[jboss-jira] [JBoss JIRA] (JBRULES-3075) window:length windows retaining events when they shouldnt

[RH Bugzilla Integration (JIRA)]

    [ https://issues.jboss.org/browse/JBRULES-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664654#comment-12664654 ] 

RH Bugzilla Integration commented on JBRULES-3075:
--------------------------------------------------

Edson Tirelli <etirelli at redhat.com> made a comment on [bug 787118|https://bugzilla.redhat.com/show_bug.cgi?id=787118]

Tomas, there are some misunderstandings with this test case:

* Up to Drools 5.3, all windows are declared inline in the rules, as in your example, BUT the order in which the operations are applied is the following:

1. first all filters are applied (e.g., company == 'RHT')
2. then the window is created out of the events that match the filters
3. then the beta constraints are applied (i.e. joins)

The example of using "not" with an inline window is semantically incorrect:

not( StockTick( company == 'RHT' ) over window:length(3) )

Since the filter (company == 'RHT') is applied first, all the events that will compose the window of length 3 will always be RHT events, and so, the window declaration is redundant in this case. The above is exactly the same as writing:

not( StockTick( company == 'RHT' ) )

To correctly define a rule that states "if there is no RHT stock ticks in the last 3 StockTicks", up to Drools 5.3, one needs to use 2 patterns:

when
    not( $st : StockTick() over window:length(3) and
         StockTick( this == $st, company == "RHT" )
    )
then

We understand that this is verbose and confusing, as well as heavier at runtime than it would be necessary. This is one of the reasons that we added named windows to Drools 5.4. 

>From Drools 5.4+, named windows can be declared outside rules. So, for instance, the above window could be defined like:

declare window ticks
    StockTick() over window:length(3)
end

And then it becomes clear what belongs to the window and what does not. Rules then can reference that window appropriately:

when
    not( StockTick( company == "RHT" ) from window ticks )
then

Behind the scenes, a new algorithm also makes the execution of such windows much more performant, as well as improves the sharing of window definitions among multiple rules.

* The second misunderstanding is that the expiration of events only happens based on temporal constraints in Drools. Since the test does not define any temporal constraints or expiration policies (a window:length is not a temporal constraint), the events are retained in memory until explicitly retracted. Support to new types of expiration policies are in our roadmap and will be available in newer versions (e.g., retain only the last 3 events, retain unique events, etc).
                
> window:length windows retaining events when they shouldnt
> ---------------------------------------------------------
>
>                 Key: JBRULES-3075
>                 URL: https://issues.jboss.org/browse/JBRULES-3075
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (fusion)
>    Affects Versions: 5.2.0.CR1
>         Environment: win64, jdk 6u24
>            Reporter: Radai Rosenblatt
>            Assignee: Mark Proctor
>         Attachments: drools length window bug.zip
>
>
> using the following DRL:
> package contrived.example
> import contrived.example.EventWithTimestamp
> declare EventWithTimestamp
>     @role(event)
> 	@duration( duration )
>     @timestamp( timestamp )
> end
> rule "no event in window"
> when
>     not EventWithTimestamp (someProp=="whatever") over window:length(3) from entry-point "Event Stream"
> then
>     System.err.println("retract");
> end
> if we start with an initial matching (someProp=="whatever") event and fire a long sequence of non-matching events:
> {"something else", "something else" ... "something else"}
> the rule should fire sometime into the long chain of "something else" events (it should fire after the 3rd such event - when the window contains 3 non-matching events and the 1st matching event has been pushed out).
> in practice the rule never fires. worse, it also retains all the events in memory when it should only keep the last 3.
> to reproduce the issue, simply build the attached maven project (mvn clean install)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira