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.
>
>
>-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
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 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 any
Re: [rules-users] Drools-Spring Config for Knowledge Agent
tried with Drools v5.1.1 but still runnig through same error - Keep Working >> KiranP -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Spring-Config-for-Knowledge-Agent-tp1634280p1640851.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
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.
>>
>>
>> -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 ba
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 );
>>
>> 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
Re: [rules-users] Drools-Spring Config for Knowledge Agent
no..I m Using 5.1.0 do u think kagents are not supported in 5.1.0 ?? BTW..i'll give it a try and let u know... - Keep Working >> KiranP -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Spring-Config-for-Knowledge-Agent-tp1634280p1640658.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] [drools-planner] eval check doesn't provide the expected output
Hi,
I have the following rule and roomCurriculumCode and currCode are of type
String. If the check is equals "insertLogical" never happens, but if the the
codes are not equal as expressed below the "insertLogical" is performed even
if the strings are equal. What am I missing here
rule "RoomAndCurriculum"
when
$room : Room($roomCode : code, $roomCapacity : capacity,
$roomCurriculumCode : curriculumCode);
$curriculum : Curriculum($currCode : code);
eval($roomCurriculumCode != $currCode)
then
insertLogical(new IntConstraintOccurrence("RoomAndCurriculum",
ConstraintType.NEGATIVE_HARD, 1, $roomCapacity, $room, $currCode,
$roomCurriculumCode));
end
-jd
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Enterprise release management
How do we manage release of content from dev to QA to Prod environments? Do we just replace Production repository with QA repository once testing is complete? Are there any other approaches? -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Enterprise-release-management-tp1640388p1640388.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
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 )
>> ...
>>
>> 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 )
>>
>> th
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'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: Norma
Re: [rules-users] Drools-Spring Config for Knowledge Agent
Did you try this with 5.1.1? Esteban Aliverti - Developer @ http://www.plugtree.com - Blog @ http://ilesteban.wordpress.com On Tue, Oct 5, 2010 at 2:59 AM, KiranP wrote: > > Hello Everybody, > > I've used Drools5.1.0 and I have following Config In Spring : > > > source="classpath:/process/profilechangeprocess.rf"> > source="classpath:/rules/documentsrule.drl" /> > source="classpath:/ChangeSet.xml"> > > > > > > ref="profileChangeProcess"> > ref="documentsRule"> > > > > > > > now when i run the code i get following exception : > > org.springframework.beans.factory.BeanCreationException: Error creating > bean with name 'kSession': Error setting property values; nested exception > is org.springframework.beans.NotWritablePropertyException: Invalid property > 'knowledgeAgent' of bean class > [org.drools.container.spring.beans.StatefulKnowledgeSessionBeanFactory]: > Bean property 'knowledgeAgent' is not writable or has an invalid setter > method. Does the parameter type of the setter match the return type of the > getter? >at > > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1341) >at > > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1067) >at > > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:511) >at > > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:450) >at > > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:290) >at > > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) >at > > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:287) >at > > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:189) >at > > org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:820) >at > > org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:762) >at > > org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:680) >at > > org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:475) >... 30 more > Caused by: org.springframework.beans.NotWritablePropertyException: Invalid > property 'knowledgeAgent' of bean class > [org.drools.container.spring.beans.StatefulKnowledgeSessionBeanFactory]: > Bean property 'knowledgeAgent' is not writable or has an invalid setter > method. Does the parameter type of the setter match the return type of the > getter? >at > > org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:1012) >at > > org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:857) >at > > org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:76) >at > > org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:58) >at > > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1338) >... 41 more > > > any help or pointers to examples may help. > > > - > Keep Working >> > KiranP > -- > View this message in context: > http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Spring-Config-for-Knowledge-Agent-tp1634280p1634280.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] nested condition in from collect
I believe it should work, do you have the right imports? List import for example? By the way, I believe that using eval in that rule is unnecessary. ___ 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
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'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
[rules-users] nested condition in from collect
I'm trying to determine if a user has a certain immunization on record or a
group of immunizations but when I attempt to put additional the rule will
not compile.
rule "Immunizations_Determine if a user has a valid tetanus immunization"
dialect 'mvel'
no-loop true
salience 100
when
$user : User($profile : profile)
$got : List() from collect ( UserImmunization( immunization != null,
eval( immunization.immunizationName == "Td or Tet/Dip (Tetanus/Diphtheria)"
|| immunization.immunizationName == "Tdap (Tetanus/Diphtheria & Pertussis)"
|| immunization.immunizationName == "DT (Diphtheria/Tetanus)" ||
immunization.immunizationName == "TT or Tet Tox (Tetanus Toxoid)" ||
immunization.immunizationName == "Tetanus")) from $profile.userImmunizations
)
then
System.out.println("The user has has a valid tetanus immunization ");
end
The profile contains a list of UserImmunizations.
UserImmunizations:
private Long id;
private Immunization immunization;
private Date dateReceived;
Immunizations:
private Long id;
private String immunizationName;
I'm not sure if this is a good place to use 'from accumulate'.
Is it possible to do the condition for the Immunization object within the
'from collect' or should it be evaluated separately?
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/nested-condition-in-from-collect-tp1637479p1637479.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] Get instance from working memory and update it in the flow
Hi,
I need to update an instance from the working memory in my Action/Script
node in process flow.
I have an instance in the working memory which I updating inside my rules,
furthermoreת I need to update it inside my action node.
Is there an option to retrieve this object instance during the flow? I have
a constrain at the beginning of the flow which filter out all other
instances of this object and leaves only the relevant instance.
I am using the context.getVariable("instName") and
context.setVariable("instName", object), but my problem is to get the
specific instance because the constrain component doesnt allow me to use the
setVariable...
Thanks
Yaniv
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Memory usage tied to rule report?
Jared, Glad to hear. Yes, the idea of the API is to extract info from the working memory and RETE network and expose it to report generation. As you saw, I am using an MVEL template to generate the report at the moment. It is very crude, so any suggestions for improvements are most welcome. Once we get something better, we can expose it as an official API in Drools API. Edson 2010/10/5 Jared Davis : > > Edson, > > Thanks for the report. The top ten on the left was just what I needed to > track down the badly written rules. > > The 385 rules generate 823 documents using 2 facts. > > My peak heap usage is now only 250mb. Before it would fail with a 1.2GB > heap. > > Do you think this report is a good starting point to generate a graphML file > showing the same info as the text report? > > > Jared > > > -- > View this message in context: > http://drools-java-rules-engine.46999.n3.nabble.com/Memory-usage-tied-to-rule-report-tp1434387p1634480.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 > -- 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
Re: [rules-users] Error in named query: ProcessInstancesWaitingForEvent
Hi, I had the same problem, but after downloading the Drools Source Code (for 5.1.1) and looking in: drools-5.1.1-src.zip\drools-persistence-jpa\src\test\resources\META-INF\orm.xml I found the answer, the correct query is: select processInstanceInfo.processInstanceId from ProcessInstanceInfo processInstanceInfo where :type in elements(processInstanceInfo.eventTypes) Have fun, Dan -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Error-in-named-query-ProcessInstancesWaitingForEvent-tp1577013p1635461.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
Re: [rules-users] performing math function in drools
Has anyone imported third party jar in Guvnor GUI 5.1 so that it can be used in
the functions created from Guvnor GUI itself?
Best Regards,
Kripa
From: rules-users-boun...@lists.jboss.org
[mailto:rules-users-boun...@lists.jboss.org] On Behalf Of Kripa Nathwani
Sent: Monday, October 04, 2010 1:50 PM
To: Rules Users List
Subject: Re: [rules-users] performing math function in drools
My problem is that I am running it using Guvnor and in Guvnor it is not able to
recognize the class when I write the import statement.
I tried creating drl using File-> New-> drl
I also tried to import the rt jar file(through "new file" option in drools 5.1
) but the package does not get built and gives import error. It seems it is not
able to recognize the jar.
Is there any way by which I can use the java api or start importing the api
jars into package(I don't want to use it as fact. Hence I am not using "upload
pojo model jar" option).
Best Regards,
Kripa
From: rules-users-boun...@lists.jboss.org
[mailto:rules-users-boun...@lists.jboss.org] On Behalf Of Wolfgang Laun
Sent: Monday, October 04, 2010 11:45 AM
To: Rules Users List
Subject: Re: [rules-users] performing math function in drools
// appl.transport.Transport.java:
public class Transport {
public static double tax( double a, int n ){
return Math.pow( a, (double)n );
}
}
// transport.drl --
import function appl.transport.Transport.tax;
import function java.lang.Math.pow;
dialect "java"
function double sqr( double a ){
return Math.pow( a, 2.0 );
}
rule "demo"
when
Cargo( name == "Crate", , limit < ( tax( 20.0, 2 ) ) )
then
System.out.println( "tax=" + tax( 20.0, 2 ) );
System.out.println( "pow=" + pow( 20.0, 2.0 ) );
System.out.println( "sqr=" + sqr( 20.0 ) );
end
-W
2010/10/4 Kripa Nathwani
mailto:kripa.nathw...@lntinfotech.com>>
But for using Math.pow() I have to import java.lang in that function.
Even after importing java.lang, it is not recognizing the function add giving
me error as :
Prohibited package name:java.class
If you can just forward me the link for that document you mentioned below, I
can get some useful insight into it.
Best Regards,
Kripa
From:
rules-users-boun...@lists.jboss.org
[mailto:rules-users-boun...@lists.jboss.org]
On Behalf Of Leandro Romero
Sent: Monday, October 04, 2010 10:22 AM
To: Rules Users List
Subject: Re: [rules-users] performing math function in drools
If you want to make a function call in LHS you have to use Eval, it allows you
to execute any Java code. In this especific case, you can call Math.pow()
inside of it.
Before using it, I strongly recommend you to read the documentation about it.
__
This Email may contain confidential or privileged information for the intended
recipient (s) If you are not the intended recipient, please do not use or
disseminate the information, notify the sender and delete it from your system.
__
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
__
This Email may contain confidential or privileged information for the intended
recipient (s) If you are not the intended recipient, please do not use or
disseminate the information, notify the sender and delete it from your system.
__
__
This Email may contain confidential or privileged information for the intended
recipient (s) If you are not the intended recipient, please do not use or
disseminate the information, notify the sender and delete it from your system.
This Email may contain confidential or privileged information for the intended
recipient (s) If you are not the intended recipient, please do not use or
disseminate the information, notify the sender and delete it from your system.
_
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Memory usage tied to rule report?
Edson, Thanks for the report. The top ten on the left was just what I needed to track down the badly written rules. The 385 rules generate 823 documents using 2 facts. My peak heap usage is now only 250mb. Before it would fail with a 1.2GB heap. Do you think this report is a good starting point to generate a graphML file showing the same info as the text report? Jared -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Memory-usage-tied-to-rule-report-tp1434387p1634480.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
