... 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).
when dynaCache is enabled, the cache is full, a new entry needs to
be allocated, thus the LRU discarded, then a new entry is opend and that
fails. In that case, it looks like the discarded stream may be reused
improperly (based on code analysis, test case and confirmation pending)
- bugfix: queues in direct mode could case a segfault, especially if an
action failed for action queues. The issue was an invalid increment of
a stack-based pointer which lead to destruction of the stack frame and
thus a segfault on function return.
Thanks to Michael Biebl for alerting us on this problem.
[backport from 5.5.2]
- bugfix: wrong memory assignment for a config variable (probably
without causing any harm) [backport from 5.2.2]
especially if an action failed for action queues. The issue was an
invalid increment of a stack-based pointer which lead to destruction
of the stack frame and thus a segfault on function return.
Thanks to Michael Biebl for alerting us on this problem.
another milestone commit: the program works, the new interface
is used, some more cleanup is needed and the per-ruleset config
options are still missing. But we are getting closer...
... but this brings a lot of problems with it. The issue is that
we still have a sequential store and we do not know how we could
delete the one entry right in the middle of processing. I keep this
branch if we intend to move on with it - but for now I look into a
different solution...
however, this had no negative effect, as the message processing state
was not evaluated when a batch was deleted, and that was the only case
where the state could be wrong.
simplified and thus speeded up the queue engine, also fixed some
potential race conditions (in very unusual shutdown conditions)
along the way. The threading model has seriously changes, so there may
be some regressions.
NOTE: the code passed basic tests, but there is still more work
and testing to be done. This commit should be treated with care.
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.
optimized substring processing, should bring a small enhancement when
forwarding with the default forwarding templates. Also did some uchar
cleanup in msg.c (thus so many changes, in reality they are few...).
It is intentionally quick & dirty, as I would like to do some
better patch, if possible. For that, I probably need the commented-out
code, thus no delete.
this bug was introduced by a recent change which was a bit too agressive
in avoiding locking. We can probably do better than with this patch, but
I think I'll move that into the v5 engine.
the string area that is used to build the string being passed to
the output module is now part of the action structure. As such,
access to it must also be guarded by the action mutex (an even more
optimal solution may be to store it in thread-local storage, but
there always must remain some room for improvement ;)).
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
