[rules-users] Stream Mode with Temporal Reasoning and Event Lifecycle Management
Tina Vießmann
tviessmann at stud.hs-bremen.de
Mon Aug 23 16:37:26 EDT 2010
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
More information about the rules-users
mailing list