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
>
>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
>
>> 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] Better Performance and Maintainability?
I think you've basically answered your own question. POJOs that contains simple property getters and setters will always be faster than a hash lookup. They would also be smaller in size, assuming you avoid complicated reference hierarchies, because hash maps create container objects behind the scene. POJOs also help avoid the need to convert objects to specific types. Lastly, if a POJO is more likely to be maintainable because your java and drools compiler can tell you when you've made a mistake, but a compiler cannot check for the correct key or value of a hash map. HonorGod wrote: > Hi, > > Can someone plz help me understand performance and maintainability in the > following scenario - ? > > I load tons of rows of data from database and store them in an object fact > model [POJO based] and apply the rules using decision tables and finally > persist data. > > vs > > I load tons of rows of data from database and store them in an object fact > model [HashMap - Key - Value] and apply the rules using decision tables and > finally persist data. > > The difference in the above two scenarios is that one of them is pojo based > and the other is key-value pairs that are used on LHS of the decision > tables. When I use Key-Value approach I had to do lot of conversion in terms > converting the conditions into eval statements and validations but where as > the pojo approach is very straight forward and less validations. > > Which approach gives me better performance and maintainability? > > I would consider the following before I make a decision - > > 1 - size of data > 2 - frequency at which the data changes [in terms of adding new conditions / > adding new columns / removal of new columns etc] > 3 - re-usability > > Thank You! > > -- Scott Embler Software Engineer, ERT Inc., Government Contractor Climate Monitoring Branch National Climatic Data Center 151 Patton Ave. Asheville, NC 28801-5001 scott.emb...@noaa.gov (828)350-2027 ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
