[rules-users] Slinding window !
Edson Tirelli
ed.tirelli at gmail.com
Tue Feb 28 13:50:19 EST 2012
:) That works... as it was the reason fireUntilHalt() was created.
Edson
2012/2/28 Wolfgang Laun <wolfgang.laun at gmail.com>
> 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()).
>
> -W
>
>
> 2012/2/28 Edson Tirelli <ed.tirelli at gmail.com>
>
>>
>> This is tricky indeed and it is part of the design decisions we had to
>> make. When you have a rule:
>>
>> when
>> X()
>>
>> 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:
>>
>> when
>> List() 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.
>>
>> Edson
>>
>>
>> 2012/2/28 Wolfgang Laun <wolfgang.laun at gmail.com>
>>
>>> OK, I suspected as much.
>>>
>>> But how do you explain that the List that's collected at T=4 by
>>> List() 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.)
>>>
>>> -W
>>>
>>> 2012/2/28 Edson Tirelli <ed.tirelli at 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 != retraction
>>>>
>>>> Hope it helps,
>>>> Edson
>>>>
>>>>
>>>> On Tue, Feb 28, 2012 at 11:05 AM, Wolfgang Laun <
>>>> wolfgang.laun at 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 at 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 at 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 at 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 at lists.jboss.org
>>>>> >> > https://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
>>>>> >
>>>>> _______________________________________________
>>>>> 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 list
>>>> rules-users at lists.jboss.org
>>>> https://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
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://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/20120228/0dfce2fd/attachment.html
More information about the rules-users
mailing list