<div><br></div> 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.<div>
<br></div><div> 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:</div>
<div><br></div><div>* If you are running fireUntilHalt(), the rules will fire asap, depending on the conflict resolution with other rules.</div><div><br></div><div>* 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.</div>
<div><br></div><div> Hope it is clear.</div><div><br></div><div> Edson<br><br><div class="gmail_quote">2011/10/14 Wolfgang Laun <span dir="ltr"><<a href="mailto:wolfgang.laun@gmail.com">wolfgang.laun@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On 14 October 2011 06:31, slyfox <span dir="ltr"><<a href="mailto:bobby.richards@gmail.com" target="_blank">bobby.richards@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
thanks for the response, that makes a little more sense. That is an issue<br>
because the whole idea of CEP is to process events as they happen. My next<br>
step is adding camel support so that I can consume the amqp feed without<br>
manually inserting into the session. I guess fireuntilhalt is my only<br>
option. But what does fire until halt do, is it just a continuous loop or<br>
is is smart enough to only process events when they come in?<br></blockquote></div><div><br>There is one reasons for the thread running a Drools engine until halt <br>to become active: when a fact is inserted. After doing the work resulting<br>
from this, the thread falls back into suspension.<br><br></div><div class="im"><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<br>
so what would happen if the event is given an expiration of say 2 seconds?<br>
if you were calling fireallrules in anything over a 2 second interval you<br>
would miss a lot.<br></blockquote></div><div><br>An event that has expired any time before you fireAllRules is discarded<br>soon after this call is entered. What could you "miss" in the time between<br>the scheduled expiry and the actual removal?<br>
<br>Note that any application that expects to produce real-time reactions<br>is bound to fireUntilHalt.<br><br></div><div class="im"><div> </div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
I do not really see the benefit of fusion then, seems like its redundant? I<br>
hope that I am missing something.<br></blockquote></div><div><br>There isn't really a "Fusion" thing. (Think of it as a marketing gag.)<br>The Drools Rule Engine is capable of dealing with facts that have the<br>
distinct traits of what is called "event": timestamp, duration and<br>expiry; the Engine is clever enough to retract stale events automatically,<br>and there's a set of operators for comparing numbers that may<br>
represent points in time with some fancy overlap options. If you don't<br>need anything of this, don't use it; OTOH, if you compare dates, just<br>using the temporal operators may help.<br><font color="#888888"> <br>
-W<br></font></div><div class="im"><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<font color="#888888"><br>
--<br>
View this message in context: <a href="http://drools.46999.n3.nabble.com/Fusion-appears-to-be-working-properly-but-tp3420043p3420701.html" target="_blank">http://drools.46999.n3.nabble.com/Fusion-appears-to-be-working-properly-but-tp3420043p3420701.html</a><br>
</font><div><div></div><div>Sent from the Drools: User forum mailing list archive at Nabble.com.<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org" target="_blank">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>
</div></div></blockquote></div></div><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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br> Edson Tirelli<br> JBoss Drools Core Development<br> JBoss by Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a><br>
</div>