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:
https://github.com/droolsjbpm/drools/blob/master/drools-core/src/test/java/org/drools/reteoo/AgendaTest.java
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.
Mark
On 12 Mar 2013, at 18:53, Jim Hahn <j...@att.com> wrote:
> 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
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
