[rules-users] Salience problems

[Wolfgang Laun]

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 at 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 at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110428/78b22263/attachment.html