The call rscript statement is able to call a rule set either synchronously or
asynchronously. We did this, because practice showed that both modes
are needed. For various reasons we decided to make async
calls if the ruleset has a queue assigned and sync if not.
To know if a "queue is assigned" we just checked if queue parameters were
given. It was overlookeded the case of someone explicitly specifying a
"direct queue", aka "no queue". As such, queue="direct" triggered async
calls. That in turn meant that when a write operation to a variable was
made inside that rule set, other rulesets could or could not see the
write. While if was often not seen, this was a data race where the
change could also be seen by the outside.
This is now fixed. No matter if queue.type="direct" is specified or
left out, the call will always by synchronous. Any values written to
variables will also be seen by the "outside world" in later processing
stages.
Note that this has some potential to BREAK EXISTING CONFIGURATIONS.
We deem this acceptable because:
1. this was racy at all, so unexpected behaviour could alwas occur
2. it is actually unlikely that someone used the triggering conditions
in practice. But we can not outrule this, especially when the
configuration was auto-generated.
Potential compatibility issues can be solved by defining a small
array-memory queue on the ruleset in question instead of specifying
direct type.
Again, we expect that almost all users will never experience any
problems. If you do, however, please let us know: we may add an
option to re-enable the bug.
The testbench framework does not properly wait until ES has created
its pid file, which probably means it did basic initializiation.
This can cause test synchronization issues and ultimately failures.
CentOS 6 has reached end of life for a while and we have not
seen any request for it for even a while longer. We asked for
community feedback and there was no objection against removing
it from regular CI. As such, this now happens.
We now also test Fedora via github actions. We add current Fedora 33
and remove outdated Fedora 30. After this patch has been applied, we
can remove Fedora test from buildbot.
So we can use the more modern tools that comes with it.
We also change some plumbing as newer version of TSAN require
that.
Note: we disable some kafka TSAN/ASAN tests as librdkafka
throws errors which we currently cannot suppress. This issue
will be addressed in separate patch.
in order to trigger actions, we seem to need to have at least one workflow
present in primary branch. At least otherwise PR runs do not trigger. So we
provide this on a hopefully simply enough (non-failing) dummy.
Instead of linking to only the master branch version of the docs, perhaps provide a link to both versions since there is not an index page that lists both?
refs rsyslog/rsyslog#2283
