Wolfgang is correct. Just an additional distinction that is important: expiring an event is different then retracting an event/fact. Imagine that there was a computer with infinite processing power and infinite memory. In that case, we would never need to expire any events, we would just keep them all in memory forever. This is obviously not the case, but it gives us the sense of "truth". An event represents something that happened and as so it is true. Since the past can't be changed, it will be true forever. So expiring an event is a way to optimize the resource consumption of the limited hardware we have, but it does not make events false. So any activation created due to events, will remain active until they are fired, even if the events that created it expire.
In other words: if your event has an expiration policy of 2 seconds, it comes into the system and activates rules for the next 2 seconds. After that time, that event will no longer create any other activation. Also:
* If you are running fireUntilHalt(), the rules will fire asap, depending on the conflict resolution with other rules.
* If you are running fireAllRules(), even if it takes 10 minutes for your application to fire the rules, they will still fire, because **expiration** of events do not cancel activations. **Retraction** of facts/events and **modifications** of facts might cause activations to be cancelled.
Hope it is clear.
Edson
2011/10/14 Wolfgang Laun
<wolfgang.laun@gmail.com>
thanks for the response, that makes a little more sense. That is an issue
because the whole idea of CEP is to process events as they happen. My next
step is adding camel support so that I can consume the amqp feed without
manually inserting into the session. I guess fireuntilhalt is my only
option. But what does fire until halt do, is it just a continuous loop or
is is smart enough to only process events when they come in?
There is one reasons for the thread running a Drools engine until halt
to become active: when a fact is inserted. After doing the work resulting
from this, the thread falls back into suspension.
so what would happen if the event is given an expiration of say 2 seconds?
if you were calling fireallrules in anything over a 2 second interval you
would miss a lot.
An event that has expired any time before you fireAllRules is discarded
soon after this call is entered. What could you "miss" in the time between
the scheduled expiry and the actual removal?
Note that any application that expects to produce real-time reactions
is bound to fireUntilHalt.
I do not really see the benefit of fusion then, seems like its redundant? I
hope that I am missing something.
There isn't really a "Fusion" thing. (Think of it as a marketing gag.)
The Drools Rule Engine is capable of dealing with facts that have the
distinct traits of what is called "event": timestamp, duration and
expiry; the Engine is clever enough to retract stale events automatically,
and there's a set of operators for comparing numbers that may
represent points in time with some fancy overlap options. If you don't
need anything of this, don't use it; OTOH, if you compare dates, just
using the temporal operators may help.
-W
_______________________________________________
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