[rules-users] Fusion appears to be working properly, but...

[Edson Tirelli]

   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 at gmail.com>

> On 14 October 2011 06:31, slyfox <bobby.richards at gmail.com> wrote:
>
>> 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
>
>>
>> --
>> View this message in context:
>> http://drools.46999.n3.nabble.com/Fusion-appears-to-be-working-properly-but-tp3420043p3420701.html
>> Sent from the Drools: User forum mailing list archive at Nabble.com.
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>


-- 
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20111014/a4df2c00/attachment.html