5:05 a.m.
I believe we can inject in Refraction capabilities into Drools Rule Engine
using a simple Agenda Filter. I have tested this with test cases against
JRules and Drools and get similar results. Without the Refraction Agenda
Filter it loops infinitely as expected.
Please try it out and tell me what you think. I believe refraction is a much
needed feature of a forward chaining rule engine for commercial purposes.
Any feedback is deeply appreciated.
Here is what the code looks like
---------Agenda Filter---------------------------
package test;
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 encounteredActivations = new ArrayList();
@Override
public boolean accept(Activation act)
{
//Check for a Refraction
if (encounteredActivations.contains(act))
{
//Remove from encountered activations for future firing
encounteredActivations.remove(act);
//return false so the rule is not selected as part of the refraction
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;
}
}
-----------------DRL------------------------
//created on: Jan 15, 2013
package test
dialect "mvel"
rule testFooBar1
salience 100
when
$foo : Foo()
$bar : Bar(y > 0)
then
$foo.setX(($foo.getX() + $bar.getY()));
System.out.println("Fired "+drools.getRule().getName())
update($foo);
end
rule testFooBar2
salience 150
when
$foo : Foo(x >= 6)
then
System.out.println("Fired "+drools.getRule().getName())
end
rule testFooBar3
salience 50
when
$foo : Foo(x >= 7)
then
System.out.println("Fired "+drools.getRule().getName())
end
----------------Runtime execution code--------------------------
package test;
import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.io.ResourceFactory;
import org.drools.runtime.StatefulKnowledgeSession;
public class TestFooBarMain {
private static void test()
{
KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
kbuilder.add( ResourceFactory.newClassPathResource( "TestFooBar.drl",
TestFooBarMain.class ),
ResourceType.DRL );
if ( kbuilder.hasErrors() ) {
System.out.println( kbuilder.getErrors().toString() );
}
else
{
System.out.println("DRL parsing - success!");
}
KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
kbase.addKnowledgePackages( kbuilder.getKnowledgePackages() );
StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
Foo foo1 = new Foo();
foo1.setX(6);
Bar bar1 = new Bar();
bar1.setY(3);
ksession.insert(foo1);
ksession.insert(bar1);
ksession.fireAllRules(new RefractionAgendaFilter());
}
/**
* @param args
*/
public static void main(String[] args) {
test();
}
}
----------------Facts-------------------------
package test;
public class Foo {
private int x;
private int y;
public int getX() {
return x;
}
public void setX(int x) {
this.x = x;
}
public int getY() {
return y;
}
public void setY(int y) {
this.y = y;
}
}
package test;
public class Bar {
public int getX() {
return x;
}
public void setX(int x) {
this.x = x;
}
public int getY() {
return y;
}
public void setY(int y) {
this.y = y;
}
private int x;
private int y;
}
Thanks,
Mukundan Agaram
--
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.
5:45 a.m.
Recently, Esteban covered the topic quite extensively, you can start from
there:
http://ilesteban.wordpress.com/2012/11/16/about-drools-and-infinite-execu...
Best
Davide
Unfortunately, I'm afraid your proposal doesn't scale as well as impacting
performance and
expected behavior negatively
--
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.
2:09 p.m.
Thanks for pointing me to the post Davide.
From a performance perspective I agree there are concerns. I have
provided
some numbers of what I saw
for situations firing several rules over several tuples at the end of this
post -
However, I ran some self loop and complex loop scenarios through this
approach and they seemed to hold. Can you elaborate on why this does not
solve the refraction scenario?
The way I understand refraction is -
This term comes from the neurobiological observation of a refractory
period for a neuron, which means that the neuron is not able to fire
immediately without first going through a relaxation process. In a
similar way, OPS5 will not allow the same instantiation in the conflict
set from firing twice in a row. This prevents the inference engine from
entering into an infinite loop.
I was reading through apost from Mark Proctor on this when I had the idea
of investigating this approach.
http://blog.athico.com/2010/07/slot-specific-and-refraction.html
----------Log snip starts -----------------------
<21 Jan 17:23:45> <INFO>
<com.deltadental.claims.rules.engine.RuleEngine>
Time taken for operation [Creating KnowledgeBuilder] = 2
<21 Jan 17:23:46> <INFO>
<com.deltadental.claims.rules.engine.RuleEngine>
Time taken for operation [Loading DROOLS ruleset into KnowledgeBuilder] =
809
<21 Jan 17:23:46> <INFO>
<com.deltadental.claims.rules.engine.RuleEngine>
Time taken for operation [Creating Knowledgebase] = 1
<21 Jan 17:23:46> <INFO>
<com.deltadental.claims.rules.engine.RuleEngine>
Time taken for operation [Loading KnowledgeBase with KnowledgePackages from
KnowledgeBuilder] = 110
<21 Jan 17:23:46> <INFO>
<com.deltadental.claims.rules.engine.RuleEngine>
Time taken for operation [Creating StatefulKnowledgeSession for
KnowledgeBase] = 0
<21 Jan 17:23:46> <INFO>
<com.deltadental.claims.rules.engine.RuleEngine>
Time taken for operation [Asserting Facts into StatefulKnowledgeSession] =
24
Encountered activation [Activation rule=BORA00105, act#=4, salience=9998978,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:43:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00105, act#=4, salience=9998978,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:43:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00110, act#=5, salience=9998975,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:43:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00110, act#=5, salience=9998975,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:43:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00115, act#=9, salience=9998973,
tuple=[fact 0:8:11412609:2335260:8:null:[Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:43:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00115, act#=9, salience=9998973,
tuple=[fact 0:8:11412609:2335260:8:null:[Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:43:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00105, act#=4, salience=9998978,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00105, act#=4, salience=9998978,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00110, act#=5, salience=9998975,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00110, act#=5, salience=9998975,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00115, act#=9, salience=9998973,
tuple=[fact 0:8:11412609:2335260:8:null:[Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00115, act#=9, salience=9998973,
tuple=[fact 0:8:11412609:2335260:8:null:[Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00135, act#=6, salience=9998969,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00135, act#=6, salience=9998969,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00140, act#=8, salience=9998968,
tuple=[fact 0:11:10123092:2335260:11:null:[Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00140, act#=8, salience=9998968,
tuple=[fact 0:11:10123092:2335260:11:null:[Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00205, act#=11,
salience=9998965, tuple=[fact 0:37:9594878:9594878:37:DEFAULT:Oid =
15661382, Adj ReasonTerm, Adjusted BC Oid = 8150309]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00205, act#=11, salience=9998965,
tuple=[fact 0:37:9594878:9594878:37:DEFAULT:Oid = 15661382, Adj ReasonTerm,
Adjusted BC Oid = 8150309]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00210, act#=12,
salience=9998962, tuple=[fact 0:37:9594878:9594878:37:DEFAULT:Oid =
15661382, Adj ReasonTerm, Adjusted BC Oid = 8150309]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00210, act#=12, salience=9998962,
tuple=[fact 0:37:9594878:9594878:37:DEFAULT:Oid = 15661382, Adj ReasonTerm,
Adjusted BC Oid = 8150309]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00215, act#=17,
salience=9998960, tuple=[fact 0:12:17846274:9594909:12:null:[Oid = 15661382,
Adj ReasonTerm, Adjusted BC Oid = 8150309]]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00215, act#=17, salience=9998960,
tuple=[fact 0:12:17846274:9594909:12:null:[Oid = 15661382, Adj ReasonTerm,
Adjusted BC Oid = 8150309]]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
<21 Jan 17:23:46> <INFO>
<com.deltadental.claims.rules.engine.RuleEngine>
Time taken for operation [Firing rules in StatefulKnowledgeSession] = 24
--
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.
5:18 p.m.
The AgendaFilter you propose is bound to cause problems if rules
are intended to fire repeatedly. I have a demo consisting of a single rule,
to be fired many times with varying data; certain patterns are bound
to occur again. Adding the proposed agenda filter produces an
incorrect result.
Also note the statistics:
3906 activations were encountered (Set.count() at the end)
3593 activations remain in the List at the end of the run
313 activations were skipped due to the filter.
The number of remaining activations is an strong indication
that this approach may result in a memory leak.
-W
On 22/01/2013, magaram <magaram(a)deltadentalmi.com> wrote:
Thanks for pointing me to the post Davide.
>From a performance perspective I agree there are concerns. I have provided
some numbers of what I saw
for situations firing several rules over several tuples at the end of this
post -
However, I ran some self loop and complex loop scenarios through this
approach and they seemed to hold. Can you elaborate on why this does not
solve the refraction scenario?
The way I understand refraction is -
This term comes from the neurobiological observation of a refractory
period for a neuron, which means that the neuron is not able to fire
immediately without first going through a relaxation process. In a
similar way, OPS5 will not allow the same instantiation in the conflict
set from firing twice in a row. This prevents the inference engine from
entering into an infinite loop.
I was reading through apost from Mark Proctor on this when I had the idea
of investigating this approach.
http://blog.athico.com/2010/07/slot-specific-and-refraction.html
----------Log snip starts -----------------------
<21 Jan 17:23:45> <INFO>
<com.deltadental.claims.rules.engine.RuleEngine>
Time taken for operation [Creating KnowledgeBuilder] = 2
<21 Jan 17:23:46> <INFO>
<com.deltadental.claims.rules.engine.RuleEngine>
Time taken for operation [Loading DROOLS ruleset into KnowledgeBuilder] =
809
<21 Jan 17:23:46> <INFO>
<com.deltadental.claims.rules.engine.RuleEngine>
Time taken for operation [Creating Knowledgebase] = 1
<21 Jan 17:23:46> <INFO>
<com.deltadental.claims.rules.engine.RuleEngine>
Time taken for operation [Loading KnowledgeBase with KnowledgePackages from
KnowledgeBuilder] = 110
<21 Jan 17:23:46> <INFO>
<com.deltadental.claims.rules.engine.RuleEngine>
Time taken for operation [Creating StatefulKnowledgeSession for
KnowledgeBase] = 0
<21 Jan 17:23:46> <INFO>
<com.deltadental.claims.rules.engine.RuleEngine>
Time taken for operation [Asserting Facts into StatefulKnowledgeSession] =
24
Encountered activation [Activation rule=BORA00105, act#=4,
salience=9998978,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:43:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00105, act#=4, salience=9998978,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:43:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00110, act#=5,
salience=9998975,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:43:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00110, act#=5, salience=9998975,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:43:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00115, act#=9,
salience=9998973,
tuple=[fact 0:8:11412609:2335260:8:null:[Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:43:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00115, act#=9, salience=9998973,
tuple=[fact 0:8:11412609:2335260:8:null:[Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:43:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00105, act#=4,
salience=9998978,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00105, act#=4, salience=9998978,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00110, act#=5,
salience=9998975,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00110, act#=5, salience=9998975,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00115, act#=9,
salience=9998973,
tuple=[fact 0:8:11412609:2335260:8:null:[Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00115, act#=9, salience=9998973,
tuple=[fact 0:8:11412609:2335260:8:null:[Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00135, act#=6,
salience=9998969,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00135, act#=6, salience=9998969,
tuple=[fact 0:33:2335229:2335229:33:DEFAULT:Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00140, act#=8,
salience=9998968,
tuple=[fact 0:11:10123092:2335260:11:null:[Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00140, act#=8, salience=9998968,
tuple=[fact 0:11:10123092:2335260:11:null:[Oid = 15661383, Adj ReasonAdd,
Adjusted BC Oid = 8150302]]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00205, act#=11,
salience=9998965, tuple=[fact 0:37:9594878:9594878:37:DEFAULT:Oid =
15661382, Adj ReasonTerm, Adjusted BC Oid = 8150309]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00205, act#=11, salience=9998965,
tuple=[fact 0:37:9594878:9594878:37:DEFAULT:Oid = 15661382, Adj ReasonTerm,
Adjusted BC Oid = 8150309]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00210, act#=12,
salience=9998962, tuple=[fact 0:37:9594878:9594878:37:DEFAULT:Oid =
15661382, Adj ReasonTerm, Adjusted BC Oid = 8150309]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00210, act#=12, salience=9998962,
tuple=[fact 0:37:9594878:9594878:37:DEFAULT:Oid = 15661382, Adj ReasonTerm,
Adjusted BC Oid = 8150309]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Encountered activation [Activation rule=BORA00215, act#=17,
salience=9998960, tuple=[fact 0:12:17846274:9594909:12:null:[Oid =
15661382,
Adj ReasonTerm, Adjusted BC Oid = 8150309]]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
Removing activation[Activation rule=BORA00215, act#=17, salience=9998960,
tuple=[fact 0:12:17846274:9594909:12:null:[Oid = 15661382, Adj ReasonTerm,
Adjusted BC Oid = 8150309]]
[fact 0:2:881692:881692:2:DEFAULT:Oid= 8150317, BPSD = 03/01/2009, BPED =
03/31/2009, RD = 02/26/2009]
[fact
0:3:21094514:21094514:45:DEFAULT:com.deltadental.billing.output.rules.BillingOutputRuleContext@141e072]
]
<21 Jan 17:23:46> <INFO>
<com.deltadental.claims.rules.engine.RuleEngine>
Time taken for operation [Firing rules in StatefulKnowledgeSession] = 24
--
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.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5:25 p.m.
Unfortunately, I'm afraid your proposal doesn't scale as well
as impacting
performance and
expected behaviour negatively
W3C RIF have tried to document refraction and repeatability.
http://www.w3.org/2005/rules/wiki/PRD_Refraction_Repeatability
Under that definition drools already has refraction, what we don't have is
repeatability control.
What you've done is more like hard coding repeatability=false. Also as davide
mentions, it's not an efficient implementation.
As Drools implements a modify-in-place we know whether an activation was created or
modified when it reaches the RTN. It can be cheaply filtered (ignored) there, we just need
to add an attribute to be able to control this behaviour per rule.
One reason why I haven't done this, is I believe the concept can be extended further
to give more control. There is a concept of rising and falling edges. I prefer the idea of
allowing or disallowing activations based on these edges.
was true, still true
was false, is true
was true, is false
We also more recently added property reactive, which provides powerful control for
choosing what you do or do not react.
I have always found the definition of refraction hard. My understanding of the OPS5
definition was similar to your interpretation, which is a hard coding of
repetability=false. I believe some of the confusion comes from the fact that OPS5 was list
based, it didn't have objects and slots.
Mark
On 22 Jan 2013, at 04:45, Davide Sottara <dsotty(a)gmail.com> wrote:
Recently, Esteban covered the topic quite extensively, you can start
from
there:
http://ilesteban.wordpress.com/2012/11/16/about-drools-and-infinite-execu...
Best
Davide
Unfortunately, I'm afraid your proposal doesn't scale as well as impacting
performance and
expected behavior negatively
--
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.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
1:39 a.m.
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.
3:48 a.m.
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(a)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-tp4...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3:36 p.m.
Thanks for the feedback and the tip on the memory leak. I am using 5.4
distribution for my POC.
I agree with your comments. These features need to be thought thru
holistically and not piece meal.
My understanding is that the execution control semantics will not be
available till 6.x i.e. the repeatable semantics is not available in 5.4.
From a use case perspective it would be nice to see these feature
implemented -
1. At a ruleset level and which can be injected into the engine at runtime
for all rules in the ruleset, with default semantics that popular commercial
engines support.
2. Rule level semantics that can be specified for specific rules.
However from a Rule Architect perspective these are interesting and should
have appropriate controls in the API and the technical rule language i.e.
DRL to be able to control these.
My humble two cents :)
--
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.
7:53 p.m.
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
8:15 p.m.
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/jav...
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 <jrh3(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
9:49 p.m.
I just downloaded the last Drools 5.5 source code and it still has the
problem. In DefaultAgenda.java, at line 707 in the cancelActivation()
method, it calls decreaseDormantActivations(), but doesn't bother to fire an
ActivationCancelled event. If lines 701-703 are copied before line 707,
then that is a quick way to fix the problem. (I have not checked 6.0)
-Jim
--
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.
1:07 a.m.
The code looks ok to me. If an activation has fired, then you cannot cancel it. Cancelled
events are only for activations that are true and have not yet fired.
Read my previous email about how to use the unmatch listener, that will do what you want.
Mark
On 12 Mar 2013, at 20:49, jrh3 <jrh3(a)att.com> wrote:
I just downloaded the last Drools 5.5 source code and it still has
the
problem. In DefaultAgenda.java, at line 707 in the cancelActivation()
method, it calls decreaseDormantActivations(), but doesn't bother to fire an
ActivationCancelled event. If lines 701-703 are copied before line 707,
then that is a quick way to fix the problem. (I have not checked 6.0)
-Jim
--
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.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6:50 p.m.
Yes, thanks, I think that will do it. Now back to the performance question:
earlier in this thread it was mentioned that this strategy had poor
performance. How bad is it? Is there any other alternative in Drools 5.5?
-Jim
--
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.
8:58 p.m.
"poor" is a relative word. It might be fast enough for many people.
If we were to implement this in the core of the code, we could avoid a fair bit of the
work you are doing. As we implement "modify in place" all we need to do is
ignore any activations that are re-actives via a modify. We wouldn't need to do any
tracking.
Mark
On 13 Mar 2013, at 17:50, jrh3 <jrh3(a)att.com> wrote:
Yes, thanks, I think that will do it. Now back to the performance
question:
earlier in this thread it was mentioned that this strategy had poor
performance. How bad is it? Is there any other alternative in Drools 5.5?
-Jim
--
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.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4062
days inactive
4112
days old
13 comments
6 participants
participants (6)
-
Davide Sottara -
Jim Hahn -
jrh3
-
magaram -
Mark Proctor -
Wolfgang Laun