New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drools applies not to all messages, if more than 1 processor enabled #2119
Comments
I cannot reproduce this issue, just tried with exactly that setup on current master and everything looks fine. |
No errors in log. |
Removed all extractors and disconnected all pipelines. Still no luck. |
The input plugin should not have anything to do with it, however, it is also not built for Graylog 2.0 yet, so there might be incompatibilities. Can you try to reproduce this issue with the random http message generator input? |
Checked with random HTTP generator and it works. |
Ok, then it sounds like there's an issue with the beat input. It could very well be that some fields have a |
I fixed that by changing all dots to "_" in input. |
All messages from an input are processed in the same manner, I don't know the beats input plugin that well, but there's usually no way to avoid processing them. |
No. I've faced dot problem on first Graylog 2.0 start and fixed it in first place |
created log with trace level while reproducing problem (GA version still have this bug) gaylog_bug_trace.txt For example. |
I can also confirm that drool rules are not applied to all messages in Graylog 2.0.0.
|
I've ran a longer test to try to reproduce this and once in a while it looks like Drools itself is not matching any rules:
This happens across all processor threads (I am running three in this case), without an obvious pattern. The weird thing about this issue is, that nothing about Drools has changed since 1.2, in fact nothing has changed since July 2014. I'll keep digging, though. |
Could you check if RulesFilter are singleton, or created per processor thread? (it is hard for me to check without IDE ) Also i found, that extractors processed before drools according to that code:
Could it be made configurable throught "Message Processors Configuration" page? |
I have found the issue and will push a fix shortly. All filters can cope with that, except Drools. Its sessions need to be isolated. We will not be making the filters configurable, because that interface will be deprecated soon. Instead the Drools support will move into a plugin in an upcoming version and implement |
When introducing the MessageProcessor interface, the processing threads accidentally shared the instances (and by induction the MessageFilter instances as well). That posed no problem for most of the filters, because they do not rely on shared state, but the Drools filter does and could skip messages (because of Drools itself returning early) This change uses a Provider to get the OrderedMessageProcessor instances explicitly and those do not get shared across threads. fixes #2119 fixes #2188
Also to avoid confusion, the binding code quoted above does not influence the execution order, filters are ordered by a numeric priority which is hardcoded. |
When introducing the MessageProcessor interface, the processing threads accidentally shared the instances (and by induction the MessageFilter instances as well). That posed no problem for most of the filters, because they do not rely on shared state, but the Drools filter does and could skip messages (because of Drools itself returning early) This change uses a Provider to get the OrderedMessageProcessor instances explicitly and those do not get shared across threads. Fixes #2119, fixes #2188
Problem description
If I set processbuffer_processors to more than 1, Drools will process not every message
Steps to reproduce the problem
rule "Test Rule" when m : Message() then m.addField("test", "test_value"); end
Environment
The text was updated successfully, but these errors were encountered: