<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Thanks very much Wolfgang... that appears to fix it.<br>
    <br>
    Chris<br>
    <br>
    On 28/04/2011 06:51, Wolfgang Laun wrote:
    <blockquote
      cite="mid:BANLkTi=3OaimAnWD0jiHSnsLnXOKhXQ3WA@mail.gmail.com"
      type="cite">This has indeed been discovered recently, for certain
      scenarios where activations were queued in the wrong order after
      fact modification.<br>
      <br>
      The fix is in
      ./drools-core/src/main/java/org/drools/core/util/BinaryHeapQueue.java:<br>
      <br>
      ---
      a/drools-core/src/main/java/org/drools/core/util/BinaryHeapQueue.java<br>
      +++
      b/drools-core/src/main/java/org/drools/core/util/BinaryHeapQueue.java<br>
      @@ -185,7 +185,7 @@ public class BinaryHeapQueue<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; compareToParent = compare( this.elements[index],<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this.elements[index /
      2] );<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
      -&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if ( index &gt; 1 &amp;&amp; compareToParent &lt; 0 )
      {<br>
      +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if ( index &gt; 1 &amp;&amp; compareToParent &gt; 0 )
      {<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; percolateUpMaxHeap( index );<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } else {<br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; percolateDownMaxHeap( index );<br>
      <br>
      <br>
      -W<br>
      <br>
      <br>
      <br>
      <div class="gmail_quote">2011/4/27 Tihomir Surdilovic <span
          dir="ltr">&lt;<a moz-do-not-send="true"
            href="mailto:tsurdilo@redhat.com">tsurdilo@redhat.com</a>&gt;</span><br>
        <blockquote class="gmail_quote" style="border-left: 1px solid
          rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
          1ex;">
          <div text="#000000" bgcolor="#ffffff"> Hi Chris, <br>
            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
            (<a moz-do-not-send="true"
              href="https://access.redhat.com/home" target="_blank">https://access.redhat.com/home</a>)
            where your question will be handled under SLAs ensuring
            timely response and continuous quality assurance monitoring
            of the same.<br>
            <br>
            Just FYI, I believe the issue you are mentioning has been
            fixed in trunk (see Jira <a moz-do-not-send="true"
              href="https://issues.jboss.org/browse/JBRULES-2942"
              target="_blank">https://issues.jboss.org/browse/JBRULES-2942</a>)
            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.<br>
            <br>
            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.<br>
            <br>
            Thanks.<br>
            Tihomir
            <div>
              <div class="h5"><br>
                <br>
                <br>
                On 4/27/11 2:31 PM, Chris Selwyn wrote: </div>
            </div>
            <blockquote type="cite">
              <div>
                <div class="h5"> I am finding that the "salience"
                  feature is acting very erratically.<br>
                  <br>
                  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.<br>
                  <br>
                  The "modifying" rules have a salience of 5. The
                  "reading" rules have a salience of 0.<br>
                  <br>
                  Using the rules logging I can see activations of my
                  modifying rules being created and activations of the
                  reading rules being created.<br>
                  And I can see "reading" rules (with salience 0) being
                  executed <i>before</i> "modifying" rules (with
                  salience 5) even though no other activations are being
                  created in between them.<br>
                  <br>
                  I am not using agenda groups or anything "fancy" like
                  that.<br>
                  <br>
                  Debugging through the code I can see the "MAIN" agenda
                  group is a queue organised as heap.<br>
                  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.<br>
                  <br>
                  Is there any known problem with the salience
                  mechanism?<br>
                  <br>
                  I am using JBoss Rules 5.1.0 (with a support licence).<br>
                  <br>
                  Chris Selwyn<br>
                </div>
              </div>
              <pre><fieldset></fieldset>
_______________________________________________
rules-users mailing list
<a moz-do-not-send="true" href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
            </blockquote>
            <br>
          </div>
          <br>
          _______________________________________________<br>
          rules-users mailing list<br>
          <a moz-do-not-send="true"
            href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
          <a moz-do-not-send="true"
            href="https://lists.jboss.org/mailman/listinfo/rules-users"
            target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
          <br>
        </blockquote>
      </div>
      <br>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
rules-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <p class="avgcert" color="#000000" align="left">No virus found in
        this message.<br>
        Checked by AVG - <a moz-do-not-send="true"
          href="http://www.avg.com">www.avg.com</a><br>
        Version: 10.0.1325 / Virus Database: 1500/3601 - Release Date:
        04/27/11</p>
    </blockquote>
  </body>
</html>