1:45 a.m.
Greg,
I'm calling fireUntilHalt to have rules fired as soon as activations are created
in response to changes in working memory, and so that I dont have to call
fireAllRules individually. In general, the behavior of fireUntilHalt is what I
want, except for this one exception.
The issue, I believe, is that whenever rules are fired, the engine must respect
the salience of the rules as specified. To do this, it must wait until all
rules that are going to be activated in response to the working memory action
have been activated.
Norman
________________________________
From: Greg Barton <greg_barton(a)yahoo.com To: Rules
Users List <rules-users(a)lists.jboss.org Cc: Rules
Users List <rules-users(a)lists.jboss.org Sent:
Tue, October 5, 2010 5:03:33 PM
Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
The entire purpose of fireUntilHalt is to do exactly the opposite of what you
describe. :) Is there any compelling reason you're using it as opposed to just
calling fireAllRules?
GreG
On Oct 5, 2010, at 16:34, Norman C <rent_my_time(a)yahoo.com> wrote:
Whichever way, there is a considerable burden associated with writing the rules
and, possibly, inserts and retracts. I wonder what the benefits of having the
session run all the time are as opposed to simply let it fire until it stops;
then do the inserts and then fireUntilHalt again? If there is, I'd opt for the
addition of an atomic insertAll(Object... objects) and then none of this
hocus-pocus would be necessary.
-W
>GreG
>--- On Sun, 10/3/10, Wolfgang Laun
<wolfgang.laun(a)gmail.com> wrote:
>From: Wolfgang Laun <wolfgang.laun(a)gmail.com >Subject: Re: [rules-users] fireUntilHalt and timing of rule
activations
>To: "Rules Users List" <rules-users(a)lists.jboss.org >Date: Sunday, October 3, 2010, 4:23 AM
>There is another way of
associating a Latch object with rules, without having to
>store a reference to a Latch in objects:
>rule "CountAs"
>enabled ( $v )
>when
> Latch( $v : value )
> X( ... )
>then ... end
>At the beginning, insert Latch( false ), which blocks all
rules with this
>construction, or modify the Latch object to false before inserting more facts.
>Then, insert the facts, and, at the end, modify Latch to true.
> Latch latch = new Latch(
true );
> FactHandle fh = kSession.insert( latch );
> kSession.fireAllRules();
> latch.setValue( false );
> kSession.update( fh, latch );
>Of course, you can use multiple Latch objects, adding a
name field with a
>specific value, so that a latch applies to a subset of rules only:
>rule "CountAs"
>enabled ( $v )
>when
> Latch( name == "CountAs", $v : value )
> ...
>But be aware that changes to Latch objects will retrigger
rules that have fired
>previously; so with this approach you'll have to make sure to retract facts when
>they have been processed.
>-W
>2010/10/3 Greg Barton
<greg_barton(a)yahoo.com >Nope,
you're not missing anything. What you need is a control object of some
>sort thst's inserted after all of the "real" data is inserted. (See
attached
>project for an example.) Rules will look like this, if the control object is
>called BatchLatch and data objects A:
>rule "CountAs"
> dialect "java"
> salience -1
> when
> l : Latch()
> a : A( latch == l )
> then
> retract(a);
> l.incACount();
> System.out.println("Found an A in
" + bl);
>end
>Note
that the A object being processed is tied back to the latch. This is so
>multiple latches can be processed simultaneously and their processing won't be
>intermingled. This is necessary because there's no guarantee that two Latch
>objects aren't in working memory at once. (Though you could create a rule that
>enforces this.)
>GreG
>---
On Sat, 10/2/10, Norman C <rent_my_time(a)yahoo.com> wrote:
>>
From: Norman C <rent_my_time(a)yahoo.com >> Subject: [rules-users] fireUntilHalt and timing of
rule activations
>> To: rules-users(a)lists.jboss.org
>> Date: Saturday, October 2, 2010, 10:22 AM
>> Hi All,
> >>
In my app, I have a separate thread calling fireUntilHalt()
>> continuously. I
>> have quite a few rules, and I am using salience
extensively
>> to control the order
> >>
in which rules are executed. What I have seen (by adding
>> an event listener) is
>> that as a new fact is inserted, various rules are
>> activated. Often, the
>> fireUntilHalt will start executing fireNextItem in
>> DefaultAgenda before all of
>> the activations are complete. So if the rule with
the
>> highest salience
>> value hasn't been activated at this point, then
the first
>> rule to be fired isn't
> >>
the correct one.
> >>
This can be worked around by waiting for insert to return
>> and then calling
>> fireAllRules(). But it seems like the session should
>> block fireUntilHalt from
>> trying to execute activated rules until all
activations are
>> complete. Or am I
>> missing something here?
> >>
thanks,
>> Norman
> > >>
> > >>
_______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
> >
>_______________________________________________
>rules-users mailing list
>rules-users(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/rules-users
>-----Inline Attachment
Follows-----
>_______________________________________________
>rules-users mailing list
>rules-users(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/rules-users
>
>_______________________________________________
>rules-users mailing list
>rules-users(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
>rules-users mailing list
>rules-users(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/rules-users
Thanks for the suggestions. They all look like good ways to handle the
situation I described. However, they require modifying all of the rules to
check for the latch object and its state, which I would prefer not to do and
doesn't seem like would be necessary.
It seems to me that this is something that Drools can handle internally without
the rules having to be written this way. Since the rules engine processes rules
in a single thread, it's a concurrency issue. fireUntilHalt should be blocked
when a fact is inserted/updated/retracted, until all activations as a result of
that change in working memory are completed.
Thoughts?
Norman
________________________________
From: Wolfgang Laun <wolfgang.laun(a)gmail.comTo: Rules Users List <rules-users(a)lists.jboss.org Sent: Sun, October 3, 2010 10:51:08 PM
Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
2010/10/4 Greg Barton <greg_barton(a)yahoo.com
If you don't have some way of associating the data with a particular Latch it's
easy to get overlap when processing datasets. In general you need some way to
group the data together. You can avoid a back reference to the Latch by having
a Set of some sort in the Latch to which you add all data in the batch.
Which burdens all inserts and retracts to be accompanied by correpsonding
updates of the Set/Map.
If you use a Set backed by an IdentityHashMap the overhead is pretty small, and
rules look like this:
rule "CountAs"
dialect "java"
salience -1
when
l : Latch()
a : A( this memberOf l.dataSet )
then
retract(a);
l.incACount();
System.out.println("Found an A in " + l);
end
See attached project.
THough I like the cleverness of using the "data in matched objects alters rule
properties" trick, you could have just as easily had a "Latch(value ==
true)"
conditional, and that would be more clear,
It was meant to emphasize the role of Latch.value as an enabler for the rule in
contrast to a regular constraint being part of the application logic. YMMV ;-)
IMO. I'm curious to see of the enabled trick would perform better, though.