If a module always returns RS_RET_OK (like ompipe does) the actionDoRetry
loop may not have leaved faked ACT_STATE_SUSP state in case iResumeOKinRow
had ever reached a count of 1000.
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
most importantly pmlastmsg, which handles the pathetic "last message
repeated n times" messages that some syslogd's emit.
Also some minor fixes, like wrong files names in make dist (for new
files introduced after last release)
Note that, as it looks, the directive was already broken in previous v5 versions.
So while I solved what looked like a (intentional) regression from the
performance tuning, I actually solved a previous regression as well ;)
I have also added new test cases to the testbench in order to capture such
problems in the future. This version does now look pretty good in shape.
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.
at least in important cases (not for non-direct action queues and some
other minor things). This version is definitely buggy, but may be tried
with success on a non-production system. I will continue to work on the
correctness, but needed to commit now to get a baseline.
Now, the full batch is passed down to the rule, which then enqueues
the elements as single messages. Note that this code has some known
defects and needs more changes until it is correct again. This is
primarily a commit to be able to return to a known-(somewhat)-good
state.
messages could get lost or be duplicated due to non-proper sync
of transactions. This is a notable slowdown again, but we know
how to get back concurrency, it just takes "some" more programming.
It is important now to come back to correct code, so that we can
base further improvements on that.
things like ACL check and message parsing. This leads to a greater level
of concurrent processing. Beware, though, that this commit duplicates
some messages. May be a regression from this or an earlier commit. I will
soon sort out.
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 :)
This was a test done to try to generate templates with C code, via
a new (potentially to-be-implemented) class of template modules. We have
a rough POC inside this code, and it showed around 5% or better speedup. So
it semms worth continuing in this direction.
Note that this experimental commit works correct, but does any
template in the form of
$template tpl,=somewhat
will lead to fixed template expansion based on the default file format.
