Re: [rules-users] Slinding window !
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 ), these functions are applied first in the moment of firing events in the agenda, and the sliding windows is applied after so it will be applied *in one point in time*, therfore only events occurring in the interval* ]DateOfFire-2s,DateOfFire]* will be activated anf afer fired. Please Edson tell me if this is exactly what the documentation means ?? -- View this message in context: http://drools.46999.n3.nabble.com/Slinding-window-tp3783772p3786723.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
Re: [rules-users] Slinding window !
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 accumulate/collect ), these functions are applied in the moment of firing, so they will consider the last window before firing events which is the interval *]DateOfFire-2s,DateOfFire]* therefore only events occurring in this interval will be fired. Please Edson tell me if this is exactly what the documentation means ?? -- View this message in context: http://drools.46999.n3.nabble.com/Slinding-window-tp3783772p3786755.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
Re: [rules-users] Slinding window !
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
Re: [rules-users] Slinding window !
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.comwrote: 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
Re: [rules-users] Slinding window !
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.comwrote: 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
Re: [rules-users] Slinding window !
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.comwrote: 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.comwrote: 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
Re: [rules-users] Slinding window !
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.comwrote: 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.comwrote: 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:
Re: [rules-users] Slinding window !
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.comwrote: 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.comwrote: 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
Re: [rules-users] Slinding window !
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
Re: [rules-users] Slinding window !
:) 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 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
