<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The even is there, just it's an internal feature at the moment. <div><br></div><div>There is an unmatch callback, for when a rule stops being true, see <span style="background-color: rgb(255, 255, 255); color: rgb(153, 0, 0); font-family: Consolas, 'Liberation Mono', Courier, monospace; font-size: 12px; font-weight: bold; line-height: 16px; white-space: pre; ">testActivationUnMatchListener:</span></div><div><a href="https://github.com/droolsjbpm/drools/blob/master/drools-core/src/test/java/org/drools/reteoo/AgendaTest.java">https://github.com/droolsjbpm/drools/blob/master/drools-core/src/test/java/org/drools/reteoo/AgendaTest.java</a></div><div><br></div><div>What you can do is set a call back during the activation created event. You'll need to cast to an internal concrete class first, AgendaItem. Remember these interfaces and classes will change over time.</div><div><br></div><div>Mark</div><div><br></div><div><br></div><div><div><div>On 12 Mar 2013, at 18:53, Jim Hahn <<a href="mailto:jrh3@att.com">jrh3@att.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Mark Proctor <mproctor <at> <a href="http://codehaus.org">codehaus.org</a>> writes:<br><br><blockquote type="cite"><br>You can improve your example by using an agenda listener to remove <br></blockquote>Activations once they are cancelled,<br><blockquote type="cite">this way you avoid a memory leak.<br><br>Further you can use annotations, to control this per rule.<br>rule xxx @repeatable(true) when<br>then end<br><br>then in your filter you can check rule.getMetaData( "repeatable" )<br><br>We aren't going to add this to Drools right now, but it certainly is a <br></blockquote>useful example for people. <br><blockquote type="cite"><br>We'll be reviewing execution control during the 6.x series, and we'll look <br></blockquote>at it then. I believe that you can<br><blockquote type="cite">have different types of repeability, and I'd like to look at rising falling <br></blockquote>edges. It's important that you<br><blockquote type="cite">don't add features one at a time, as one might make another impossible. So <br></blockquote>these things must be look at, as a<br><blockquote type="cite">whole, and planned out.<br><br>Mark<br>On 23 Jan 2013, at 00:39, magaram <magaram <at> <a href="http://deltadentalmi.com">deltadentalmi.com</a>> wrote:<br><br><blockquote type="cite">Thanks for the clarifications Mark and Wolfgang. I wanted to share some<br>additional data.<br>I was trying to reproduce the same behavior that ILOG JRules exhibits by<br>default for refraction.<br><br>My experiment with no-loop and lock-on-active did not work when I compared<br>against my baseline results with JRules. However, the interesting part was<br>when I ratified the agenda filter as follows (wrong and hacky as it is) -<br>removed the encounteredActivations.remove(act) before returning false, it<br>matched the ILOG baselines exactly. I ran through 46 test cases as part of<br>my baseline, all of which have several looping opportunities single and<br>complex. My earlier agenda filter implementation that I posted earlier did<br>not yield identical results with the JRules baseline.<br><br>It seems this logic for refraction seems to mimic JRules refraction<br>behavior. From commercial use case perspective refraction/repeatability<br>control is important. ILOG implements refraction out of the box as part of<br>conflict resolution. However they offer up a antecedent directive called<br>refresh (in lieu of update) that overrides refraction...<br><br>import java.util.ArrayList;<br>import java.util.List;<br><br>import org.drools.runtime.rule.Activation;<br>import org.drools.runtime.rule.AgendaFilter;<br><br>/**<br>* This custom agenda filter injects refraction behavior into the rule<br>engine<br>* @author Mukundan Agaram<br>*<br>*/<br>public class RefractionAgendaFilter implements AgendaFilter {<br><span class="Apple-tab-span" style="white-space:pre"> </span>private List<Activation> encounteredActivations = new<br>ArrayList<Activation>();<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>@Override<br><span class="Apple-tab-span" style="white-space:pre"> </span>public boolean accept(Activation act) <br><span class="Apple-tab-span" style="white-space:pre"> </span>{<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>//Check for a Refraction<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>if (encounteredActivations.contains(act))<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>{<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>return false;<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>}<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>//Otherwise add the rule to check for potential refractions in <br></blockquote></blockquote>the future<br><blockquote type="cite"><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>encounteredActivations.add(act);<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>//select the rule to be part of the agenda<br><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>return true;<br><span class="Apple-tab-span" style="white-space:pre"> </span>}<br><br>}<br><br><br><br><br>--<br>View this message in context: <br></blockquote></blockquote><a href="http://drools.46999.n3.nabble.com/Implementing-Refraction-with-Drools-">http://drools.46999.n3.nabble.com/Implementing-Refraction-with-Drools-</a><br>tp4021705p4021747.html<br><blockquote type="cite"><blockquote type="cite">Sent from the Drools: User forum mailing list archive at Nabble.com.<br>_______________________________________________<br>rules-users mailing list<br>rules-users <at> lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/rules-users<br></blockquote><br>_______________________________________________<br>rules-users mailing list<br>rules-users <at> lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/rules-users<br><br><br></blockquote><br><br>Using an activation listener could help to eliminate the memory leak, but with <br>the current implementation, it does not. When activations are added and <br>removed from the agenda, events are generated properly, in general. However, <br>there is one case that fails. If an activation is actually fired, then it <br>remains on the agenda and, because it was previously fired, if it is later <br>removed from the agenda, no activation event is fired. Unfortunately, this <br>missing event is precisely the event that is needed to clean out your cache of <br>previously-fired activations. (This hole existed in Drools 4 and also in <br>Drools 5 when I checked a few months ago. Perhaps it has been fixed since <br>then.)<br><br>If that hole were plugged, then this strategy would certainly do the job. <br>Neverhteless, based on other comments in this thread, I'm not sure if there <br>isn't a performance concern, though what other option is there until <br>@repeatable (or some alternative) is implemented?<br><br>-Jim<br><br><br>_______________________________________________<br>rules-users mailing list<br>rules-users@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/rules-users<br></blockquote></div><br></div></body></html>