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

[Edson Tirelli]

   Hi Tina,

1. In cases like this, either you define an @expires policy that is longer
than your temporal constraints + latency to receive the events, or you run
the engine in cloud mode (disabling the lifecycle management).

2. Yes, correct. As you probably realized, given only the constraint in your
example, the same B could match multiple A's.

   Edson



2010/8/23 Tina Vießmann <tviessmann at stud.hs-bremen.de>

>  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>
>
>>  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
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
>
>
> --
>   Edson Tirelli
>   JBoss Drools Core Development
>   JBoss by Red Hat @ www.jboss.com
>
>
> _______________________________________________
> rules-users mailing listrules-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> 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/20100823/59860fae/attachment.html