Re: [rules-users] Need clarification on how event expiration offset is calculated in 5.3.0.FINAL
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.tire...@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 stemb...@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@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Need clarification on how event expiration offset is calculated in 5.3.0.FINAL
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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Need clarification on how event expiration offset is calculated in 5.3.0.FINAL
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 stemb...@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@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users