| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
as well as some work in preparation of storing doAction params inside
the batch
|
|
|
|
|
| |
I did not revert to using the action ppMsg data element, as one of the
next steps is to remove it by an overall much better solution.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
messages should be logged
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.
|
|/
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
... 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 :)
|
|
|
|
| |
also: bugfix: mutexes used to similate atomic instructions were not destructed
|
|
|
|
|
|
|
|
| |
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).
|
|\ \
| | |
| | |
| | |
| | |
| | | |
Conflicts:
runtime/rsyslog.h
runtime/wtp.c
|
| | | |
|
|\ \ \
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
configure.ac
plugins/imudp/imudp.c
runtime/stream.h
tests/Makefile.am
tests/diag.sh
tools/omfile.c
|
| |\|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
runtime/debug.c
runtime/stream.c
tests/Makefile.am
tests/diskqueue.sh
tests/nettester.c
tools/omfile.c
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|\| | |
|
| | |
| | |
| | |
| | |
| | | |
what could lead to rsyslog running in a thight loop.
Also did some code cleanup of previous patch.
|
| | |
| | |
| | |
| | |
| | | |
Suspension during beginTransaction() did not properly cause the action
to be suspended, thus we entered an endless loop.
|
|\| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
action.c
configure.ac
doc/manual.html
doc/rsyslog_conf_modules.html
tests/sndrcv_drvr.sh
|
| | |
| | |
| | |
| | | |
potentially resulting in non-message destruction and thus hangs
|
|/ /
| |
| |
| |
| | |
... and addes some (later-to-be-removed) debug code to support finding
a problem in transaction handling.
|
| |
| |
| |
| |
| | |
...by replacing time() call with much faster (at least under linux)
gettimeofday() calls.
|
|\|
| |
| |
| |
| | |
Conflicts:
tests/Makefile.am
|
| |\
| | |
| | |
| | |
| | | |
Conflicts:
tests/Makefile.am
|
| | |
| | |
| | |
| | |
| | |
| | | |
This was a regression from the time() optimizations done in v4.
Bug tracker: http://bugzilla.adiscon.com/show_bug.cgi?id=143
Thanks to Klaus Tachtler for reporting this bug.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
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...
|
| | |
| | |
| | |
| | |
| | |
| | | |
processing.
THIS IS A VERY IMPORTANT ADDITION, see its doc for why.
|
| | |
| | |
| | |
| | | |
As an artifact of early development, they were registered in syslogd.c
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
... 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.
|
| | |
| | |
| | |
| | | |
... non-working version!
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|