Re: [rules-users] fireUntilHalt() is halt forever
You are not writing rules - you are using rules to disguise the fact that you are using if statements to process your data. What is "droolsRequest" and how is it declared? If this were a real rule, it would be when DroolsRequest( address.stateCode == "MA" ) then ... no-loop is nonsense in a rule that doesn't update any WM data. -W On 21 August 2012 17:00, Rana wrote: > Here is the example > > rule "AndroGel Provider State" > no-loop true > salience 95 > agenda-group "AndroGel" > when > eval( droolsRequest.address.stateCode == "MA" ) > then > logging(); > drools.halt(); > end > > the other rule is very similar but for a different Agenda Group > > rule "Pradaxa Provider State" > no-loop true > salience 95 > agenda-group "Pradaxa" > when > eval( droolsRequest.address.stateCode == "MA" ) > then > logging(); > drools.halt(); > end > > In this case it is firing the Pradaxa rule and giving me the wrong output. > > Thanks. > > > > -- > View this message in context: > http://drools.46999.n3.nabble.com/fireUntilHalt-is-halt-forever-tp4019146p4019313.html > Sent from the Drools: User forum mailing list archive at Nabble.com. > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt() is halt forever
You can still have different change-sets pointing to different resources (you can share these resources too) for different kbases. Best Regards, Esteban Aliverti - Blog @ http://ilesteban.wordpress.com On Tue, Aug 21, 2012 at 5:21 PM, Rana wrote: > I am actually using ChangeSet, because we did not wanted the rule files to > loaded many times, rather load at once and use scanner to look for any > changes. > > > > -- > View this message in context: > http://drools.46999.n3.nabble.com/fireUntilHalt-is-halt-forever-tp4019146p4019317.html > Sent from the Drools: User forum mailing list archive at Nabble.com. > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt() is halt forever
I am actually using ChangeSet, because we did not wanted the rule files to loaded many times, rather load at once and use scanner to look for any changes. -- View this message in context: http://drools.46999.n3.nabble.com/fireUntilHalt-is-halt-forever-tp4019146p4019317.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt() is halt forever
Instead of grouping your rules using agenda-group maybe you could partition your kbase to only have the rules for a particular Product (?) Best Regards, Esteban Aliverti - Blog @ http://ilesteban.wordpress.com On Tue, Aug 21, 2012 at 5:00 PM, Rana wrote: > Here is the example > > rule "AndroGel Provider State" > no-loop true > salience 95 > agenda-group "AndroGel" > when > eval( droolsRequest.address.stateCode == "MA" ) > then > logging(); > drools.halt(); > end > > the other rule is very similar but for a different Agenda Group > > rule "Pradaxa Provider State" > no-loop true > salience 95 > agenda-group "Pradaxa" > when > eval( droolsRequest.address.stateCode == "MA" ) > then > logging(); > drools.halt(); > end > > In this case it is firing the Pradaxa rule and giving me the wrong output. > > Thanks. > > > > -- > View this message in context: > http://drools.46999.n3.nabble.com/fireUntilHalt-is-halt-forever-tp4019146p4019313.html > Sent from the Drools: User forum mailing list archive at Nabble.com. > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt() is halt forever
Here is the example rule "AndroGel Provider State" no-loop true salience 95 agenda-group "AndroGel" when eval( droolsRequest.address.stateCode == "MA" ) then logging(); drools.halt(); end the other rule is very similar but for a different Agenda Group rule "Pradaxa Provider State" no-loop true salience 95 agenda-group "Pradaxa" when eval( droolsRequest.address.stateCode == "MA" ) then logging(); drools.halt(); end In this case it is firing the Pradaxa rule and giving me the wrong output. Thanks. -- View this message in context: http://drools.46999.n3.nabble.com/fireUntilHalt-is-halt-forever-tp4019146p4019313.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt() is halt forever
On 21/08/2012, Rana wrote: > One question, my rules have the same facts, and this is why it is > activating > all the satisfied rules before firing. is there anyway to stop this. > How do you determine that there are many "satisfied rules"? And, if they are on the agenda after inserting facts, why don't they have to be fired? It's impossible to suggest anything without a representative sample. > I mean think about it. If I have million rules with same facts it will slow > down the application. I'll take you a million of hours to write a million of rules, or about 600 years of work. :) -W > > Please let me know. > > Thanks. > > > > -- > View this message in context: > http://drools.46999.n3.nabble.com/fireUntilHalt-is-halt-forever-tp4019146p4019308.html > Sent from the Drools: User forum mailing list archive at Nabble.com. > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt() is halt forever
Ok, it is working now. I don't know what was the problem. I guess the rules were not right before. One question, my rules have the same facts, and this is why it is activating all the satisfied rules before firing. is there anyway to stop this. I mean think about it. If I have million rules with same facts it will slow down the application. Please let me know. Thanks. -- View this message in context: http://drools.46999.n3.nabble.com/fireUntilHalt-is-halt-forever-tp4019146p4019308.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt() is halt forever
Is the consequence of the rule where you call drools.halt() really executed? -W On 21/08/2012, Rana wrote: > I mean to say is that, control does not come back to > workingMemory.fireUntillHalt(). It just hangs in the rule file itself. Does > not do anything at all. > > What is the use of that. > > If I write like halt in the rule then it should stop the rule firing and > control should be sent back to workingMemory.fireUntillHalt() and execute > whatever after that. > > Thanks. > > > > -- > View this message in context: > http://drools.46999.n3.nabble.com/fireUntilHalt-is-halt-forever-tp4019146p4019304.html > Sent from the Drools: User forum mailing list archive at Nabble.com. > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt() is halt forever
I mean to say is that, control does not come back to workingMemory.fireUntillHalt(). It just hangs in the rule file itself. Does not do anything at all. What is the use of that. If I write like halt in the rule then it should stop the rule firing and control should be sent back to workingMemory.fireUntillHalt() and execute whatever after that. Thanks. -- View this message in context: http://drools.46999.n3.nabble.com/fireUntilHalt-is-halt-forever-tp4019146p4019304.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt() is halt forever
On 20/08/2012, Rana wrote: > I am using Working Memory instead of kSession. And it is not working at > all. > It just hangs after drools.halt(); Well, halt() means "do not continue". What on earth do you expect? -W > > Please let me know about it. > > Thanks. > > > > -- > View this message in context: > http://drools.46999.n3.nabble.com/fireUntilHalt-is-halt-forever-tp4019146p4019290.html > Sent from the Drools: User forum mailing list archive at Nabble.com. > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt() is halt forever
I am using Working Memory instead of kSession. And it is not working at all. It just hangs after drools.halt(); Please let me know about it. Thanks. -- View this message in context: http://drools.46999.n3.nabble.com/fireUntilHalt-is-halt-forever-tp4019146p4019290.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt() is halt forever
Nope it is not working like that. I removed it. Using fireAll Thanks. -- View this message in context: http://drools.46999.n3.nabble.com/fireUntilHalt-is-halt-forever-tp4019146p4019153.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt() is halt forever
I guess you call kSession.fireUntilHalt(). This call should return after drools.halt() is called from one of the rules. Java code following this call should do whatever needs to be done. (I don't know what you mean by "retrieve the resources...".) -W On 15/08/2012, Rana wrote: > Thanks for your reply. > > Once all the rules of that file is good, then it should retrieve the > resources in the rule file but not the session. and then may be fire other > rule file. > > Thanks. > > > > -- > View this message in context: > http://drools.46999.n3.nabble.com/fireUntilHalt-is-halt-forever-tp4019146p4019148.html > Sent from the Drools: User forum mailing list archive at Nabble.com. > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt() is halt forever
Thanks for your reply. Once all the rules of that file is good, then it should retrieve the resources in the rule file but not the session. and then may be fire other rule file. Thanks. -- View this message in context: http://drools.46999.n3.nabble.com/fireUntilHalt-is-halt-forever-tp4019146p4019148.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt() is halt forever
Hi,
yes if you use : drools.halt();
that will stop the session.
What exactly do you want to achieve with that?
Cheers
On Wed, Aug 15, 2012 at 5:49 PM, Rana wrote:
> Hi my rule file is halt for ever. Can anybody tell me why. I debugged and
> saw
> that it is going into this method in DefaultAgenda.class
>
> public void fireUntilHalt(final AgendaFilter agendaFilter) {
>
> synchronized ( this.halt ) {
> if( !this.halt.get() ) this.halt.wait(); //it is
> halt here and waiting.
> }
>
>
> this is my rule file.
>
> http://drools.46999.n3.nabble.com/file/n4019146/rule_file.txtrule_file.txt
>
>
> Please help me out.
>
> Thanks.
>
>
>
> --
> View this message in context:
> http://drools.46999.n3.nabble.com/fireUntilHalt-is-halt-forever-tp4019146.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
--
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] fireUntilHalt() is halt forever
Hi my rule file is halt for ever. Can anybody tell me why. I debugged and saw
that it is going into this method in DefaultAgenda.class
public void fireUntilHalt(final AgendaFilter agendaFilter) {
synchronized ( this.halt ) {
if( !this.halt.get() ) this.halt.wait(); //it is
halt here and waiting.
}
this is my rule file.
http://drools.46999.n3.nabble.com/file/n4019146/rule_file.txt rule_file.txt
Please help me out.
Thanks.
--
View this message in context:
http://drools.46999.n3.nabble.com/fireUntilHalt-is-halt-forever-tp4019146.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] FireUntilHalt
Thanks for your comment, Edson. I have been using 5.3.0.Final. I could easily move to 5.4.0.Final but I don't see any of the 5.4.x branches at Maven Central. Is there another repository that has more up to date releases? Craig -- View this message in context: http://drools.46999.n3.nabble.com/FireUntilHalt-tp4018610p4018638.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] FireUntilHalt
Which Drools version are you using? There are no "secrets", but you have to be aware that in this mode rules will fire right away if they can. Also, if you are using 5.4.0.Final, please read another e-mail I sent to the list today, as there was a concurrency bug that was fixed in the 5.4.x branch that could cause NPE. Edson On Wed, Jul 11, 2012 at 10:16 PM, crajor wrote: > I have a fairly complicated drools program and I want to introduce temporal > reasoning to it. I spent a bit of time writing some proof-of-concept > programs to get the feel of fusion and then tried to slowly introduce > things > into my original drools program. When I changed my program from using > fireAllRules() to using fireUntilHalt() on a separate thread, I suddenly > get > failures in my unit tests. (My first thought was that there was a race > condition between my unit tests and the thread calling fireUntilHalt() so I > introduced a delay before my unit tests but no luck) > > Here are some of the behaviors I am seeing. > > 1) I occasionally get nullpointerexception from the thread running > fireUntilHalt() > 2) My lock-on-active rules aren't firing > > I have banged my head on this a while with no success. (I even tried > putting fireAllRules() in a loop because of suggestions I saw but no luck > and same behavior). My questions are, Is there a secret to using > fireUntilHalt() that I am not aware of? Can anybody point me to where I > can > educate myself on its proper use? > > BTW no persistence and no spring in the code at this point. > > Thanks, in advance, for any help you can provide. > > Craig > > -- > View this message in context: > http://drools.46999.n3.nabble.com/FireUntilHalt-tp4018610.html > Sent from the Drools: User forum mailing list archive at Nabble.com. > ___ > rules-users mailing list > rules-users@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] FireUntilHalt
I have a fairly complicated drools program and I want to introduce temporal reasoning to it. I spent a bit of time writing some proof-of-concept programs to get the feel of fusion and then tried to slowly introduce things into my original drools program. When I changed my program from using fireAllRules() to using fireUntilHalt() on a separate thread, I suddenly get failures in my unit tests. (My first thought was that there was a race condition between my unit tests and the thread calling fireUntilHalt() so I introduced a delay before my unit tests but no luck) Here are some of the behaviors I am seeing. 1) I occasionally get nullpointerexception from the thread running fireUntilHalt() 2) My lock-on-active rules aren't firing I have banged my head on this a while with no success. (I even tried putting fireAllRules() in a loop because of suggestions I saw but no luck and same behavior). My questions are, Is there a secret to using fireUntilHalt() that I am not aware of? Can anybody point me to where I can educate myself on its proper use? BTW no persistence and no spring in the code at this point. Thanks, in advance, for any help you can provide. Craig -- View this message in context: http://drools.46999.n3.nabble.com/FireUntilHalt-tp4018610.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] fireUntilHalt is doing busy wait and consuming 100% of one CPU core
Observed this on Drools 5.1.1 final when fireUntilHalt() is used. The issue is reported as 'Resolved' in post: "https://issues.jboss.org/browse/JBRULES-2756"; in Drools 5.2.0 M1. So tried the same on Drools 5.2.0 final & 5.2.0 M1. Also when I try to make the recommended code changes in drools-core in Jira-2756, the issue seems to me as not fixed. In all these cases, the system consumes 100% resources of one CPU core. Please let me know does this issue is resolved or not in the latter versions of Drools? -Prashant Badhe -- View this message in context: http://drools.46999.n3.nabble.com/fireUntilHalt-is-doing-busy-wait-and-consuming-100-of-one-CPU-core-tp3844714p3844714.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt and timing of rule activations
Another solution would be to have a simple rule matching an Object
that is a container of facts:
rule "synced bunch insert"
when
$fc : FactContainer( $facts : facts )
then
for( Object $f : $facts ){ insert( $f ); }
retract( $fc );
end
Threads just insert a FactContainer; so this is synced in all ways.
BTW: Having a session run continuously in a thread of its own may be a
necessity if there are timers active; thus just using fireAllRules may
not be a solution in all situations.
-W
On 6 October 2010 10:15, Swindells, Thomas wrote:
> 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-boun...@lists.jboss.org [mailto:rules-users-
>> boun...@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 :
>> >
>> > 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
>> > To: Rules Users List
>> > Sent: Sun, October 3, 2010 10:51:08 PM
>> > Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>> >
>> > 2010/10/4 Greg Barton
>> >>
>> >> 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 ;-)
>> >
>> >
>&
Re: [rules-users] fireUntilHalt and timing of rule activations
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-boun...@lists.jboss.org [mailto:rules-users-
> boun...@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 :
> >
> > 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
> > To: Rules Users List
> > Sent: Sun, October 3, 2010 10:51:08 PM
> > Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
> >
> > 2010/10/4 Greg Barton
> >>
> >> 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 wrote:
> >>
> >> From: Wolfgang Laun
> >> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
> >> To: "Rules Users List"
> >> Date: Sunday, October 3, 2010, 4:23 AM
> >>
> >&
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
To: Rules Users List
Sent: 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
>
>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
>
>To: Rules Users List
>Sent: Sun, October 3, 2010 10:51:08 PM
>
>Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>
>
>2010/10/4 Greg Barton
>
>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 wrote:
>
>From: Wolfgang Laun
>Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>To: "Rules Users List"
>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.
Re: [rules-users] fireUntilHalt and timing of rule activations
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
To: Rules Users List
Cc: Rules Users List
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 wrote:
>
>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
>To: Rules Users List
>Sent: Sun, October 3, 2010 10:51:08 PM
>Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>
>2010/10/4 Greg Barton
>
>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 wrote:
>
>From: Wolfgang Laun
>Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>To: "Rules Users List"
>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
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
>
> 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
> *To:* Rules Users List
> *Sent:* Sun, October 3, 2010 10:51:08 PM
>
> *Subject:* Re: [rules-users] fireUntilHalt and timing of rule activations
>
> 2010/10/4 Greg Barton
>
>> 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 wrote:
>>
>> From: Wolfgang Laun
>> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>> To: "Rules Users List"
>> 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 pro
Re: [rules-users] fireUntilHalt and timing of rule activations
Edson, thanks for the reply. I've logged a ticket:
https://jira.jboss.org/browse/JBRULES-2723
Basically, this is how I'm working around the issue for now.
Thanks,
Norman
- Original Message
From: Edson Tirelli
To: Rules Users List
Sent: Tue, October 5, 2010 5:27:58 PM
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 :
>
> 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
> To: Rules Users List
> Sent: Sun, October 3, 2010 10:51:08 PM
> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>
> 2010/10/4 Greg Barton
>>
>> 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 wrote:
>>
>> From: Wolfgang Laun
>> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>> To: "Rules Users List"
>> 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 );
>>
>&g
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 :
>
> 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
> To: Rules Users List
> Sent: Sun, October 3, 2010 10:51:08 PM
> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>
> 2010/10/4 Greg Barton
>>
>> 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 wrote:
>>
>> From: Wolfgang Laun
>> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>> To: "Rules Users List"
>> 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 )
>> ...
&
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 wrote:
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
To: Rules Users List
Sent: Sun, October 3, 2010 10:51:08 PM
Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
2010/10/4 Greg Barton
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 wrote:
From: Wolfgang Laun
Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
To: "Rules Users List"
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
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&#
Re: [rules-users] fireUntilHalt and timing of rule activations
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
To: Rules Users List
Sent: Sun, October 3, 2010 10:51:08 PM
Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
2010/10/4 Greg Barton
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 wrote:
>
>From: Wolfgang Laun
>Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>To: "Rules Users List"
>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
>
>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 " +
Re: [rules-users] fireUntilHalt and timing of rule activations
2010/10/4 Greg Barton
> 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 wrote:
>
> From: Wolfgang Laun
> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
> To: "Rules Users List"
> 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
>
> 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 wrote:
>
>
>
> > From: Norman C
>
> > Subject: [rules-users] fireUntilHalt and timing of rule activations
>
> > To: rules-users@lists.jboss.org
>
> > Date: Saturday, October 2, 2010, 10:22 AM
>
> > Hi All,
>
> >
>
> > In my app, I have a s
Re: [rules-users] fireUntilHalt and timing of rule activations
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. 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, IMO. I'm curious to see of the
enabled trick would perform better, though.
GreG
--- On Sun, 10/3/10, Wolfgang Laun wrote:
From: Wolfgang Laun
Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
To: "Rules Users List"
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
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 wrote:
> From: Norman C
> Subject: [rules-users] fireUntilHalt and timing of rule activations
> To: rules-users@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
___
rules-users mailing list
rules-users@lists.jboss.org
https://
Re: [rules-users] fireUntilHalt and timing of rule activations
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
> 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 wrote:
>
> > From: Norman C
> > Subject: [rules-users] fireUntilHalt and timing of rule activations
> > To: rules-users@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@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
>
>
>
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt and timing of rule activations
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 wrote:
> From: Norman C
> Subject: [rules-users] fireUntilHalt and timing of rule activations
> To: rules-users@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
DroolsContinuousBatch.tar.gz
Description: GNU Zip compressed data
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] fireUntilHalt and timing of rule activations
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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt() and OSGi - CPU load
Thanks for your confirmation. Can anyone else report a case like that? I
didn't progress much in finding an explanation so far. If anyone else could
confirm, maybe this is some kind of common problem, maybe even a bug?
Is there something like a public issue tracker? Still, more cases would help,
don't want to bug developers offering such a great project and in the end it
turns out that I made a mistake...
Have a nice weekend everyone!
-Ursprüngliche Nachricht-
Von: rules-users-boun...@lists.jboss.org
[mailto:rules-users-boun...@lists.jboss.org] Im Auftrag von mardo
Gesendet: Freitag, 13. August 2010 14:46
An: rules-users@lists.jboss.org
Betreff: Re: [rules-users] fireUntilHalt() and OSGi - CPU load
"When invoking fireUntilHalt() for my StatefulKnowledgeSession, CPU load
rises to 25% (meaning one complete core on the quad-core machine)."
I can confirm this issue. Below is a minimal example. I have noticed that in
DefaultAgenda, missedNotifyAll is always true in this case, is this an
intended behaviour?
http://www.jboss.org/drools";
typeLanguage="http://www.java.com/javaTypes";
expressionLanguage="http://www.mvel.org/2.0";
xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL";
xmlns:xs="http://www.w3.org/2001/XMLSchema-instance";
xs:schemaLocation="http://www.omg.org/spec/BPMN/20100524/MODEL
BPMN20.xsd"
xmlns:g="http://www.jboss.org/drools/flow/gpd";
xmlns:tns="http://www.jboss.org/drools";>
john
public void test() throws InterruptedException{
try {
// load up the knowledge base
KnowledgeBase kbase = readKnowledgeBase();
final StatefulKnowledgeSession ksession =
kbase.newStatefulKnowledgeSession();
WSHumanTaskHandler wsh = new WSHumanTaskHandler();
wsh.setConnection("127.0.0.1", 9123);
ksession.getWorkItemManager().registerWorkItemHandler("Human Task", wsh);
new Thread(new Runnable() {
public void run() {
ksession.fireUntilHalt();
}
}).start();
ksession.startProcess("servicerequest2");
} catch (Throwable t) {
t.printStackTrace();
}
Thread.sleep(120);
}
private static KnowledgeBase readKnowledgeBase() throws Exception {
KnowledgeBuilder kbuilder =
KnowledgeBuilderFactory.newKnowledgeBuilder();
kbuilder.add(ResourceFactory.newClassPathResource("testcases/integrationuc/se
rvicerequest.bpmn"),
ResourceType.BPMN2);
return kbuilder.newKnowledgeBase();
}
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/fireUntilHalt-and-OSGi-CP
U-load-tp1022352p1131701.html
Sent from the Drools - User mailing list archive at Nabble.com.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] fireUntilHalt() and OSGi - CPU load
"When invoking fireUntilHalt() for my StatefulKnowledgeSession, CPU load
rises to 25% (meaning one complete core on the quad-core machine)."
I can confirm this issue. Below is a minimal example. I have noticed that in
DefaultAgenda, missedNotifyAll is always true in this case, is this an
intended behaviour?
http://www.jboss.org/drools";
typeLanguage="http://www.java.com/javaTypes";
expressionLanguage="http://www.mvel.org/2.0";
xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL";
xmlns:xs="http://www.w3.org/2001/XMLSchema-instance";
xs:schemaLocation="http://www.omg.org/spec/BPMN/20100524/MODEL
BPMN20.xsd"
xmlns:g="http://www.jboss.org/drools/flow/gpd";
xmlns:tns="http://www.jboss.org/drools";>
john
public void test() throws InterruptedException{
try {
// load up the knowledge base
KnowledgeBase kbase = readKnowledgeBase();
final StatefulKnowledgeSession ksession =
kbase.newStatefulKnowledgeSession();
WSHumanTaskHandler wsh = new WSHumanTaskHandler();
wsh.setConnection("127.0.0.1", 9123);
ksession.getWorkItemManager().registerWorkItemHandler("Human Task", wsh);
new Thread(new Runnable() {
public void run() {
ksession.fireUntilHalt();
}
}).start();
ksession.startProcess("servicerequest2");
} catch (Throwable t) {
t.printStackTrace();
}
Thread.sleep(120);
}
private static KnowledgeBase readKnowledgeBase() throws Exception {
KnowledgeBuilder kbuilder =
KnowledgeBuilderFactory.newKnowledgeBuilder();
kbuilder.add(ResourceFactory.newClassPathResource("testcases/integrationuc/servicerequest.bpmn"),
ResourceType.BPMN2);
return kbuilder.newKnowledgeBase();
}
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/fireUntilHalt-and-OSGi-CPU-load-tp1022352p1131701.html
Sent from the Drools - User mailing list archive at Nabble.com.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] fireUntilHalt() and OSGi - CPU load
Hi, I am using Drools 5.1 (final) in an OSGi environment. When invoking fireUntilHalt() for my StatefulKnowledgeSession, CPU load rises to 25% (meaning one complete core on the quad-core machine). Needless to say, when two sessions are used in different components at the same time I'm reaching about 50%. When creating an "ordinary" Drools project and using a StatefulKnowledgeSession with fireUntilHalt() I do not experience this problem. Anyone experienced something similar or has some advice for me? Any help would be highly appreciated :-) Thanks in advance! Cheers, Georg ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
