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).
The "queue.xxx" parameter set was not supported, and legacy ruleset
config statements did not work (by intention). The fix introduces the
"queue.xxx" parameter set. It has some regression potential, but only
for the new functionality. Note that using that interface it is possible
to specify duplicate queue file names, which will cause trouble. This
will be solved in v7.3, because there is a too-large regression
potential for the v7.2 stable branch.
this enables smoother builds on older systems that do not support
libuuid. Loss of functionality should usually not matter too much as
uuid support has only recently been added and is very seldom used.
The most important real code chane is the initialization of the
epoll control set. This should just be cosmetic (valgrind warnings),
as all data we actually use already was properly initialized.
This lead to queue file corruption. While the root cause is a config
error, it is a bug that this important and hard to find config error
was not detected by rsyslog.
note that none of the rsyslog-provided plugins does this
Thanks to bodik and Rohit Prasad for alerting us on this bug and
analyzing it.
fixes: http://bugzilla.adiscon.com/show_bug.cgi?id=347
The interface was actually not present in older versions, even though some modules
already used it. The implementation was now done, and not in 6.3/6.4
because the resulting memory leak was ultra-slim and the new interface
handling has some potential to seriously break things. Not the kind of
thing you want to add in late beta state, if avoidable.
There seem to be cases where the shutdown message is otherwise not
processed, not even on an idle system. Thanks to Marcin for
bringing this problem up.
