This was due to the fact that the action module only preserved and
processed the last set passing mode. Note that this was not a problem
for the plugins provided by the rsyslog git: none of them uses different
passing modes.
Thanks to Tomas Heinrich for providing a very detailled bug report.
which makes troubleshooting a bit easier. Note that we cannot output all
the config details (like destination etc) as this would require much more
elaborate code changes, which we at least do not like to do in the
stable version.
For obvious reasons, it needs to be boolean. Note that this change
can break existing configurations if they circumvented
the problem by using 0/1 values.
This was experienced if the retry action took more than one second
to complete. For suspending, a cached timestamp was used, and if the
retry took longer, that timestamp was already in the past. As a
result, the action never was kept in suspended state, and as such
no failover happened. The suspend functionalit now does no longer use
the cached timestamp (should not have any performance implication, as
action suspend occurs very infrequently).
Also added some better debug logging for the action engine.
Moave element status out of batch_obj_t because we
get a *much* better cache hit ratio this way.
Note that this is really a HUGE saving, even if it
doesn't look so (both profiler data as well as
practical tests indicate that!).
This happened only on very high volume systems, if the same message was
being processed by two different actions. This was a regression caused
by the new config processor, which did no longer properly enable msg
locking in multithreaded cases. The bugfix is actually a refactoring of
the msg locking code - we no longer do unlocked operations, as the use
case for it has mostly gone away. It is potentially possible only at
very low-end systems, and there the small additional overhead of doing
the locking does not really hurt. Instead, the removal of that
capability can actually slightly improve performance in common cases,
as the code path is smaller and requires slightly less memory writes.
That probably outperforms the extra locking overhead (which in the
low-end case always happens in user space, without need for kernel
support as we can always directly aquire the lock - there is no
contention at all).
this was always action_t, but the initial design was more generic. We are
making it specific now in order to gain better performance (after all, we
did not need the generic engine in the past 8 years...)
