Re: [rules-users] Implementing Refraction with Drools

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-tp4... Sent from the Drools: User forum mailing list archive at Nabble.com.