<br> Yes, we probably need to explain that better. There is a semantic difference between fact (event) retract and event expiration. An event expiration does not cancel existing activations. That happens because if a condition was detected, it should be handled, even if the application decides to delay the handling by not firing the rules immediately. This way, the events are kept in memory, although removed from the partial matches (improving match performance), and are removed after their rules are fired.<br>
<br> Also, depending on the model you are using (single vs multile threads), the actual expiration might wait for the next action in the working memory to happen so that the thread can be "borrowed" to execute the expiration. That happens to ensure determinism and proper concurrency handling on single threaded mode.<br>
<br> Edson<br><br><div class="gmail_quote">2009/10/30 richarda <span dir="ltr"><<a href="mailto:richard.ambridge@gmail.com">richard.ambridge@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I wanted to post something I found in case others are scratching their heads<br>
on this.<br>
<br>
Drools Fusion user guide indicates:<br>
<br>
2.8.2. Inferred expiration offset<br>
Another way for the engine to calculate the expiration offset for a given<br>
event is implicitly, by analyzing the temporal constraints in the rules.<br>
<br>
<br>
So I needed to check that my rules were working correctly, so I setup some<br>
temporal rules and after adding some events and firing the rules, I put my<br>
code into a loop:<br>
while (true) {<br>
Thread.sleep(10000);<br>
for (FactHandle h : ksession.getFactHandles()) {<br>
System.out.println(" :" + h.toString());<br>
}<br>
}<br>
<br>
To hope to find that there were no Events left in working memory after all<br>
the time periods have passed.<br>
<br>
but they were always showing as still in memory..<br>
<br>
After spending ages trying to understand my rules, I found that the Events<br>
are not expired until the next call of ksession.fireAllRules()<br>
which makes sense..<br>
<br>
Perhaps that should be added to the manual?<br>
<br>
Cheers<br>
Ric<br>
<font color="#888888">--<br>
View this message in context: <a href="http://old.nabble.com/Events-are-not-automatically-expiring-from-working-memory-tp26131877p26131877.html" target="_blank">http://old.nabble.com/Events-are-not-automatically-expiring-from-working-memory-tp26131877p26131877.html</a><br>
Sent from the drools - user mailing list archive at Nabble.com.<br>
<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br> Edson Tirelli<br> JBoss Drools Core Development<br> JBoss by Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a><br>