[
https://issues.jboss.org/browse/JBRULES-3075?page=com.atlassian.jira.plug...
]
RH Bugzilla Integration commented on JBRULES-3075:
--------------------------------------------------
Edson Tirelli <etirelli(a)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