Hi Edson,
If I really understood, In the first case, the windows *are moving in time*
so all events found are activated, and are not retracted from the agenda
even after their duration.
so that:
*$a : Event1() over window:time(2s)*
firs all events.
In the second case (with accumulate/collect
Hi Edson,
If I really understood, In the first case, the windows are moving in time so
all events found are activated, and are not retracted from the agenda even
after their expiration.
so that:
$a : Event1() over window:time(2s)
fires all events.
In the second case (with
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
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
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
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
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
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
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
:) That works... as it was the reason fireUntilHalt() was created.
Edson
2012/2/28 Wolfgang Laun wolfgang.l...@gmail.com
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
10 matches
Mail list logo
