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

Wolfgang, so I don't improperly interpret your suggestion, it may be better if you add your suggestion to the ticket.  This is the ticket I logged: https://jira.jboss.org/browse/JBRULES-2723 Thanks, Norman ________________________________ From: Wolfgang Laun <wolfgang.laun(a)gmail.comTo: Rules Users List <rules-users(a)lists.jboss.orgSent: Tue, October 5, 2010 11:34:53 PM Subject: Re: [rules-users] fireUntilHalt and timing of rule activations Norman, if you create the Jira, please include my suggestion to make this call accept a collection of facts without any intervening Engine activity. Thanks -W 2010/10/5 Norman C <rent_my_time(a)yahoo.com ________________________________ 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: 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>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&gt; 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 &gt;rules-users(a)lists.jboss.org >https://lists.jboss.org/mailman/listinfo/rules-users >-----Inline Attachment Follows----- >_______________________________________________ >rules-users mailing list &gt;rules-users(a)lists.jboss.org >https://lists.jboss.org/mailman/listinfo/rules-users >      >_______________________________________________ >rules-users mailing list &gt;rules-users(a)lists.jboss.org >https://lists.jboss.org/mailman/listinfo/rules-users >_______________________________________________ >rules-users mailing list &gt;rules-users(a)lists.jboss.org >https://lists.jboss.org/mailman/listinfo/rules-users