[rules-users] Rule with temporal operators
Edson Tirelli
tirelli at post.com
Fri Jul 10 17:05:48 EDT 2009
Ok, this is a very tricky situation. The engine is behaving as it is
designed to behave, but I can see how the situation is misleading, and it is
an edge case. I will explain what is happening and then I am open to ideas
on how to fix that.
I executed this example with the audit log. See attached screenshot.
So, first of all, you are running your example with the engine set to
STREAM mode, meaning that the engine will automatically garbage collect
events when they can no longer match or when they are expired. So, from the
audit log you see that events 1, 2 and 3 are inserted, rule is activated and
fired and when the clock is advanced to match event 4 timestamp, the first 3
events are garbage collected (expired).
Now, the edge case. It happens that you are using a minute based
precision and the events 4 and 5 happen exactly at the same minute, in the
given order. Your rule, although, considers events happening at the same
minute as valid events to avoid the rule firing (timeStampAttr >=
$timeStampAttr1). That is fine and the rule does not fire. But when the
clock advances to match timestamp of event 7, the engine expires the old
events in the order they arrived. The expiration of event 4 before event 5
causes the engine to activate the rule. If the order of the events is
reversed in the rule file (just to mention one example), then the rule never
fires because the event "warning Symantec" expires before the "normal
Login_failure".
Now the event semantics state that an event "expiration", different from
a fact "retraction", does NOT cancel previously activated rules. That is
why, even when event 5 expires, the rule still fires.
I am asking Kris if we can add the session clock timestamp to the audit
log, to make this kind of analysis easier, but if you follow the code and
the audit log, it will make sense.
Now what I am thinking is: since fact expiration does not causes
activated rules to be canceled, maybe fact expirations should not cause new
activations either. But as these things are never simple (what would be the
fun?), that clashes with sliding window semantics. For instance:
Number( doubleValue > 100 ) from accumulate(
StockTick( $p : price ) over window:time( 10m ),
average( $p ) )
On the previous statement, imagine that a StockTick that is about to
expire will cause the average price of the non-expired stock ticks to go
over 100. In this case, it is expected that the fact expiration triggers an
activation.
So, please I am open to ideas.
Edson
2009/7/7 PriyaSha <nash.8103 at gmail.com>
>
> global java.lang.String output
>
> declare OMNewTicket
> @role( event )
> @timestamp (timeStampAttr)
> @expires (10m)
> end
>
> # Find 'critical' events of 'Windows' which occured after 1minute but
> before
> 10 minutes
> # of 'warning' events of 'Symantec' provided no 'Security' with severity
> 'normal' exist in between
> rule "Sample Temporal"
> no-loop true
> when
> $ticket : OMNewTicket($severity1 : severity == "warning",
> appName == "Symantec",
> $timeStampAttr1 :
> timeStampAttr)
> $ticket1 : OMNewTicket(this after[1m, 10m] $ticket,
> severity == "critical",
> $appName1 : appName ==
> "Windows",
> $timeStampAttr2 :
> timeStampAttr)
> not (OMNewTicket( timeStampAttr <= $timeStampAttr2,
> timeStampAttr >= $timeStampAttr1,
> appName == "Login_failure",
> severity == "normal"))
> then
> drools.getWorkingMemory().setGlobal( "output", "found");
> end
>
> For the input :
>
> e6382090-a259-71dd-12b9-92dfda160000 14178 10/25/2008:5:59:AM
> warning Symantec Application
> 956cb3a0-a22d-71dd-09d7-c0195b7b0000 14178 10/25/2008:6:00:AM
> warning Login_failure Security
> 28bdb2e0-a25a-71dd-1bc3-c01959f40000 14178 10/25/2008:6:05:AM
> critical Windows Application
> 956cb3a0-a22d-71dd-09d7-c0195b7b0000 14178 10/25/2008:10:04:AM
> normal Login_failure Security
> 20f39930-a27d-71dd-0369-81f8b3ee0000 14178 10/25/2008:10:04:AM
> warning Symantec Application
> 648d5010-a27c-71dd-1bc3-c01959f40000 14178 10/25/2008:10:05:AM
> critical Windows Application
> 8bcb9bb0-a32f-71dd-10c5-c01959dc0000 14179 10/26/2008:7:23:AM
> warning Login_failure Security
> 8882ee70-a331-71dd-1fbc-c0068f170000 14179 10/26/2008:7:37:AM
> warning Symantec Application
>
> I get the below output:
>
> 405000 405000 0 warning
> Symantec Sat Oct 25 05:59:00
> 406000 406000 0 warning
> Login_failure Sat Oct 25 06:00:00
> 407000 407000 0 critical
> Windows Sat Oct 25 06:05:00 found
> 408000 408000 0 normal
> Login_failure Sat Oct 25 10:04:00
> 409000 409000 0 warning
> Symantec Sat Oct 25 10:04:00
> 410000 410000 0 critical
> Windows Sat Oct 25 10:05:00
> 411000 411000 0 warning
> Login_failure Sun Oct 26 07:23:00 found
> 412000 412000 0 warning
> Symantec Sun Oct 26 07:37:00
>
> I use pseudo clock and I set the time in the third column(example
> 10/25/2008:5:59:AM) of the input as the 'timeStampAttr' by converting it to
> long.
> I also adjust the clock accordingly.
>
> My requirement is to get the those 'critical-windows' event which happens
> after 1 to 10minutes of 'warning-Symantec' provided no
> 'normal-Login_Failure' between them.
>
> Problem here is, I could not get convinced with the occurance of found in
> row #7. Coz 'Login_failure' did not occur between 10minute interval of a
> symantec and windows event. Also my intention is to identify the windows
> event.
>
> --
> View this message in context:
> http://www.nabble.com/Rule-with-temporal-operators-tp24370198p24370198.html
> Sent from the drools - user mailing list archive at Nabble.com.
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20090710/fecb5666/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: audit_log.jpg
Type: image/jpeg
Size: 93777 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/rules-users/attachments/20090710/fecb5666/attachment.jpg
More information about the rules-users
mailing list