All right, I can condense the discussion into a single recommendation for CEP with Fusion:If you want consistent real-time results from your rules, make sure that the Engine doesn't remain idle - evaluate each new situation immediately, or do not run the Engine intermittently at all (i.e., call fireUntilHalt()).-W2012/2/28 Edson Tirelli <ed.tirelli@gmail.com>This is tricky indeed and it is part of the design decisions we had to make. When you have a rule:whenX()The rule cares about X. Whether X is an event or fact, whether X is in a sliding window was simply expired by the expiration policy. Because the rule cares about X, X has to be correct and the rule has to be fired for X unless it is explicitly retracted.When you have a rule that says:whenList() from collect(X() ...)The rule does not care about the elements of the List individually, the rule cares about the List of elements. Quoting the text above: "Because the rule cares about the List, the List has to be correct", i.e., reflect the current content at the time it fires.It is hard to see on paper, but as soon as you start applying it to use cases, it makes sense. For instance, you want to fire a rule to call the firefighters if the fire alarm is sounding. Even if it takes some time to do it, you want to call the fire fighters. On the other hand, you want to turn on the sprinklers if the average temperature is above X degrees... but since the time it raised over X degrees, something happened and the temperature lowered to under X degrees, so you don't want to turn on the sprinklers anymore because the current temperature is under the threshold, even if it was over in the past.It is tricky and there is no single right or wrong answer on this. It was a design decision.
Edson2012/2/28 Wolfgang Laun <wolfgang.laun@gmail.com>
OK, I suspected as much.But how do you explain that the List that's collected at T=4 byList() from collect( Event() over window(2) )contains just one element? This means that the same pattern "Event over window(2)" produces two different sets of facts, at the same time!(I don't think that "expiry" is a good term for an event "drifting out" of a window, but that's not the point.)-W2012/2/28 Edson Tirelli <ed.tirelli@gmail.com>Yes, the misunderstanding is that an expiration is not a retract. Expiration does not cancel an activation. Retract does. So if you received an event dated T1, it match your pattern and the rule will activate. Then you receive event dated T3 and your rule activates again for the new event. Then when the clock advances to T4, the event at T1 expires and will not create any **new** matches for the rule, but it respects the activation that was **already created**. Then you fireAllRules() at time T4 and it will fire the 2 existing activations.This happens because of the 2-phase execution of the engine and the need to unify the semantics of event processing and rules processing. Imagine that the engine was, because of forward chaining, executing a long sequence of high priority activations that prevented the rule in discussion of being fired at time T1...T3. Only at T4 the engine had CPU cycles to execute the rule for event T1. If event expiration would cancel the activation, the engine would completely miss the rule execution because of lack of processing power. This is an extreme example, but perfectly illustrates what happens with events that expire immediately or within a few milliseconds.The application can also be designed to run in cycles, waiting as much as it wants to fireAllRules(), because it is guaranteed that it will not miss any events because of that.On the other hand, if you were running the engine with fireUntilHalt(), after inserting event T1, the activation would be created and fired asap.Key point: expiration != retractionHope it helps,EdsonOn Tue, Feb 28, 2012 at 11:05 AM, Wolfgang Laun <wolfgang.laun@gmail.com> wrote:
I think there is a misunderstanding - expiry is not an issue.
We have two events, dated (say) 1 and 3 and it is now 4 o'clock and
the window looks back 2 units:
Event() over window:time(2)
This fires twice!
-W
On 28/02/2012, Edson Tirelli <ed.tirelli@gmail.com> wrote:
> This is correct and works as designed. Please note that a direct event
> expiration does NOT cause a rule to be cancelled. So using sliding windows
> in isolation will be useless:
>
> X() over window:time(...)
>
> Will activate and fire for every single X, and that is correct.
>
> Now, if you use sliding windows in combination with other CEs, then the
> results will be affected by the sliding window. This is perfectly clear
> with accumulate/collect, but also happens when you are using multiple
> patterns. For instance:
>
> X() over window:time( 1m )
> Y() over window:time( 1m )
>
> This will create pairs of [X,Y] only for the X's and Y's that happened
> in the last minute, as intended. An X that just happened will not match an
> Y that happened 2 minutes ago.
>
> Edson
>
>
>
> On Tue, Feb 28, 2012 at 7:18 AM, Wolfgang Laun
> <wolfgang.laun@gmail.com>wrote:
>
>> I can confirm (using 5.3.0) that after
>> advance the clock to 1
>> insert an event with timestamp 1,
>> advance the clock to 3
>> insert another one with timestamp 3
>> advance the clock to 4
>> fire all rules
>> a rule with
>> Event() over window:time( 2s )
>> will fire twice (2 times). There is no difference between STREAM and CLOUD
>> mode.
>>
>> Indeed, the documentation (Fusion, 2.6.1, Sliding Time Windows)
>> appears to tell another story: "Sliding Time Windows allow the user
>> to write rules that will only match events occurring in the last X
>> time units." This is quite explicit.
>>
>> Also, please note that firing all rules after each insertion produces
>> the expected results; the rule firings at T=3 and T=4 show only one
>> event in the window.
>>
>> Even more surprisingly, running a rule that collects over a sliding
>> window works as intuitively expected:
>> $l: List() from collect( Event() over window:time( 2s ) )
>> Here the List will never contain more than one element, even when the
>> simple pattern (shown above) fires twice.
>>
>> -W
>>
>>
>>
>>
>>
>> On 28/02/2012, Hassan <azbakh01@gmail.com> wrote:
>> > Hi guys,
>> >
>> > While trying to understand how slinding window work, I realize that all
>> > exemples are given with "accumulate" or "collect" functions , I din't
>> know
>> > why ??
>> >
>> > $a : List() from collect(Event1() over window:time(2s) from entry-point
>> > "point")
>> > // work
>> >
>> >
>> > Bur why
>> >
>> > $a : Event1() over window:time(2s) from entry-point "point")
>> >
>> >
>> > doesn't work ??!
>> >
>> > Thanks,
>> > Youssef AZBAKH
>> >
>> > --
>> > View this message in context:
>> > http://drools.46999.n3.nabble.com/Slinding-window-tp3783772p3783772.html
>> > Sent from the Drools: User forum mailing list archive at Nabble.com.
>> > _______________________________________________
>> > rules-users mailing list
>> > rules-users@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/rules-users
>> >
>> _______________________________________________
>> rules-users mailing list
>> rules-users@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 list
rules-users@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 list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@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 list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users