The even is there, just it's an internal feature at the moment. 

There is an unmatch callback, for when a rule stops being true, see testActivationUnMatchListener:

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.


On 12 Mar 2013, at 18:53, Jim Hahn <> wrote:

Mark Proctor <mproctor <at>> 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.

On 23 Jan 2013, at 00:39, magaram <magaram <at>> 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
* @author Mukundan Agaram
public class RefractionAgendaFilter implements AgendaFilter {
private List<Activation> encounteredActivations = new

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
//select the rule to be part of the agenda
return true;


View this message in context:
Sent from the Drools: User forum mailing list archive at
rules-users mailing list
rules-users <at>

rules-users mailing list
rules-users <at>

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

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?


rules-users mailing list