[jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2288) Investigate a possible problem when using forall() with sliding windows

[ https://jira.jboss.org/jira/browse/JBRULES-2288?page=com.atlassian.jira.p... ] Edson Tirelli resolved JBRULES-2288. ------------------------------------ Resolution: Done A 'forall' conditional element is translated into a specific set of notes in the network. As an example, the following construction: forall( Bus( color == RED ) ) Is translated into: not( $bus : Bus( ) and not ( Bus( this == $bus, color == RED ) ) ) It happens that such a translation causes the rule to re-activate every time a new Bus is inserted (or retracted, depending on the order of the propagation) into the knowledge base, even if the rule was previously activated and fired. This behaviour is not consistent with the pure "not" and "exists" CEs. On a side note, though, other rules engines on the market behave in the exact same way. As an example, I checked the CLIPS open source rules engine. Nevertheless, Drools is the only mainstream engine that supports streams and sliding windows, AFAIK, and that problem seriously hinders the use of forall with sliding windows, where events arrive and expire all the time. Example: rule "ATM link is down" when forall( ATMEvents( link == DOWN ) over window:time( 1m ) ) then // send technician end Links may me unstable, so a single event saying the link is down is not a big deal, but if all events during a 1 minute time window indicate that the link is down, then something must be done. As you can see, the rule is pretty intuitive, but imagine the events arrive every 5 seconds. With the current forall behaviour, this rule would be re-activated and re-fired every 5 seconds, when in reality I (Edson) would expect it to only reactivate when the LHS changes from non-matching to matching in the same way that the "exists CE" and the "not CE" work. Given all that, I decided to change the behaviour of forall to be consistent with the behaviour of "not" and "exists". I.e., the rule only re-activates when the LHS changes state from non-matching to matching. In order to do that, I implemented a specialized "not" node (lets call it "forall_not") and the previous translation becomes: not( $bus : Bus( ) and forall_not ( Bus( this == $bus, color == RED ) ) ) The forall_not node is a regular not node with a twist: it does not propagate activations from the right when the activation is triggered by the base pattern, since the base pattern will trigger the left activation right after the right activation. This solved the problem and the behaviour is now fixed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira