| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This offers considerable additional flexibility AND superior performance
(in cases where multiple inputs now can avoid lock contention)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Problems could happen if the queue worker needed to be cancelled
and this cancellation happened inside queue-code (including
wtp, wti). We have now solved this by disabling cancellation while
in this code and only enabling it when working inside the user consumer.
This exactly matches the use case for which cancellation may be needed.
|
|
|
|
| |
... but in anticipation of changing cancel processing altogether...
|
|
|
|
|
|
|
| |
these occured in very unusual scenarios where we had a DA-queue running
in parallel and very lengthy actions. Then, in some situations, the
shutdown could hang. The code needs some addition lab time, but
is believed to be much better than any previous version.
|
|\ |
|
| |
| |
| |
| |
| |
| | |
primarily a problem of imdiag. Also added some fix for a potential
situation during cancel processing. That one is not considered vital
and may later be removed again.
|
| |
| |
| |
| |
| | |
We do now enqueue those objects that are left unprocessed. This enables
us to delete the full batch, what is exactly what we need to do.
|
|/
|
|
|
|
|
|
| |
... 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...
|
|
|
|
|
|
|
|
| |
support for enhancing probability of memory addressing failure by
using non-NULL default value for malloced memory (optional, only if
requested by configure option). This helps to track down some
otherwise undetected issues within the testbench and is expected
to be very useful in the future.
|
|\
| |
| |
| |
| |
| | |
Conflicts:
ChangeLog
runtime/queue.c
|
| |
| |
| |
| |
| |
| | |
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.
|
| |\
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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!
|
| | |
| | |
| | |
| | |
| | | |
Failed for both pure disk as well as DA queues. Now, we emit an error
message and disable disk queueing facility.
|
| | |
| | |
| | |
| | |
| | | |
this was a regression of the recent imudp multi-ruleset enhancement
bug was not in any released version
|
|\ \ \ |
|
| | |/
| |/| |
|
|/ / |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| | |
Conflicts:
ChangeLog
runtime/msg.c
|
| |
| |
| |
| | |
This was a recently introduced regression.
|
| |
| |
| |
| |
| | |
bugfix: debug string larger than 1K were improperly displayed. Max size
is now 32K, and if a string is even longer it is meaningful truncated.
|
| |
| |
| |
| |
| | |
also bumped version number and corrected ChangeLog, where I merged
some post 5.3.1 changes into the 5.3.1 section.
|
| | |
|
| |
| |
| |
| | |
This was a recently introduced regression.
|
|\ \ |
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | | |
Max size is now 32K.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- bugfix: solved potential (temporary) stall of messages when the queue was
almost empty and few new data added (caused testbench to sometimes hang!)
- fixed some race condition in testbench
- added more elaborate diagnostics to parts of the testbench
- solved a potential race inside the queue engine
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
made shutdown more reliable by makeing sure that the main queue DA worker
is only cancelled if this is actually unavoidable. Also moved down the
deletion of rsyslogd's pid file to immediately before termination, so
that absence of the file is a proper indication that rsyslogd has
finished (in the past, e.g. the testbench accidently ran two intances
as the pid file was deleted too early). Also some improvments to the
testbench, namely to handle aborts more intelligently (but still not
perfect).
|
| |_|/
|/| | |
|
|\| | |
|
| |\| |
|
| | | |
|
|\| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
runtime/rsyslog.h
tcpsrv.c
|
| |\|
| | |
| | |
| | |
| | | |
Conflicts:
runtime/rsyslog.h
|
| | | |
|
| |\ \
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
configure.ac
doc/manual.html
runtime/datetime.h
runtime/parser.c
runtime/rsyslog.h
tools/syslogd.c
v4-stable had a bug with RFC5424-formatted structured data, which showed
was detected by the enhanced automatted testbench of v4-beta.
|
| | |
| | |
| | |
| | | |
could lead to mis-addressing and potential memory corruption/segfault
|
| | | |
|
|\| |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
ChangeLog
configure.ac
doc/manual.html
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
we needed to release ALL resources (including file handles!) only
after the the async writer thread has terminated (else it may access
them). In this case, we had a file handle leak, because the handle was
sometimes only opened in the async writer, but the close was attempted
before the writer even started (in some cases).
|
| | |
| | |
| | |
| | |
| | |
| | | |
...after we seem to have identified the root cause of the segfault.
I leave them commented out so that we can re-activate it if need
arises (aka "get some practice drill first").
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Most severely affected omfile. The problem was that some buffers were
freed before the asynchronous writer thread was shut down. So the
writer thread accessed invalid data, which may even already be
overwritten. Symptoms (with omfile) were segfaults, grabled data
and files with random names placed around the file system (most
prominently into the root directory). Special thanks to Aaron for
helping to track this down.
|