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.tire...@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.l...@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.tire...@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.l...@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 <azbak...@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
