[rules-users] Stream Mode with Temporal Reasoning and Event Lifecycle Management

[Tina Vießmann]

  Thank you, Edson. :)

I've got two more questions about that for now.

The first one is kind of ... ugly.
I know the stream mode needs a time-ordered stream so that the 
processing can be done correctly. In my case it can not really be 
predicted at which time an event arrives so that the system/application 
clock and the timestamp contained in the events are not synchronous.
Let's say that delta-t is the relation between the time a object is send 
and received. The send time is reflected by the timestamp of the object 
which is referenced using @timestamp. In my case there does no Delta-t 
exists that expresses  sendTime+Delta-t=receiveTime. Therefore a event A 
with ts=10h15m03s10ms can arrive at tr=10h15m04s49ms and a event B with 
ts=10h15m17s30ms can arrive at tr=10h15m20s55ms.
If I've got now the rule
   $a : A()
   $b : B(this after[0,20s] $a)
Will the engine 'count' and wait the 20 seconds for a appropriate event 
B? Or how would it work?


The second question is more simple.
If I use
   $a : A()
   $b : B( this before[0,3m] $a )
How does the engine handle the automatic life cycle managment? Will 
every B will be kept for 3 minutes to see if there will be a related A?

Thank you! :)
Tina


>
>    Drools also use the 13 temporal operators as "hints", so if you 
> have a rule:
>
> $a : A()
> $b : B( this after[0,3m] $a )
>
>    Drools will know that A's must be held in memory for 3 minutes 
> while B's will expire immediately. Drools will calculate all possible 
> expiration offsets based on all used temporal operators.
>
>    In case no expiration offset can be calculated for a given event 
> (i.e., no temporal operator was used, no sliding window, no @expires 
> policy, resulting in expiration offset to be infinity), the event is 
> help in memory until explicitly retracted.
>
>    Edson
>
> 2010/8/23 Tina Vießmann <tviessmann at stud.hs-bremen.de 
> <mailto:tviessmann at stud.hs-bremen.de>>
>
>      Hi,
>
>     I'm thinking about something. Maybe anyone can tell me.
>
>     The Stream Processing Mode of Drools Fusion provides automatic
>     lifecycle
>     managment. For my understandings this is based on the sliding windows
>     used inside the rule conditions, the @expires metadata and the @delay
>     metadata. Am I right so far?
>     My questions is now: How are Events handled if non of the things
>     listed
>     above are used?
>
>     Let's say I've got rules just using the temporal reasoning operators
>     inside the rule conditions - no sliding windows at all. I'm also not
>     using any of the @expires and @delay metadata. Is it correct than
>     that:
>      - Drools matches the event coming in and the events existing in the
>     KnowledgeBase and eventually activates a rule. And after
>     fireAllRules()
>     is called the resulting actions are performed and all Events are
>     retracted by the automatic lifecycle managment,  because there are no
>     hints (like a sliding window) that events will be needed again.
>     (So that
>     the knowledge base would be empty again?)
>
>     Thanks for any explanations. :)
>     Tina
>     _______________________________________________
>     rules-users mailing list
>     rules-users at lists.jboss.org <mailto: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 <http://www.jboss.com>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20100823/63f017c8/attachment.html