Add "Concurrency & Locking" to dev_action_threads.rst:
multiple workers per action; WID is per-worker; shared pData must be
mutex/rwlock-protected; direct mode still needs module-side serialization
for inherently serial resources.
Introduce a new developer-oriented documentation page:
File: doc/source/development/dev_action_threads.rst
Content:
- End-to-end overview of the rsyslog queue engine (producers → rulesets → actions)
- Terminology
- Mermaid flowchart for thread and queue topology
- State diagram for watermarks/backpressure
- Sequence diagram for action-queue lifecycle
- Error handling (retry/suspend) and shutdown behavior
- Queue types and selection guidance
- Key queue parameters and cross-references
Motivation:
Provide a single, high-signal reference for contributors to understand the queue engine and action worker model, with visualizations to aid comprehension.
Update dev_queue.rst with note about outdated content and reference to dev_action_threads
Co-authored-by: alorbach <alorbach@adiscon.com>
Refactored omelasticsearch.rst by moving each parameter description
into its own file under doc/source/reference/parameters/, one per
parameter. Each new page contains:
- Standardized metadata (Name, Scope, Type, Default, Required?, Introduced)
- Concise summary block for inclusion in the overview table
- Verified and clarified type information
- Usage examples for module/action contexts
- Legacy or alternate name mappings where applicable
Updated omelasticsearch.rst to present a list-table with :ref: links
and inline summaries for all parameters, plus a hidden toctree linking
to the new reference pages.
This change brings omelasticsearch documentation in line with the
structured parameter format adopted for other modules, improving
maintainability, readability, and navigation for both human users and
AI systems.
No functional changes; documentation only.
Refactored pmrfc3164.rst to move individual parameter descriptions into
dedicated files under doc/source/reference/parameters/, one per parameter.
Each new page contains:
- Consistent metadata (Name, Scope, Type, Default, Required?, Introduced)
- Concise summary blocks for inclusion in overview tables
- Corrected and clarified type info (boolean/string)
- Usage examples for parser configuration
- Legacy/alternate name mappings
pmrfc3164.rst now presents parameters via a list-table with :ref: links
and inline summaries, plus a hidden toctree for the new reference pages.
This brings pmrfc3164 documentation in line with the structured parameter
format used in other modules, improving maintainability, readability,
and navigation.
No functional changes; documentation only.
Refactored imjournal.rst to move detailed parameter descriptions into
individual files under doc/source/reference/parameters/, one file per
parameter. Each page now includes:
- Consistent metadata (Name, Scope, Type, Default, Required?, Introduced)
- Concise summary blocks for list-table inclusion
- Updated and clarified type information (boolean/string/integer)
- Corrected legacy/obsolete name mappings
- Usage examples for module and input scopes
imjournal.rst now uses list-tables with :ref: links to these pages and
includes summaries inline for quick scanning. This aligns imjournal’s
documentation structure with other modules, improves maintainability,
and enhances reusability for AI-assisted and human navigation.
No code changes; documentation only.
With support from AI agents: Codex, Gemini
Added cross-references to doc/ai/module_map.yaml in both developer-
facing guides:
- AGENTS.md:
* Mentioned the AI module map in the Repository Overview and
Quickstart sections.
* Added a common task instructing contributors to consult the map
before making edits.
- DEVELOPING.md:
* Updated “Pointers” to include the AI module map as a source for
per-module paths and known locking hints.
This improves discoverability of module locations and expected locking
patterns for both AI agents (e.g., Codex) and human contributors,
reducing time spent locating code and relevant design notes.
No functional changes; documentation only.
Split monolithic omfile.rst content into dedicated parameter reference
files under doc/source/reference/parameters/, one file per parameter.
Added :toctree: entries and summary include blocks to omfile.rst for
both module and action parameters. Introduced consistent metadata
(Name, Scope, Type, Default, Required?, Introduced) and usage examples
for each parameter page, along with legacy name mappings where
applicable.
This change improves documentation maintainability, readability, and
AI/RAG ingestion by:
- Enforcing consistent structure across parameter docs
- Separating module and action scopes in a clear, reusable format
- Linking parameter summaries directly from omfile.rst via list-tables
- Preserving legacy directive references for backward compatibility
No functional changes to rsyslog.
Migrates all imdocker module parameter descriptions from the monolithic
module page into individual parameter reference files under
doc/source/reference/parameters/. Each parameter now has:
- A stable Sphinx label and cross-references
- A concise summary section for use in tables and AI ingestion
- Clear metadata (scope, type, default, introduced version)
- RainerScript usage examples
- "See also" links back to the main module page
The imdocker.rst page now uses a compact parameter list-table with
embedded summaries and a hidden toctree linking to full parameter pages.
This aligns with the new documentation structure for better maintainability,
human readability, and machine ingestion (e.g. for RAG-based assistants).
GPT 5 has problems accessing the RAG which GPT 4 did not have. But it
may also be that GPT 4 simply did not tell us about these problems.
My guess is that the new anti-hallucination algo is at work here. This
is generally good, albeit it broke the rsyslog Assistant a bit.
As a short-term measure we have enabled it to search rsyslog.com. That
will still remove all the garbagged. My first impression is that this
might be even better than a RAG based system with larger files. This
needs to be seen in practice now.
see also https://github.com/rsyslog/rsyslog/issues/5903
We need to validate the locking method - in theory, multiple access to
the mysql handle should not be possible, because instance data is
worker-local. However, the following 2021 commit suggests there were some
issue. I tend to say the commit was wrong, but this needs to be checked
in more depth, while we need some better doc on the current locking method
right now. So we document existing and valid behaviour and will follow up later.
related commit:
a3b2983342
Replace opaque/variadic callback usage with explicit, type-safe function
signatures to reduce undefined behavior and clarify intent.
Adapter helpers bridge the existing APIs without raw variadic casts, enabling
the transition incrementally. Callback setup sites are standardized for
consistent readability. This tightens the contract on callbacks, eases future
refactoring, and makes their roles more self-documenting.
Inspired by https://github.com/rsyslog/rsyslog/pull/5882
With AI support: Codex, Gemini
- Replaced function pointer casting with direct handler calls for type safety
- Fixes crashes (BUS errors) on ARM64 macOS 14+ due to strict calling conventions
- Root cause identified by ThreadSanitizer
- Eliminates undefined behavior, improves code safety
This commit fixes a race condition that could occur when two threads tried to close the same TCP session simultaneously. This could lead to an "epoll_ctl failed: Bad file descriptor" error message.
The fix introduces an atomic flag `being_closed` to the `tcps_sess_t` struct. This flag is used to ensure that the session-closing logic is executed only once per session.
This commit also corrects the logic of the atomic check to prevent the race condition correctly.
This commit fixes a race condition that could occur when two threads tried to close the same TCP session simultaneously. This could lead to an "epoll_ctl failed: Bad file descriptor" error message.
The fix introduces an atomic flag `being_closed` to the `tcps_sess_t` struct. This flag is used to ensure that the session-closing logic is executed only once per session.
