[rules-users] Slinding window !

Edson Tirelli ed.tirelli at gmail.com
Tue Feb 28 13:02:11 EST 2012 

   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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20120228/3dfb2d1e/attachment.html

More information about the rules-users mailing list