| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
For consistency, ./configure generated "config.h" must be the first
header include through out the project.
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
|
|
|
|
|
| |
on some platforms (namely Debian sid). This smells like a bug in zlib.
Thanks to Michael Biebl for reporting the issue.
|
|
|
|
|
|
|
|
|
| |
- improved testbench to contain samples for totally malformed messages
which miss parts of the message content
- bugfix: some malformed messages could lead to a missing LF inside files
or some other missing parts of the template content.
- bugfix: if a message ended immediately with a hostname, the hostname
was mistakenly interpreted as TAG, and localhost be used as hostname
|
|
|
|
|
|
|
| |
[backported from v5 commit 98d1ed504ec001728955a5bcd7916f64cd85f39f]
This actually was a "recent" regression, but I did not realize that it
was introduced by the performance optimization in v4-devel. Shame on
me for having two devel versions at the same time...
|
| |
|
| |
|
|
|
|
|
| |
now CSV and regex extraction are being tested (would have caught the
bug fixed with the last commit).
|
| |
|
|\
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
also prepared test case for TLS testing, but not activated it
inside the build itself.
A note on TLS testing: the current testsuite (in git!) already contains
TLS test cases. However, getting these test cases correct is not simple.
That's not a problem with the code itself, but rater a problem with
synchronization in the test environment. So I have deciced to keep the
TLS tests in, but not yet actually utilize them. This is most probably
left as an excercise for future (devel) releases.
|
| |
| |
| |
| |
| | |
... also improved two-instance test mechanism, now have a generic
approach.
|
| |
| |
| |
| | |
... plus a simple initial test of the tcp forwarding capability.
|
| | |
|
| |
| |
| |
| |
| | |
thus some unpredictable behavior and a false negative test result
could occur. [BACKPORTED from v5]
|
|\|
| |
| |
| |
| |
| | |
Conflicts:
ChangeLog
runtime/msg.c
|
| |
| |
| |
| |
| |
| | |
This resulted in build errors if no Java was present on the build system,
even though none of the selected option actually required Java.
(I forgot to backport a similar fix to newer releases).
|
| | |
|
| |
| |
| |
| | |
Some devices seem to create them and I do not see any harm in supporting that.
|
|\ \
| | |
| | |
| | |
| | | |
Conflicts:
tests/nettester.c
|
| | |
| | |
| | |
| | |
| | |
| | | |
This was a result of an internal processing error if maximum field
sizes had been specified in the property replacer.
Also did some testbench improvements, including omstdout.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
... this is necessary in preparation for the final solution (we need
to have a "unified" writer). If it causes worse performance to have the
zip writher togehter with the synchronous write, we may do an async write...
|
|/ /
| |
| |
| |
| | |
... seems to work on quick testing, but needs a far more testing
and improvement. Good milestone commit.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
some things inside the message can be used over a large number of
messages and need to to be allocated and re-written every time. I now
begin to implement this as a "prop_t" object, first use for the inputName.
Some input modules are already converted, some others to go. Will do
a little performance check on the new method before I go further.
Also, this commit has some cleanup and a few bug fixes that prevented
compiliation in debug mode (I overlooked this as I did not compile
for debug, what I normally do, and the automatted test also does not
do that)
|
| |
| |
| |
| |
| | |
the deferred activation of input modules broke part of the testbench -
but this was a testbench issue, not one of the patch
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
tests for the various timestamp formats have been added
|
| |
| |
| |
| | |
this was a regression I introduced this afternoon
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
... actually, it was not broken, but just very slow. I have now
reduced the number of test messages so that make check will not be
held for an extended period of time.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
... this was long overdue, and I finlly tackeld it. It turned out to
be more complex than I initially thought. The next step now probably is
to actually implement multiple rule sets and the beauty that comes
with them.
|
| |
| |
| |
| |
| |
| |
| | |
also adds speed, because you do no longer need to run the whole file
system in sync mode. New testbench and new config directives:
- $MainMsgQueueSyncQueueFiles
- $ActionQueueSyncQueueFiles
|
|/
|
|
|
|
|
| |
now only stream class is utilized. ttys, pipes and outchannel functionality
is currently disabled. But the testbench worked again. Cleanup needed, will
do this with next commit (it may break things and I like to have this
milestone here).
|
|
|
|
|
|
|
|
| |
this permits us to keep a persistent test environment between
v4 and v5, most importantly using the same tools. As far as the
actual tests are concerned, some had issues. I had no time to check
if that was an issue with the test or an actual issue with the
v3/4 engine. Will do that at some later stage.
|
| |
|
|\
| |
| |
| |
| | |
Conflicts:
tests/Makefile.am
|
| |\
| | |
| | |
| | |
| | | |
Conflicts:
tests/Makefile.am
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
is detected.
This change is considered important but small enough
to apply it directly to the stable version. [But it is a border case,
the change requires more code than I had hoped. Thus I have NOT tried
to actually catch all cases, this is left for the current devel
releases, if necessary]
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The imdiag module now can very effectively inject messages, which also
frees us from uncertainties of tcp reception and processing. All shell
script based tests have been modularized, what makes it far easier to
create new tests. Also, the test bench now executes more reliable and
much faster, because we can now rely on actual engine information where
we previously did just a dumb sleep.
|
| | | |
|