Re: [rules-users] fireUntilHalt and timing of rule activations

-----Original Message----- From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users- bounces(a)lists.jboss.org] On Behalf Of Edson Tirelli Sent: 06 October 2010 01:28 To: Rules Users List Subject: Re: [rules-users] fireUntilHalt and timing of rule activations 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(a)yahoo.com&gt;: > > 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.com&gt; > To: Rules Users List <rules-users(a)lists.jboss.org&gt; > 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&gt; >> >> 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(a)gmail.com&gt; wrote: >> >> From: Wolfgang Laun <wolfgang.laun(a)gmail.com&gt; >> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations >> To: "Rules Users List" <rules-users(a)lists.jboss.org&gt; >> 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&gt; >> >> 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&gt; wrote: >> >> >> >> > From: Norman C <rent_my_time(a)yahoo.com&gt; >> >> > 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 > > -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users