This is considered cosmetic as multiple threads tried to write exactly
the same value into the same memory location without sync. The method
has been changed so this can no longer happen.
by implementing some code that was missing so far ;) as well as
finding some real bugs. I also did some general cleanup, removing
debug strings and such. This code should be fairly OK to use, except
when "exec only when previous action was suspended" is used -- this is
NOT yet re-implemented in the tuned engine.
this was previously not properly handeld. This is also the first occurence of
a (real) CAS loop inside rsyslog. Note that the performance is now very well
in the default configuration, and mark message directives are still correctly
being handled. So this code looks close to final, but needs to have some
bug cleanup as the testsuite shows.
... plus some other tests, namely string generation in parallel to action
processing. The code is not yet solid and not fully compatible to
older versions. But it is good enough for an early commit and some
early testing/gaining of experience.
The optimization was done based on the fine-grained partitioning
paradigm worked on the past couple of weeks -- seems to work out
really great :)
We now manage to cancel threads that block inside a retry loop to
terminate without the need to cancel the thread. Avoiding cancellation
helps keep the system complexity minimal and thus provides for better
stability. This also solves some issues with improper shutdown when
inside an action retry loop.
The rsyslog engine did not guard itself against output modules that do
not properly convey back the tryResume() behaviour. This then leads to
what looks like an endless loop. I consider this to be a bug of the
engine not only because it should be hardened against plugin misbehaviour,
but also because plugins may not be totally able to avoid this situation
(depending on the type of and processing done by the plugin).
this option permites to process mark messages under all circumstances,
even if an action was recently called. This can be useful to use mark
messages as a kind of heartbeat.
This was a complex manual merge, especially in action.c. So if
there occur some problems, this would be a good point to start
troubleshooting. I run a couple of tests before commiting and
they all went well.
Conflicts:
action.c
action.h
runtime/queue.c
runtime/queue.h
runtime/wti.c
runtime/wti.h
- added $GenerateConfigGraph configuration command which can be used
to generate nice-looking (and very informative) rsyslog configuration
graphs.
- added $ActionName configuration directive (currently only used for
graph generation, but may find other uses)
This is more efficient for some outputs. They new can receive fields not only
as a single string but rather in an array where each string is seperated.
Unfortunatley, I do not have the full list of contributors
available. The patch set was compiled by Ben Taylor, and I made
some further changes to adopt it to the news rsyslog branch. Others
provided much of the base work, but I can not find the names of the
original authors. If you happen to be one of them, please let me
know so that I can give proper credits.
so that the "last message repeated n times" messages, if generated, may
have an alternate format that contains the message that is being repeated.
Note that this is on an action-by-action basis.
... but did not manage to avoid doing at least one call. So
this change introduced performance benefit only in a few
non-common situations. Anyhow, it hopefully levels ground
for better things to come.
This also lead to the addition of two new config directives:
$ActionExecOnlyEveryNthTime and $ActionExecOnlyEveryNthTimeTimeout
This feature is useful, for example, for alerting: it permits you to
send an alert only after at least n occurences of a specific message
have been seen by rsyslogd. This protectes against false positives
due to waiting for additional confirmation.
initialization now takes place in message processing. This works much
better with the new queued action mode (fast startup)
- fixed a newly introduced bug that caused output module's doAction entry
point to be called on more than one thread under some circumstances
