| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
It has proven to be very valuable, so now it is properly formatted
inside the source.
|
| |
|
|
|
|
|
| |
this could happen if multiple rulesets were used and some output batches
contained messages belonging to more than one ruleset.
fixes: http://bugzilla.adiscon.com/show_bug.cgi?id=226
fixes: http://bugzilla.adiscon.com/show_bug.cgi?id=218
|
| |\ |
|
| | |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| | |
I have now done the necessary cleanup. Looks like everything is in place.
Unfortunately, I do not yet have any actual parser that is not built-in,
but I think we can postpone working on that when the first one appears.
I don't expect troubles in that case, but you never know ;)
|
| | |
| |
| |
| |
| | |
The implementation is now almost done and works, including doc. I now
need to verify shutdown, guess there are some resource leaks left...
|
| | |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
This offers considerable additional flexibility AND superior performance
(in cases where multiple inputs now can avoid lock contention)
|
| | |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
also bumped version number and corrected ChangeLog, where I merged
some post 5.3.1 changes into the 5.3.1 section.
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
| |
... as well as added multi-ruleset support for imtcp
|
| |
|
|
| |
plus some cleanup...
|
| |
|
|
|
|
| |
... 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.
|
