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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users