[rules-users] No inferred expiration when correlating events in Drools Fusion

[Wolfgang Laun]

Subsection 8.8.2., Inferred expiration offset, sounds great when you
read it, and I'm sure that it has been implemented with a vengeance.
But, given the ever increasing complexity of the LHS language, who
can claim that the implementation is complete? Even the smallest
glitch can thwart the automatism. And, assuming that the implementation
is complete and correct, a single CE in a single rule can inhibit
automatic expiration for a fact, which alone is sufficient to create
a memory leak and may have a domino effect on others.

This, then, inevitably leads to the conclusion that using this feature
is a risky game. Use it if you are a gambler.

It would be much better if you could take out insurance, e.g., by an API
that answers the question whether automatic expiry is in effect
for a certain fact type.

-W


On 19/01/2014, Alexandre Gattiker <agattik at gmail.com> wrote:
> Hello,
>
> I am trying to use Drools Fusion (5.6.0 or 6.0.1) to correlate events, but
> can't get the internal mechanism for expiring events to work in my rule.
>
> I made up a simple example that detects duplicate messages over a short
> time window. The rule below seems to work fine, but facts accumulate
> indefinitely in the working memory. Changing window:length(1) to
> window:time(10s) does not solve the issue.
>
> declare DataEvent
>     @role(event)
> end
> rule "Detect duplicates"
> when
>    DataEvent ( $text: text ) over window:length(1)
>    ArrayList( size >= 2 ) from collect( DataEvent( text == $text )  over
> window:time( 10s ) )
> then
>     System.err.println("Duplicate detected");
> end
>
> Now, if I change my condition to the following, I see that facts
> automatically expire and are retracted after 10 seconds.
>
> ...when
>    ArrayList( size >= 10 ) from collect( DataEvent( )  over window:time(
> 10s ) )
> then...
>
> Many thanks in advance.
>