[rules-users] fireUntilHalt and timing of rule activations
Swindells, Thomas
TSwindells at nds.com
Wed Oct 6 04:15:04 EDT 2010
I'd suggest that it may be simple to have a (synchronized) helper method which you call to insert your objects.
This method would create a batch command containing an insert command and a fireAllRules command. You only need to fire the rules after you have changed something and this approach removes all multithread access into the working memory.
Thomas
> -----Original Message-----
> From: rules-users-bounces at lists.jboss.org [mailto:rules-users-
> bounces at 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 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
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster at nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
More information about the rules-users
mailing list