]
Matteo Mortari updated JBRULES-3639:
------------------------------------
Attachment: SimpleCEP2 (very simple demo).zip
The source Eclipse project, including drl Rule file, Audit log as commented in the JIRA,
and Application which manages the Event insert into working memory and session clock.
Improve Drools Fusion Documentation of Event expiration mechanism
-----------------------------------------------------------------
Key: JBRULES-3639
URL:
https://issues.jboss.org/browse/JBRULES-3639
Project: Drools
Issue Type: Patch
Security Level: Public(Everyone can see)
Components: drools-compiler (fusion), drools-core (fusion)
Affects Versions: 5.4.0.Final
Environment: Eclipse 3.7 SR2, Jboss Tools, Drools 5.4.0.Final, Win XP. Attaching
Eclipse project
Reporter: Matteo Mortari
Assignee: Mark Proctor
Attachments: Screenshot-2012-09-27_18.25.40.png, SimpleCEP2 (very simple
demo).zip
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.
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: