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