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.
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.
Edson
2009/10/30 richarda <richard.ambridge(a)gmail.com>
I wanted to post something I found in case others are scratching their
heads
on this.
Drools Fusion user guide indicates:
2.8.2. Inferred expiration offset
Another way for the engine to calculate the expiration offset for a given
event is implicitly, by analyzing the temporal constraints in the rules.
So I needed to check that my rules were working correctly, so I setup some
temporal rules and after adding some events and firing the rules, I put my
code into a loop:
while (true) {
Thread.sleep(10000);
for (FactHandle h : ksession.getFactHandles()) {
System.out.println(" :" + h.toString());
}
}
To hope to find that there were no Events left in working memory after all
the time periods have passed.
but they were always showing as still in memory..
After spending ages trying to understand my rules, I found that the Events
are not expired until the next call of ksession.fireAllRules()
which makes sense..
Perhaps that should be added to the manual?
Cheers
Ric
--
View this message in context:
http://old.nabble.com/Events-are-not-automatically-expiring-from-working-...
Sent from the drools - user mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @
www.jboss.com