Pull request #92 was submitted

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).

Edson Tirelli <ed.tirelli> updated the status of jira JBRULES-3075 to Resolved

Edson Tirelli <ed.tirelli> made a comment on jira JBRULES-3075

I am closing this ticket as Drools 5.3 does not support non-temporal-based expiration policies. Also, there was a misunderstanding on the semantics of sliding window definition and usage as explained in my previous comment.

Edson Tirelli <ed.tirelli> updated the status of jira JBRULES-3075 to Closed

It seems there is another problem. I have submitted another pull request (#98) showing that such a rule is not activated. I also removed the assertions about WM size.

Firing the rules with empty WM is fine, but after inserting StockTick (company == 'RHT') the rule is not reactivated again even if the RHT StockTick event is past the window.
It works fine without entry points (plainly inserting it into ksession).

Could also the fact that facts falling off from length windows are not retracted automatically be mentioned in documentation? I have assumed that the facts are retracted from the last line of Drools Fusion documentation [1] which says "The engine will keep only the last 100 readings." which is misleading.



[1] http://docs.jboss.org/drools/release/5.3.0.Final/drools-fusion-docs/html/ch02.html#d0e1178

Tomas, 

" but after inserting StockTick (company == 'RHT') the rule is not reactivated again even if the RHT StockTick event is past the window."

I know it is confusing, and that is the reason we added the explicit window declaration in 5.4. If you read my previous comment, when a window is declared the way it is in your example, the filter "company == 'RHT'" is applied **before** the sliding window. So the events with companies other than RHT, will never reach the window and will never cause the ones in there to expire. This is why using the not() in that situation does not make sense.

I will update the documentation to try to explain this better.

Tomas,

I updated the documentation:

https://github.com/droolsjbpm/drools/commit/5fb2feeb1b7ccbbe0662aab3f1acf28885c63452

Hope this helps clarify the subject.

Update status to ON_QA. Please verify them against ER6.

This is fixed now.

This product has been discontinued or is no longer tracked in Red Hat Bugzilla.