Re: [rules-users] Slinding window !

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