Re: [rules-users] Implementing Refraction with Drools

Mark Proctor <mproctor <at> codehaus.org> writes: > > You can improve your example by using an agenda listener to remove Activations once they are cancelled, > this way you avoid a memory leak. > > Further you can use annotations, to control this per rule. > rule xxx @repeatable(true) when > then end > > then in your filter you can check rule.getMetaData( "repeatable" ) > > We aren't going to add this to Drools right now, but it certainly is a useful example for people. > > We'll be reviewing execution control during the 6.x series, and we'll look at it then. I believe that you can > have different types of repeability, and I'd like to look at rising falling edges. It's important that you > don't add features one at a time, as one might make another impossible. So these things must be look at, as a > whole, and planned out. > > Mark > On 23 Jan 2013, at 00:39, magaram <magaram <at> deltadentalmi.com> wrote: > >> Thanks for the clarifications Mark and Wolfgang. I wanted to share some >> additional data. >> I was trying to reproduce the same behavior that ILOG JRules exhibits by >> default for refraction. >> >> My experiment with no-loop and lock-on-active did not work when I compared >> against my baseline results with JRules. However, the interesting part was >> when I ratified the agenda filter as follows (wrong and hacky as it is) - >> removed the encounteredActivations.remove(act) before returning false, it >> matched the ILOG baselines exactly. I ran through 46 test cases as part of >> my baseline, all of which have several looping opportunities single and >> complex. My earlier agenda filter implementation that I posted earlier did >> not yield identical results with the JRules baseline. >> >> It seems this logic for refraction seems to mimic JRules refraction >> behavior. From commercial use case perspective refraction/repeatability >> control is important. ILOG implements refraction out of the box as part of >> conflict resolution. However they offer up a antecedent directive called >> refresh (in lieu of update) that overrides refraction... >> >> import java.util.ArrayList; >> import java.util.List; >> >> import org.drools.runtime.rule.Activation; >> import org.drools.runtime.rule.AgendaFilter; >> >> /** >> * This custom agenda filter injects refraction behavior into the rule >> engine >> * @author Mukundan Agaram >> * >> */ >> public class RefractionAgendaFilter implements AgendaFilter { >> private List<Activation> encounteredActivations = new >> ArrayList<Activation>(); >> >> @Override >> public boolean accept(Activation act) >> { >> //Check for a Refraction >> if (encounteredActivations.contains(act)) >> { >> return false; >> } >> //Otherwise add the rule to check for potential refractions in the future >> encounteredActivations.add(act); >> //select the rule to be part of the agenda >> return true; >> } >> >> } >> >> >> >> >> -- >> View this message in context: http://drools.46999.n3.nabble.com/Implementing-Refraction-with-Drools- tp4021705p4021747.html >> Sent from the Drools: User forum mailing list archive at Nabble.com. >> _______________________________________________ >> rules-users mailing list >> rules-users <at> lists.jboss.org >> https://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 > > Using an activation listener could help to eliminate the memory leak, but with the current implementation, it does not. When activations are added and removed from the agenda, events are generated properly, in general. However, there is one case that fails. If an activation is actually fired, then it remains on the agenda and, because it was previously fired, if it is later removed from the agenda, no activation event is fired. Unfortunately, this missing event is precisely the event that is needed to clean out your cache of previously-fired activations. (This hole existed in Drools 4 and also in Drools 5 when I checked a few months ago. Perhaps it has been fixed since then.) If that hole were plugged, then this strategy would certainly do the job. Neverhteless, based on other comments in this thread, I'm not sure if there isn't a performance concern, though what other option is there until @repeatable (or some alternative) is implemented? -Jim _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users