[jboss-jira] [JBoss JIRA] (JBRULES-3639) Improve Drools Fusion Documentation of Event expiration mechanism

[ https://issues.jboss.org/browse/JBRULES-3639?page=com.atlassian.jira.plug... ] Matteo Mortari updated JBRULES-3639: ------------------------------------ Description: h4. Executive Summary This is to kindly request, if you can please improve the Drools Fusion documentation to explain more specifically about “Automatic Event Lifecycle Management”, and the basis how Event expiration actually works. Possibly by means of simple examples, or blueprints detailing CEP best implementation patterns specifically for Fusion, could greatly benefit. Thank you, I love RedHat and the JBoss Community :) but trying to understand completely Fusion’s Event expiration is making me crazy :P h4. Rationale The documentation in [par. “2.5.2. Stream Mode”| http://docs.jboss.org/drools/release/5.4.0.Final/drools-fusion-docs/html_...] is imho vague in the second requirement, specifically the generic statement “the use of non-time-synchronized streams may result in some unexpected results”. Especially it seems to me not only streams must be time-synchronized, but +also streams and the session clock must be strictly in-sync?+ Take for instance the attached Eclipse project, to replicate one un-expected behavior - I’m specifically not raising this JIRA as a bug, because of the aforementioned “vagueness” in the doc, I don’t have specific evidence this is strictly a bug. (!) The assumption in this application: Events are inserted with a lag if compared to the session clock to simulate a communication lag and slight delay. However, all Events are inserted in strict chronological order. The issue here is: *because Events, despite in chronological order, are inserted slightly late if compared to the session clock, some unexpected behavior of the After LHS operator occurs* There is a simple rule that checks for two Event of type Message to happen within 1minute delay. {code:title=Sample.drl|borderStyle=solid} declare Message @role(event) @timestamp (timestamp) end rule "asd" when $m1 : Message() $m2 : Message(this after[0, 1m] $m1, this != $m1) then System.out.println("x"); end {code} Events are being inserted in strict chronological order. A first Event of type Message is inserted. Pseudo clock is advanced rapidly. Then a second Event of type Message is inserted having timestamp {{\+1}} second to the previous one. In the Audit log, also attached, you will see the very first Event, matched as {{$m1}}, get expired and retracted immediately after the rule has fired. This is OK: now the very first Event can no longer match in this rule, and because is the only rule available, gets expired and retracted. As you would expect from the documentation. Happily. This analogously repeats in the application and reflected in the audit log. !Screenshot-2012-09-27_18.25.40.png|align=center! Now skip to the *last* Event of type Message inserted. The consequence of this last Event being inserted is that the rule had fired again; analogously, this is the only Event of type Message remaining in the working memory. Happily. As the pseudo clock gets advanced rapidly, now no more Events are inserted. When the pseudo clock reaches {{\+60}} seconds from the +session time+ when this last Event was inserted, the Event is retracted. This is the issue and the unexpected behavior. I have NOT specified {{window:time(1m)}} in my rule, but seems to behaving like that. Shouldn’t the engine wait for a very next Event *of any type* to be inserted into the working memory, to evaluate the current stream timestamp and therefore infer this Event can now safely be expired and retracted? The rule, by the way it’s written, would check to see if two Events of type Message are available within a 1minute of timespan. While instead, seems to me by the unexpected results, this also implicitly stating {{window:time(1m)}} being the Max of the parameters for the time constraint operators available in the rule. If you can explain better the Event expiration mechanism and improve the Documentation, it would greatly help to understand for instance why this scenario behaves in this (from my perspective) unexpected behavior. I seize the chance to thank you once again, Ciao was: h4. Executive Summary This is to kindly request, if you can please improve the Drools Fusion documentation to explain more specifically about “Automatic Event Lifecycle Management”, and the basis how Event expiration actually works. Possibly by means of simple examples, or blueprints detailing CEP best implementation patterns specifically for Fusion, could greatly benefit. Thank you, I love RedHat and the JBoss Community :) but trying to understand completely Fusion’s Event expiration is making me crazy :P h4. Rationale The documentation in [par. “2.5.2. Stream Mode”| http://docs.jboss.org/drools/release/5.4.0.Final/drools-fusion-docs/html_...] is imho vague in the second requirement, specifically the generic statement “the use of non-time-synchronized streams may result in some unexpected results”. Especially it seems to me not only streams must be time-synchronized, but +also streams and the session clock must be strictly in-sync?+ Take for instance the attached Eclipse project, to replicate one un-expected behavior - I’m specifically not raising this JIRA as a bug, because of the aforementioned “vagueness” in the doc, I don’t have specific evidence this is strictly a bug. (!) The assumption in this application: Events are inserted with a lag if compared to the session clock to simulate a communication lag and slight delay. However, all Events are inserted in strict chronological order. The issue here is: *because Events, despite in chronological order, are inserted slightly late if compared to the session clock, some unexpected behavior of the After LHS operator occurs* There is a simple rule that checks for two Event of type Message to happen within 1minute delay. {code:title=Sample.drl|borderStyle=solid} declare Message @role(event) @timestamp (timestamp) end rule "asd" when $m1 : Message() $m2 : Message(this after[0, 1m] $m1, this != $m1) then System.out.println("x"); end {code} Events are being inserted in strict chronological order. A first Event of type Message is inserted. Pseudo clock is advanced rapidly. Then a second Event of type Message is inserted having timestamp {{\+1}} second to the previous one. In the Audit log, also attached, you will see the very first Event, matched as {{$m1}}, get expired and retracted immediately after the rule has fired. This is OK: now the very first Event can no longer match in this rule, and because is the only rule available, gets expired and retracted. As you would expect from the documentation. Happily. This analogously repeats in the application and reflected in the audit log. !image.gif|align=center! Now skip to the *last* Event of type Message inserted. The consequence of this last Event being inserted is that the rule had fired again; analogously, this is the only Event of type Message remaining in the working memory. Happily. As the pseudo clock gets advanced rapidly, now no more Events are inserted. When the pseudo clock reaches {{\+60}} seconds from the +session time+ when this last Event was inserted, the Event is retracted. This is the issue and the unexpected behavior. I have NOT specified {{window:time(1m)}} in my rule, but seems to behaving like that. Shouldn’t the engine wait for a very next Event *of any type* to be inserted into the working memory, to evaluate the current stream timestamp and therefore infer this Event can now safely be expired and retracted? The rule, by the way it’s written, would check to see if two Events of type Message are available within a 1minute of timespan. While instead, seems to me by the unexpected results, this also implicitly stating {{window:time(1m)}} being the Max of the parameters for the time constraint operators available in the rule. If you can explain better the Event expiration mechanism and improve the Documentation, it would greatly help to understand for instance why this scenario behaves in this (from my perspective) unexpected behavior. I seize the chance to thank you once again, Ciao -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira