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(a)gmail.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

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(a)gmail.com&gt; 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(a)gmail.com&gt;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(a)gmail.com&gt; 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(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/rules-users >> > >> _______________________________________________ >> rules-users mailing list >> rules-users(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

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(a)gmail.com&gt; > > 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(a)gmail.com&gt;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(a)gmail.com&gt; 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(a)gmail.com&gt;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(a)gmail.com&gt; 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(a)lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/rules-users >> >> > >> >> _______________________________________________ >> >> rules-users mailing list >> >> rules-users(a)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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

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(a)gmail.com&gt; > > 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(a)gmail.com&gt; > >> 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(a)gmail.com&gt; >> >>> >>> 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt;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(a)gmail.com&gt; 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(a)lists.jboss.org >>>> >> > https://lists.jboss.org/mailman/listinfo/rules-users >>>> >> > >>>> >> _______________________________________________ >>>> >> rules-users mailing list >>>> >> rules-users(a)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(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users