- duplicate diag.sh init call was not detected due to typo
- queue-persits test did not work correctly
- some general testbench framework improvements
issues found be shellcheck, fixes brought up other work to do
Also now permit interactivly running tests without explicitly setting
$srcdir. This now works if we are inside ./tests and fails, as before,
when we are in a different directory.
Detected by shellcheck via CodeFactor.io
This is required to support parallel test runs.
Among others, make thise files dynamic:
* test-spool
* rsyslog.input
* rsyslog.out*.log
* tmp.in
Also:
* convert presort test statement to function
* cleanup imfile truncation test
* cleanup imfile-growing-file-id test
some cruft was left due to copy and paste error
* serialize mysql tests
Merging in multiple steps to avoid getting new tests with non-correct
plumbing.
- some more dynamic file names
- convert more commands to pure bash functions
- cleanup no longer neede files
- DEAD_PORT now uses unassigned IANA port unlike to be used on the system
(dynamic port querying is racy and we had at least once an issue, so we
can remove ambiguity here easily)
- replace some diag.sh commands by bash functions
Support tools (like tcpflood) are also upgraded to support the
necessary dynamic port.s
This is part of the effort to make parallel testing possible.
We move parts of the cleanup to the buildbot cleanup, as we cannot
clean out instances on each test when we run parallel tests.
changes some of the test commands to use bash functions
includes some small bug fixes to tests where bugs were
previously not seen due to different plumbing.
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.
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.
... 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.
- 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
