[rules-users] fireUntilHalt and timing of rule activations
Edson Tirelli
tirelli at post.com
Tue Oct 5 20:27:58 EDT 2010
Norman,
What you say makes sense, but it is not implemented. It is
something I think would be good to have. May I suggest you open a JIRA
for it so we track it?
Meanwhile, the workaround I suggest is that instead of using
fireUntilHalt(), you call fireAllRules() in a loop, either after each
X insertions of every Y seconds, depending on your system's
architecture.
Edson
2010/10/5 Norman C <rent_my_time at yahoo.com>:
>
> 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 at gmail.com>
> To: Rules Users List <rules-users at 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 at 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.
>
> 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 at gmail.com> wrote:
>>
>> From: Wolfgang Laun <wolfgang.laun at gmail.com>
>> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>> To: "Rules Users List" <rules-users at 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 at 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 at yahoo.com> wrote:
>>
>>
>>
>> > From: Norman C <rent_my_time at yahoo.com>
>>
>> > Subject: [rules-users] fireUntilHalt and timing of rule activations
>>
>> > To: rules-users at 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 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
>>
>>
>>
>>
>>
>> -----Inline Attachment Follows-----
>>
>> _______________________________________________
>> 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
>>
>
>
>
> _______________________________________________
> 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
More information about the rules-users
mailing list