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@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
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com