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

Scott Embler stembler at gmail.com
Thu Dec 8 10:16:10 EST 2011


Following up:

I verified that I am using STREAM mode on the knowledge base, that events
and rules are declared in the same package, and that the session clock is
in line with the events.  The behavior I described previously is still
present even after adding and explicit expiration.  I've created a JIRA at
https://issues.jboss.org/browse/JBRULES-3307 so that you can look into this
further.  Thanks for your quick response.

Scott

2011/12/7 Edson Tirelli <ed.tirelli at gmail.com>

>
>    Scott,
>
>    The event expiration algorithm in Drools works with compile time
> analysis of temporal constraints. It calculates the transitive closure on
> the temporal intervals created by each temporal constraint and from that it
> infers the required time for an event to stay in memory, expiring them
> after that. Some interactions are pretty hard to calculate manually, but as
> you already realized, you can enable the Drools MBeans and use jconsole (or
> visualvm as you mentioned) to inspect them.
>
>     In your case, first things first, I assume you are running the engine
> in STREAM mode? the default is CLOUD mode, and in CLOUD mode there is no
> expiration of events. Second, there was a bug in one of the released
> versions of Drools (I think 5.2 or 5.3) that was fixed after where the
> calculation was wrong if the events were in different packages. Finally,
> you are using external timestamps for the events (on its attributes), so
> make sure your clock is in line with the externally timestamped events.
>
>     If everything I mentioned is working as expected and your events are
> still not being expired, please try adding an explicit expiration policy
> (e.g., @expires( 1m ) ), and submit a bug (JIRA) with your findings.
>
>     Edson
>
> 2011/12/7 Scott Embler <stembler at gmail.com>
>
>> 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.
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>
>
> --
>   Edson Tirelli
>   JBoss Drools Core Development
>   JBoss by Red Hat @ www.jboss.com
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20111208/9196eb81/attachment.html 


More information about the rules-users mailing list