[rules-users] Need clarification on how event expiration offset is calculated in 5.3.0.FINAL

Scott Embler stembler at gmail.com
Wed Dec 7 11:57:57 EST 2011


Hi,

I've recently started using some of the temporal operators that drools
supports (coincides, starts, finishes, during) and have had trouble with
events not being expired, causing severe memory consumption.
I'd first like to make sure that I'm using these operators appropriately,
so as a test case I have rules like:

declare A
  @role( event )
  @timestamp( timestamp )
  @duration( duration )
end

declare B
  @role( event )
  @timestamp( timestamp )
  @duration( duration )
end

rule "coincides events"
when
  $a: A() from entry-point "a"
  $b: B(this coincides $a) from entry-point "b"
then insert("coincides"); end

With classes like:

public class A{
        public final long timestamp;
        public final long duration;
        public A(long timestamp, long duration){
            this.timestamp = timestamp;
            this.duration = duration;
        }
}

//B is identical to A.

Using a knowledge base configured with stream mode, and a knowledge session
with a pseudo clock I'd run this test:

A a = new A(0, 1000);
B b = new B(0, 1000);

entryPointA.insert(a);
entryPointB.insert(b);
clock.advanceTime(1000, TimeUnit.MILLISECONDS);
ksession.fireAllRules();

In this test I'm expecting that the rule will fire to insert "coincides"
and expire both A and B.  But instead, "coincides" is inserted, B is
expired, but A remains in memory permanently.  If I use jvisualvm to
inspect the expirationOffset for A, I see that it is the Long.MAX value of
9223372036854775807.  This behavior persists even after adding an explicit
expiration to A.  I was under the impression that the offset would be zero
(of close to it) since Drools would only need to retain A until the clock
reaches A's endTimestamp.  The documentation does not cover the calculation
of event expiration in great detail, so have I missed something?  Thanks in
advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20111207/e79fca6b/attachment.html 


More information about the rules-users mailing list