[rules-users] Slinding window !

Tue Feb 28 11:42:01 EST 2012

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