1:31 p.m.
I am finding that the "salience" feature is acting very erratically.
Some of my rules modify the working memory. So I would like them to
execute before the others that simply read the memory after modification
and report on certain data conditions that are left after all
modifications have happened.
The "modifying" rules have a salience of 5. The "reading" rules have a
salience of 0.
Using the rules logging I can see activations of my modifying rules
being created and activations of the reading rules being created.
And I can see "reading" rules (with salience 0) being executed /before/
"modifying" rules (with salience 5) even though no other activations are
being created in between them.
I am not using agenda groups or anything "fancy" like that.
Debugging through the code I can see the "MAIN" agenda group is a queue
organised as heap.
However, the order in which things happen is very non-deterministic
(presumably due to hashing or something like that) and I am finding it
very difficult to actually pin down an actual 100% reproducible case.
Is there any known problem with the salience mechanism?
I am using JBoss Rules 5.1.0 (with a support licence).
Chris Selwyn
2 p.m.
Hi Chris,
since you mention to already have a support license for JBoss Enterprise
BRMS, the best place to ask these types of questions is at the excellent
JBoss Customer Support Portal (https://access.redhat.com/home) where
your question will be handled under SLAs ensuring timely response and
continuous quality assurance monitoring of the same.
Just FYI, I believe the issue you are mentioning has been fixed in trunk
(see Jira https://issues.jboss.org/browse/JBRULES-2942) which should
make the fix available in the next BRMS 5.2 release. Please confirm with
the Red Hat support engineers through a support case as they are much
more knowledgeable on product releases, and direct any further questions
regarding the supported BRMS bits to them.
If there are any further issues that you would like to see prioritized
for the supported BRMS bits you are using, we will be glad to work with
you through the JBoss Customer Support Portal.
Thanks.
Tihomir
On 4/27/11 2:31 PM, Chris Selwyn wrote:
I am finding that the "salience" feature is acting very
erratically.
Some of my rules modify the working memory. So I would like them to
execute before the others that simply read the memory after
modification and report on certain data conditions that are left after
all modifications have happened.
The "modifying" rules have a salience of 5. The "reading" rules have
a
salience of 0.
Using the rules logging I can see activations of my modifying rules
being created and activations of the reading rules being created.
And I can see "reading" rules (with salience 0) being executed
/before/ "modifying" rules (with salience 5) even though no other
activations are being created in between them.
I am not using agenda groups or anything "fancy" like that.
Debugging through the code I can see the "MAIN" agenda group is a
queue organised as heap.
However, the order in which things happen is very non-deterministic
(presumably due to hashing or something like that) and I am finding it
very difficult to actually pin down an actual 100% reproducible case.
Is there any known problem with the salience mechanism?
I am using JBoss Rules 5.1.0 (with a support licence).
Chris Selwyn
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
12:51 a.m.
This has indeed been discovered recently, for certain scenarios where
activations were queued in the wrong order after fact modification.
The fix is in
./drools-core/src/main/java/org/drools/core/util/BinaryHeapQueue.java:
--- a/drools-core/src/main/java/org/drools/core/util/BinaryHeapQueue.java
+++ b/drools-core/src/main/java/org/drools/core/util/BinaryHeapQueue.java
@@ -185,7 +185,7 @@ public class BinaryHeapQueue
compareToParent = compare( this.elements[index],
this.elements[index / 2] );
}
- if ( index > 1 && compareToParent < 0 ) {
+ if ( index > 1 && compareToParent > 0 ) {
percolateUpMaxHeap( index );
} else {
percolateDownMaxHeap( index );
-W
2011/4/27 Tihomir Surdilovic <tsurdilo(a)redhat.com>
Hi Chris,
since you mention to already have a support license for JBoss Enterprise
BRMS, the best place to ask these types of questions is at the excellent
JBoss Customer Support Portal (https://access.redhat.com/home) where your
question will be handled under SLAs ensuring timely response and continuous
quality assurance monitoring of the same.
Just FYI, I believe the issue you are mentioning has been fixed in trunk
(see Jira https://issues.jboss.org/browse/JBRULES-2942) which should make
the fix available in the next BRMS 5.2 release. Please confirm with the Red
Hat support engineers through a support case as they are much more
knowledgeable on product releases, and direct any further questions
regarding the supported BRMS bits to them.
If there are any further issues that you would like to see prioritized for
the supported BRMS bits you are using, we will be glad to work with you
through the JBoss Customer Support Portal.
Thanks.
Tihomir
On 4/27/11 2:31 PM, Chris Selwyn wrote:
I am finding that the "salience" feature is acting very erratically.
Some of my rules modify the working memory. So I would like them to execute
before the others that simply read the memory after modification and report
on certain data conditions that are left after all modifications have
happened.
The "modifying" rules have a salience of 5. The "reading" rules have
a
salience of 0.
Using the rules logging I can see activations of my modifying rules being
created and activations of the reading rules being created.
And I can see "reading" rules (with salience 0) being executed
*before*"modifying" rules (with salience 5) even though no other activations
are
being created in between them.
I am not using agenda groups or anything "fancy" like that.
Debugging through the code I can see the "MAIN" agenda group is a queue
organised as heap.
However, the order in which things happen is very non-deterministic
(presumably due to hashing or something like that) and I am finding it very
difficult to actually pin down an actual 100% reproducible case.
Is there any known problem with the salience mechanism?
I am using JBoss Rules 5.1.0 (with a support licence).
Chris Selwyn
_______________________________________________
rules-users mailing
listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
8:40 a.m.
Thanks very much Wolfgang... that appears to fix it.
Chris
On 28/04/2011 06:51, Wolfgang Laun wrote:
This has indeed been discovered recently, for certain scenarios where
activations were queued in the wrong order after fact modification.
The fix is in
./drools-core/src/main/java/org/drools/core/util/BinaryHeapQueue.java:
--- a/drools-core/src/main/java/org/drools/core/util/BinaryHeapQueue.java
+++ b/drools-core/src/main/java/org/drools/core/util/BinaryHeapQueue.java
@@ -185,7 +185,7 @@ public class BinaryHeapQueue
compareToParent = compare( this.elements[index],
this.elements[index / 2] );
}
- if ( index > 1 && compareToParent < 0 ) {
+ if ( index > 1 && compareToParent > 0 ) {
percolateUpMaxHeap( index );
} else {
percolateDownMaxHeap( index );
-W
2011/4/27 Tihomir Surdilovic <tsurdilo(a)redhat.com
<mailto:tsurdilo@redhat.com>>
Hi Chris,
since you mention to already have a support license for JBoss
Enterprise BRMS, the best place to ask these types of questions is
at the excellent JBoss Customer Support Portal
(https://access.redhat.com/home) where your question will be
handled under SLAs ensuring timely response and continuous quality
assurance monitoring of the same.
Just FYI, I believe the issue you are mentioning has been fixed in
trunk (see Jira https://issues.jboss.org/browse/JBRULES-2942)
which should make the fix available in the next BRMS 5.2 release.
Please confirm with the Red Hat support engineers through a
support case as they are much more knowledgeable on product
releases, and direct any further questions regarding the supported
BRMS bits to them.
If there are any further issues that you would like to see
prioritized for the supported BRMS bits you are using, we will be
glad to work with you through the JBoss Customer Support Portal.
Thanks.
Tihomir
On 4/27/11 2:31 PM, Chris Selwyn wrote:
> I am finding that the "salience" feature is acting very erratically.
>
> Some of my rules modify the working memory. So I would like them
> to execute before the others that simply read the memory after
> modification and report on certain data conditions that are left
> after all modifications have happened.
>
> The "modifying" rules have a salience of 5. The "reading"
rules
> have a salience of 0.
>
> Using the rules logging I can see activations of my modifying
> rules being created and activations of the reading rules being
> created.
> And I can see "reading" rules (with salience 0) being executed
> /before/ "modifying" rules (with salience 5) even though no other
> activations are being created in between them.
>
> I am not using agenda groups or anything "fancy" like that.
>
> Debugging through the code I can see the "MAIN" agenda group is a
> queue organised as heap.
> However, the order in which things happen is very
> non-deterministic (presumably due to hashing or something like
> that) and I am finding it very difficult to actually pin down an
> actual 100% reproducible case.
>
> Is there any known problem with the salience mechanism?
>
> I am using JBoss Rules 5.1.0 (with a support licence).
>
> Chris Selwyn
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 10.0.1325 / Virus Database: 1500/3601 - Release Date: 04/27/11
4964
days inactive
4966
days old
3 comments
3 participants
participants (3)
-
Chris Selwyn -
Tihomir Surdilovic -
Wolfgang Laun