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
Is the consequence of the rule where you call drools.halt() really executed? -W On 21/08/2012, Rana ven12...@yahoo.com 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
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
On 21/08/2012, Rana ven12...@yahoo.com 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
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
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 ven12...@yahoo.com 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
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
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 ven12...@yahoo.com 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
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 ven12...@yahoo.com 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
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
On 20/08/2012, Rana ven12...@yahoo.com 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
[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() 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 ven12...@yahoo.com 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
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
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 ven12...@yahoo.com 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
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
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
[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
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 crjo...@sandia.gov 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 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 tswinde...@nds.com 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 rent_my_t...@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.l...@gmail.com
To: Rules Users List rules-users@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_bar...@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.l...@gmail.com wrote:
From: Wolfgang Laun wolfgang.l...@gmail.com
Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
To: Rules Users List rules-users@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
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 tire...@post.com To: Rules Users List rules-users@lists.jboss.org 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 rent_my_t...@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.l...@gmail.com To: Rules Users List rules-users@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_bar...@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.l...@gmail.com wrote: From: Wolfgang Laun wolfgang.l...@gmail.com Subject: Re: [rules-users] fireUntilHalt and timing of rule activations To: Rules Users List rules-users@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_bar...@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
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_t...@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.l...@gmail.com *To:* Rules Users List rules-users@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_bar...@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.l...@gmail.com wrote: From: Wolfgang Laun wolfgang.l...@gmail.com Subject: Re: [rules-users] fireUntilHalt and timing of rule activations To: Rules Users List rules-users@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_bar...@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
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 greg_bar...@yahoo.com To: Rules Users List rules-users@lists.jboss.org Cc: Rules Users List rules-users@lists.jboss.org 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 rent_my_t...@yahoo.com 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 wolfgang.l...@gmail.com To: Rules Users List rules-users@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_bar...@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.l...@gmail.com wrote: From: Wolfgang Laun wolfgang.l...@gmail.com Subject: Re: [rules-users] fireUntilHalt and timing of rule activations To: Rules Users List rules-users@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
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.l...@gmail.com To: Rules Users List rules-users@lists.jboss.org 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 rent_my_t...@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.l...@gmail.com To: Rules Users List rules-users@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_bar...@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.l...@gmail.com wrote: From: Wolfgang Laun wolfgang.l...@gmail.com Subject: Re: [rules-users] fireUntilHalt and timing of rule activations To: Rules Users List rules-users@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_bar...@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
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 rent_my_t...@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.l...@gmail.com To: Rules Users List rules-users@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_bar...@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.l...@gmail.com wrote: From: Wolfgang Laun wolfgang.l...@gmail.com Subject: Re: [rules-users] fireUntilHalt and timing of rule activations To: Rules Users List rules-users@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
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 wolfgang.l...@gmail.com To: Rules Users List rules-users@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_bar...@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.l...@gmail.com wrote: From: Wolfgang Laun wolfgang.l...@gmail.com Subject: Re: [rules-users] fireUntilHalt and timing of rule activations To: Rules Users List rules-users@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_bar...@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_t...@yahoo.com wrote: From: Norman C rent_my_t...@yahoo.com
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 rent_my_t...@yahoo.com 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 wolfgang.l...@gmail.com To: Rules Users List rules-users@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_bar...@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.l...@gmail.com wrote: From: Wolfgang Laun wolfgang.l...@gmail.com Subject: Re: [rules-users] fireUntilHalt and timing of rule activations To: Rules Users List rules-users@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_bar...@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
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_t...@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.l...@gmail.com To: Rules Users List rules-users@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_bar...@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.l...@gmail.com wrote: From: Wolfgang Laun wolfgang.l...@gmail.com Subject: Re: [rules-users] fireUntilHalt and timing of rule activations To: Rules Users List rules-users@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_bar...@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
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 greg_bar...@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_t...@yahoo.com wrote: From: Norman C rent_my_t...@yahoo.com 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
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 wolfgang.l...@gmail.com wrote: From: Wolfgang Laun wolfgang.l...@gmail.com Subject: Re: [rules-users] fireUntilHalt and timing of rule activations To: Rules Users List rules-users@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_bar...@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_t...@yahoo.com wrote: From: Norman C rent_my_t...@yahoo.com 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 -Inline Attachment Follows- ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users DroolsContinuousBatch.tar.gz Description
[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 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 rent_my_t...@yahoo.com wrote: From: Norman C rent_my_t...@yahoo.com 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
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?
?xml version=1.0 encoding=UTF-8?
definitions id=Definition
targetNamespace=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;
process processType=Private isExecutable=true id=servicerequest2
name=servicerequest.b
!-- nodes --
startEvent id=_1 name=Manual Trigger (Customer Calls) g:x=19
g:y=124 g:width=48 g:height=48 /
endEvent id=_19 name=End g:x=463 g:y=148 g:width=48
g:height=48
terminateEventDefinition/
/endEvent
userTask id=_22 name=Initialize Service Request Process g:x=139
g:y=234 g:width=100 g:height=48
potentialOwner
resourceAssignmentExpression
formalExpressionjohn/formalExpression
/resourceAssignmentExpression
/potentialOwner
/userTask
!-- connections --
sequenceFlow id=_22-_19 sourceRef=_22 targetRef=_19 /
sequenceFlow id=_1-_22 sourceRef=_1 targetRef=_22 /
/process
/definitions
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
