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