8:34 a.m.
Hello List,
Issue: Too many ACTIVATION "candidates"
Sorry for the terminology, I'm sure it is not correct.
Background Information:
- Drools.5.0.1
- using StatefulKnowledgeSession
- logging through KnowledgeRuntimeLoggerFactory.newConsoleLogger()
- after each session creation, rules are inserted from a DRL file,
facts are inserted and ksession.fireAllRules() is executed
- str[contains] and str[bidicontains] are custom operators implemented by me
If I understand Drools modus operandi correctly, as each fact is inserted
the list of candidate "nodes" to fire are constructed. Upon
fireAllRules(), a selection mechanism selects a candidate "node" to fire
and things start
rolling.
In my case, the rule at the end results in too many candidate "nodes"
created during facts insertion mode. If the rule ever gets to fire, only
one will remain since the not codition in the LHS and the logicalInserts
in the RHS exclude two firings of the rule (I hope).
fact1 has about 90 entries.
fact2 has about 25 entries.
fact3 has about 350 entries.
fact4 has about 150 entries.
fact5 has about 250 entries.
So I'm guessing that 90*25*350*150*250=29.531.250.000, i.e. 29 billion
candidate "nodes" would be created. Of course, I'm having OME long before
that!
If my analysis is correct, is any way that I could either:
a) detect that kind of combinatorial explosion during runtime (maybe a
kind of dry-run) and act accordingly
or
b) set any kind of upper limit for candidate "nodes" creation and stop
further execution thus avoiding to bring down the server along the way...
rule "r21767.2"
dialect "mvel"
when
gnId : GoodNumbers()
v1 : fact1( c21658 == "R" )
v2 : fact2( c21727 == "R" )
v3 : fact3( c21723 == "R" )
v4 : fact4( c21616 == "R" )
v5 : fact5( c21731 == "R" )
v6 : GoodsItems( gnId.goodNo==goodNo ,
goodsDescr str[bidicontains] v5.c21733 ||
goodsDescr str[bidicontains] v5.c21732 ||
goodsDescr str[bidicontains] v4.c21617 ||
goodsDescr str[bidicontains] v4.c21619 ||
goodsDescr str[bidicontains] v3.c21724 ||
goodsDescr str[bidicontains] v2.c21726 ||
goodsDescr str[bidicontains] v1.c21656 ||
goodsDescr str[bidicontains] v1.c21657 ||
goodsUnDangCode str[contains] v1.c21659 ||
goodsUnDangCode str[contains] v2.c21728 ||
goodsUnDangCode str[contains] v4.c21618 ||
goodsUnDangCode str[contains] v5.c21735 ||
combinedNome str[bidicontains] v1.c21655 ||
combinedNome str[bidicontains] v2.c21729 ||
combinedNome str[bidicontains] v4.c21615 ||
combinedNome str[bidicontains] v5.c21734
)
not mm : Marker ( mm.entityId==v6.entityID, mm.markAs=="19")
then
modify ( v6 ) {
setMarkAs("1")
}
Marker m1 = new Marker();
m1.setEntityId(v6.entityID);
m1.setMarkAs("19");
insertLogical(m1);
end
Thank you very much for your time,
-Stathis
9:48 a.m.
Are the constraints c99999 == "R" true for all Facts of type fact1,...fact5?
Is this actually the only constraint?
The not doesn't really reduce the network since it is the last pattern.
I'll wait for your answer before proposing a solution.
-W
On 22 December 2010 15:34, <rouvas(a)di.uoa.gr> wrote:
Hello List,
Issue: Too many ACTIVATION "candidates"
Sorry for the terminology, I'm sure it is not correct.
Background Information:
- Drools.5.0.1
- using StatefulKnowledgeSession
- logging through KnowledgeRuntimeLoggerFactory.newConsoleLogger()
- after each session creation, rules are inserted from a DRL file,
facts are inserted and ksession.fireAllRules() is executed
- str[contains] and str[bidicontains] are custom operators implemented by
me
If I understand Drools modus operandi correctly, as each fact is inserted
the list of candidate "nodes" to fire are constructed. Upon
fireAllRules(), a selection mechanism selects a candidate "node" to fire
and things start
rolling.
In my case, the rule at the end results in too many candidate "nodes"
created during facts insertion mode. If the rule ever gets to fire, only
one will remain since the not codition in the LHS and the logicalInserts
in the RHS exclude two firings of the rule (I hope).
fact1 has about 90 entries.
fact2 has about 25 entries.
fact3 has about 350 entries.
fact4 has about 150 entries.
fact5 has about 250 entries.
So I'm guessing that 90*25*350*150*250=29.531.250.000, i.e. 29 billion
candidate "nodes" would be created. Of course, I'm having OME long before
that!
If my analysis is correct, is any way that I could either:
a) detect that kind of combinatorial explosion during runtime (maybe a
kind of dry-run) and act accordingly
or
b) set any kind of upper limit for candidate "nodes" creation and stop
further execution thus avoiding to bring down the server along the way...
rule "r21767.2"
dialect "mvel"
when
gnId : GoodNumbers()
v1 : fact1( c21658 == "R" )
v2 : fact2( c21727 == "R" )
v3 : fact3( c21723 == "R" )
v4 : fact4( c21616 == "R" )
v5 : fact5( c21731 == "R" )
v6 : GoodsItems( gnId.goodNo==goodNo ,
goodsDescr str[bidicontains] v5.c21733 ||
goodsDescr str[bidicontains] v5.c21732 ||
goodsDescr str[bidicontains] v4.c21617 ||
goodsDescr str[bidicontains] v4.c21619 ||
goodsDescr str[bidicontains] v3.c21724 ||
goodsDescr str[bidicontains] v2.c21726 ||
goodsDescr str[bidicontains] v1.c21656 ||
goodsDescr str[bidicontains] v1.c21657 ||
goodsUnDangCode str[contains] v1.c21659 ||
goodsUnDangCode str[contains] v2.c21728 ||
goodsUnDangCode str[contains] v4.c21618 ||
goodsUnDangCode str[contains] v5.c21735 ||
combinedNome str[bidicontains] v1.c21655 ||
combinedNome str[bidicontains] v2.c21729 ||
combinedNome str[bidicontains] v4.c21615 ||
combinedNome str[bidicontains] v5.c21734
)
not mm : Marker ( mm.entityId==v6.entityID, mm.markAs=="19")
then
modify ( v6 ) {
setMarkAs("1")
}
Marker m1 = new Marker();
m1.setEntityId(v6.entityID);
m1.setMarkAs("19");
insertLogical(m1);
end
Thank you very much for your time,
-Stathis
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
11:05 a.m.
Wolfgang Laun wrote:
Are the constraints c99999 == "R" true for all Facts of
type
fact1,...fact5?
Is this actually the only constraint?
For the example rule I have posted, this is the only constraint.
The equality test for "R", in that case does not really prune the facts a
lot. The numbers I have posted are roughly correct.
The not doesn't really reduce the network since it is the last pattern.
Indeed. I have found this to be true the hard way!
I'll wait for your answer before proposing a solution.
Please, take into consideration the general case for this kind of problem.
I know that the particular rule I have posted can be re-written as a
series of 5 rules that each one test for a single fact.
I have done so for this particular rule and there was no issue getting a
result.
The problem is, that I do not have direct control over the rules, the
users write them (through a custom interface).
So I am actually wondering if there is a way to foresee these kinds of
problems without actually executing the rules.
Thank you for your time,
-Stathis
-W
On 22 December 2010 15:34, <rouvas(a)di.uoa.gr> wrote:
> Hello List,
>
> Issue: Too many ACTIVATION "candidates"
>
> Sorry for the terminology, I'm sure it is not correct.
>
> Background Information:
> - Drools.5.0.1
> - using StatefulKnowledgeSession
> - logging through KnowledgeRuntimeLoggerFactory.newConsoleLogger()
> - after each session creation, rules are inserted from a DRL file,
> facts are inserted and ksession.fireAllRules() is executed
> - str[contains] and str[bidicontains] are custom operators implemented
> by
> me
>
> If I understand Drools modus operandi correctly, as each fact is
> inserted
> the list of candidate "nodes" to fire are constructed. Upon
> fireAllRules(), a selection mechanism selects a candidate "node" to fire
> and things start
> rolling.
>
> In my case, the rule at the end results in too many candidate "nodes"
> created during facts insertion mode. If the rule ever gets to fire, only
> one will remain since the not codition in the LHS and the logicalInserts
> in the RHS exclude two firings of the rule (I hope).
>
> fact1 has about 90 entries.
> fact2 has about 25 entries.
> fact3 has about 350 entries.
> fact4 has about 150 entries.
> fact5 has about 250 entries.
>
> So I'm guessing that 90*25*350*150*250=29.531.250.000, i.e. 29 billion
> candidate "nodes" would be created. Of course, I'm having OME long
> before
> that!
>
> If my analysis is correct, is any way that I could either:
>
> a) detect that kind of combinatorial explosion during runtime (maybe a
> kind of dry-run) and act accordingly
>
> or
>
> b) set any kind of upper limit for candidate "nodes" creation and stop
> further execution thus avoiding to bring down the server along the
> way...
>
> rule "r21767.2"
> dialect "mvel"
> when
> gnId : GoodNumbers()
> v1 : fact1( c21658 == "R" )
> v2 : fact2( c21727 == "R" )
> v3 : fact3( c21723 == "R" )
> v4 : fact4( c21616 == "R" )
> v5 : fact5( c21731 == "R" )
> v6 : GoodsItems( gnId.goodNo==goodNo ,
> goodsDescr str[bidicontains] v5.c21733 ||
> goodsDescr str[bidicontains] v5.c21732 ||
> goodsDescr str[bidicontains] v4.c21617 ||
> goodsDescr str[bidicontains] v4.c21619 ||
> goodsDescr str[bidicontains] v3.c21724 ||
> goodsDescr str[bidicontains] v2.c21726 ||
> goodsDescr str[bidicontains] v1.c21656 ||
> goodsDescr str[bidicontains] v1.c21657 ||
> goodsUnDangCode str[contains] v1.c21659 ||
> goodsUnDangCode str[contains] v2.c21728 ||
> goodsUnDangCode str[contains] v4.c21618 ||
> goodsUnDangCode str[contains] v5.c21735 ||
> combinedNome str[bidicontains] v1.c21655 ||
> combinedNome str[bidicontains] v2.c21729 ||
> combinedNome str[bidicontains] v4.c21615 ||
> combinedNome str[bidicontains] v5.c21734
> )
> not mm : Marker ( mm.entityId==v6.entityID,
> mm.markAs=="19")
> then
> modify ( v6 ) {
> setMarkAs("1")
> }
> Marker m1 = new Marker();
> m1.setEntityId(v6.entityID);
> m1.setMarkAs("19");
> insertLogical(m1);
> end
>
> Thank you very much for your time,
> -Stathis
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
11:26 a.m.
Your problem is you have a series of 5 facts which have no dependent constraints between
them, the constraint is only applied by the last fact and even that isn't constraining
as it involves ors not ands (if there is a fact 5 that matches then every combination of
valid facts1-4 would be included).
I'd say that this rule should actually be written as 16 rules - one for each of the
or'd together GoodsItems conditions, each of these rules would only depend on a single
Fact and you won't get into this problem.
Who controls the custom interface? If you can control then the simplest solution is to
prevent them doing or's of conditions (though perhaps this may not fly with your
customers). Alternatively have the interface output an intermediate form which you can
then control the compilation of.
Thomas.
-----Original Message-----
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-
bounces(a)lists.jboss.org] On Behalf Of rouvas(a)di.uoa.gr
Sent: 22 December 2010 17:05
To: Wolfgang Laun
Cc: Rules Users List
Subject: Re: [rules-users] Too many ACTIVATION "candidates"
Wolfgang Laun wrote:
> Are the constraints c99999 == "R" true for all Facts of type
> fact1,...fact5?
> Is this actually the only constraint?
For the example rule I have posted, this is the only constraint.
The equality test for "R", in that case does not really prune the facts a
lot. The numbers I have posted are roughly correct.
>
> The not doesn't really reduce the network since it is the last pattern.
Indeed. I have found this to be true the hard way!
>
> I'll wait for your answer before proposing a solution.
Please, take into consideration the general case for this kind of problem.
I know that the particular rule I have posted can be re-written as a
series of 5 rules that each one test for a single fact.
I have done so for this particular rule and there was no issue getting a
result.
The problem is, that I do not have direct control over the rules, the
users write them (through a custom interface).
So I am actually wondering if there is a way to foresee these kinds of
problems without actually executing the rules.
Thank you for your time,
-Stathis
>
> -W
>
>
>
> On 22 December 2010 15:34, <rouvas(a)di.uoa.gr> wrote:
>
>> Hello List,
>>
>> Issue: Too many ACTIVATION "candidates"
>>
>> Sorry for the terminology, I'm sure it is not correct.
>>
>> Background Information:
>> - Drools.5.0.1
>> - using StatefulKnowledgeSession
>> - logging through KnowledgeRuntimeLoggerFactory.newConsoleLogger()
>> - after each session creation, rules are inserted from a DRL file,
>> facts are inserted and ksession.fireAllRules() is executed
>> - str[contains] and str[bidicontains] are custom operators implemented
>> by
>> me
>>
>> If I understand Drools modus operandi correctly, as each fact is
>> inserted
>> the list of candidate "nodes" to fire are constructed. Upon
>> fireAllRules(), a selection mechanism selects a candidate "node" to
fire
>> and things start
>> rolling.
>>
>> In my case, the rule at the end results in too many candidate "nodes"
>> created during facts insertion mode. If the rule ever gets to fire, only
>> one will remain since the not codition in the LHS and the logicalInserts
>> in the RHS exclude two firings of the rule (I hope).
>>
>> fact1 has about 90 entries.
>> fact2 has about 25 entries.
>> fact3 has about 350 entries.
>> fact4 has about 150 entries.
>> fact5 has about 250 entries.
>>
>> So I'm guessing that 90*25*350*150*250=29.531.250.000, i.e. 29 billion
>> candidate "nodes" would be created. Of course, I'm having OME
long
>> before
>> that!
>>
>> If my analysis is correct, is any way that I could either:
>>
>> a) detect that kind of combinatorial explosion during runtime (maybe a
>> kind of dry-run) and act accordingly
>>
>> or
>>
>> b) set any kind of upper limit for candidate "nodes" creation and
stop
>> further execution thus avoiding to bring down the server along the
>> way...
>>
>> rule "r21767.2"
>> dialect "mvel"
>> when
>> gnId : GoodNumbers()
>> v1 : fact1( c21658 == "R" )
>> v2 : fact2( c21727 == "R" )
>> v3 : fact3( c21723 == "R" )
>> v4 : fact4( c21616 == "R" )
>> v5 : fact5( c21731 == "R" )
>> v6 : GoodsItems( gnId.goodNo==goodNo ,
>> goodsDescr str[bidicontains] v5.c21733 ||
>> goodsDescr str[bidicontains] v5.c21732 ||
>> goodsDescr str[bidicontains] v4.c21617 ||
>> goodsDescr str[bidicontains] v4.c21619 ||
>> goodsDescr str[bidicontains] v3.c21724 ||
>> goodsDescr str[bidicontains] v2.c21726 ||
>> goodsDescr str[bidicontains] v1.c21656 ||
>> goodsDescr str[bidicontains] v1.c21657 ||
>> goodsUnDangCode str[contains] v1.c21659 ||
>> goodsUnDangCode str[contains] v2.c21728 ||
>> goodsUnDangCode str[contains] v4.c21618 ||
>> goodsUnDangCode str[contains] v5.c21735 ||
>> combinedNome str[bidicontains] v1.c21655 ||
>> combinedNome str[bidicontains] v2.c21729 ||
>> combinedNome str[bidicontains] v4.c21615 ||
>> combinedNome str[bidicontains] v5.c21734
>> )
>> not mm : Marker ( mm.entityId==v6.entityID,
>> mm.markAs=="19")
>> then
>> modify ( v6 ) {
>> setMarkAs("1")
>> }
>> Marker m1 = new Marker();
>> m1.setEntityId(v6.entityID);
>> m1.setMarkAs("19");
>> insertLogical(m1);
>> end
>>
>> Thank you very much for your time,
>> -Stathis
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received
this message in error, please immediately notify the postmaster(a)nds.com and delete it from
your system as well as any copies. The content of e-mails as well as traffic data may be
monitored by NDS for employment and security purposes. To protect the environment please
do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United
Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603
8808 40-00
**************************************************************************************
3:11 a.m.
Swindells, Thomas wrote:
Your problem is you have a series of 5 facts which have no dependent
constraints between them, the constraint is only applied by the last fact
and even that isn't constraining as it involves ors not ands (if there is
a fact 5 that matches then every combination of valid facts1-4 would be
included).
Indeed that is the issue.
In my case, the facts 1...5 are not related and the only constraint is
specified at the last fact.
I'd say that this rule should actually be written as 16 rules - one for
each of the or'd together GoodsItems conditions, each of these rules would
only depend on a single Fact and you won't get into this problem.
True. This rule can be re-written as a series of 5 rules that do not
exhibit the explosion of activation candidates. I have done so and
everything worked fine.
Who controls the custom interface? If you can control then the simplest
solution is to prevent them doing or's of conditions (though perhaps this
may not fly with your customers). Alternatively have the interface output
an intermediate form which you can then control the compilation of.
The custom interface, you may think of it as a simplified Guvnor, is under
my total control as I've implemented it.
The problem is, that the user can use it to write these kinds of rules.
In theory, rule rewriting could be possible, but I'm not sure I can detect
these kinds of dependencies for any kind of rule that may be written.
It there is a way that these kinds of cartesian product of activation
candidates can be estimated before hand (either by analyzing the rule or
by some other means), it would be great.
Any ideas are welcomed.
-Stathis
Thomas.
> -----Original Message-----
> From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-
> bounces(a)lists.jboss.org] On Behalf Of rouvas(a)di.uoa.gr
> Sent: 22 December 2010 17:05
> To: Wolfgang Laun
> Cc: Rules Users List
> Subject: Re: [rules-users] Too many ACTIVATION "candidates"
>
> Wolfgang Laun wrote:
> > Are the constraints c99999 == "R" true for all Facts of type
> > fact1,...fact5?
> > Is this actually the only constraint?
>
> For the example rule I have posted, this is the only constraint.
> The equality test for "R", in that case does not really prune the facts
> a
> lot. The numbers I have posted are roughly correct.
>
> >
> > The not doesn't really reduce the network since it is the last
> pattern.
>
> Indeed. I have found this to be true the hard way!
>
> >
> > I'll wait for your answer before proposing a solution.
>
> Please, take into consideration the general case for this kind of
> problem.
> I know that the particular rule I have posted can be re-written as a
> series of 5 rules that each one test for a single fact.
> I have done so for this particular rule and there was no issue getting a
> result.
>
> The problem is, that I do not have direct control over the rules, the
> users write them (through a custom interface).
>
> So I am actually wondering if there is a way to foresee these kinds of
> problems without actually executing the rules.
>
> Thank you for your time,
> -Stathis
>
>
> >
> > -W
> >
> >
> >
> > On 22 December 2010 15:34, <rouvas(a)di.uoa.gr> wrote:
> >
> >> Hello List,
> >>
> >> Issue: Too many ACTIVATION "candidates"
> >>
> >> Sorry for the terminology, I'm sure it is not correct.
> >>
> >> Background Information:
> >> - Drools.5.0.1
> >> - using StatefulKnowledgeSession
> >> - logging through KnowledgeRuntimeLoggerFactory.newConsoleLogger()
> >> - after each session creation, rules are inserted from a DRL file,
> >> facts are inserted and ksession.fireAllRules() is executed
> >> - str[contains] and str[bidicontains] are custom operators
> implemented
> >> by
> >> me
> >>
> >> If I understand Drools modus operandi correctly, as each fact is
> >> inserted
> >> the list of candidate "nodes" to fire are constructed. Upon
> >> fireAllRules(), a selection mechanism selects a candidate "node"
to
> fire
> >> and things start
> >> rolling.
> >>
> >> In my case, the rule at the end results in too many candidate
"nodes"
> >> created during facts insertion mode. If the rule ever gets to fire,
> only
> >> one will remain since the not codition in the LHS and the
> logicalInserts
> >> in the RHS exclude two firings of the rule (I hope).
> >>
> >> fact1 has about 90 entries.
> >> fact2 has about 25 entries.
> >> fact3 has about 350 entries.
> >> fact4 has about 150 entries.
> >> fact5 has about 250 entries.
> >>
> >> So I'm guessing that 90*25*350*150*250=29.531.250.000, i.e. 29
> billion
> >> candidate "nodes" would be created. Of course, I'm having OME
long
> >> before
> >> that!
> >>
> >> If my analysis is correct, is any way that I could either:
> >>
> >> a) detect that kind of combinatorial explosion during runtime (maybe
> a
> >> kind of dry-run) and act accordingly
> >>
> >> or
> >>
> >> b) set any kind of upper limit for candidate "nodes" creation and
> stop
> >> further execution thus avoiding to bring down the server along the
> >> way...
> >>
> >> rule "r21767.2"
> >> dialect "mvel"
> >> when
> >> gnId : GoodNumbers()
> >> v1 : fact1( c21658 == "R" )
> >> v2 : fact2( c21727 == "R" )
> >> v3 : fact3( c21723 == "R" )
> >> v4 : fact4( c21616 == "R" )
> >> v5 : fact5( c21731 == "R" )
> >> v6 : GoodsItems( gnId.goodNo==goodNo ,
> >> goodsDescr str[bidicontains] v5.c21733 ||
> >> goodsDescr str[bidicontains] v5.c21732 ||
> >> goodsDescr str[bidicontains] v4.c21617 ||
> >> goodsDescr str[bidicontains] v4.c21619 ||
> >> goodsDescr str[bidicontains] v3.c21724 ||
> >> goodsDescr str[bidicontains] v2.c21726 ||
> >> goodsDescr str[bidicontains] v1.c21656 ||
> >> goodsDescr str[bidicontains] v1.c21657 ||
> >> goodsUnDangCode str[contains] v1.c21659 ||
> >> goodsUnDangCode str[contains] v2.c21728 ||
> >> goodsUnDangCode str[contains] v4.c21618 ||
> >> goodsUnDangCode str[contains] v5.c21735 ||
> >> combinedNome str[bidicontains] v1.c21655 ||
> >> combinedNome str[bidicontains] v2.c21729 ||
> >> combinedNome str[bidicontains] v4.c21615 ||
> >> combinedNome str[bidicontains] v5.c21734
> >> )
> >> not mm : Marker ( mm.entityId==v6.entityID,
> >> mm.markAs=="19")
> >> then
> >> modify ( v6 ) {
> >> setMarkAs("1")
> >> }
> >> Marker m1 = new Marker();
> >> m1.setEntityId(v6.entityID);
> >> m1.setMarkAs("19");
> >> insertLogical(m1);
> >> end
> >>
> >> Thank you very much for your time,
> >> -Stathis
> >>
> >>
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-users
> >>
> >
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
**************************************************************************************
This message is confidential and intended only for the addressee. If you
have received this message in error, please immediately notify the
postmaster(a)nds.com and delete it from your system as well as any copies.
The content of e-mails as well as traffic data may be monitored by NDS for
employment and security purposes. To protect the environment please do not
print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18
4EX, United Kingdom. A company registered in England and Wales. Registered
no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************
3:37 a.m.
> I'd say that this rule should actually be written as 16
rules - one for
> each of the or'd together GoodsItems conditions, each of these rules would
> only depend on a single Fact and you won't get into this problem.
True. This rule can be re-written as a series of 5 rules that do not
exhibit the explosion of activation candidates. I have done so and
everything worked fine.
>
> Who controls the custom interface? If you can control then the simplest
> solution is to prevent them doing or's of conditions (though perhaps this
> may not fly with your customers). Alternatively have the interface output
> an intermediate form which you can then control the compilation of.
The custom interface, you may think of it as a simplified Guvnor, is under
my total control as I've implemented it.
The problem is, that the user can use it to write these kinds of rules.
In theory, rule rewriting could be possible, but I'm not sure I can detect
these kinds of dependencies for any kind of rule that may be written.
No, I think they should be rewritten as a series of 16 rules (one for each '||'.
You could remove the option from the user of being able to 'or' together
conditions and require each thing to be written as separate rules. This should reduce the
Cartesian products for the majority of cases (although creative users could still possibly
write statements like (fact1 != "thiswillneverhappen" && fact2 !=
"thiswillneverhappen2"...)/
It there is a way that these kinds of cartesian product of
activation
candidates can be estimated before hand (either by analyzing the rule or
by some other means), it would be great.
Any ideas are welcomed.
It depends on how accurate you want it.
Simplist option is to restrict the number of facts that a rule can match against (if they
can only match against 3 facts the Cartesian product probably isn't too bad).
Slightly more complicated you can assume the worst case scenario that every value of each
fact type is included and multiple the count of each included fact together, if it exceeds
a configured limit you decide that potentially the rule is too complicated.
Getting much more complicated is to perform a much more accurate estimation of each fact
based upon the constraints. You could either do this in code (perhaps a db query or some
other way to apply the constraint).
Another way to do this would be to decompose the rules so that you accumulate the result
of each fact constraint first, check whether too many facts have been included and then
use a from for each accumulation at the end (or something like that anyway).
Thomas
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received
this message in error, please immediately notify the postmaster(a)nds.com and delete it from
your system as well as any copies. The content of e-mails as well as traffic data may be
monitored by NDS for employment and security purposes. To protect the environment please
do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United
Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603
8808 40-00
**************************************************************************************
8:37 p.m.
One way of detecting cartesian products is to model the LHS as a graph, with object
patterns being nodes, and conditions that compare two objects being an edge. If the LHS
graph has unconnected subgraphs then it contains a cartesian product. You can make this
more sophisticated by excluding classes that you know have few instances in working
memory, like control objects.
GreG
On Dec 23, 2010, at 3:37, "Swindells, Thomas" <TSwindells(a)nds.com> wrote:
>> I'd say that this rule should actually be written as 16
rules - one for
>> each of the or'd together GoodsItems conditions, each of these rules would
>> only depend on a single Fact and you won't get into this problem.
>
> True. This rule can be re-written as a series of 5 rules that do not
> exhibit the explosion of activation candidates. I have done so and
> everything worked fine.
>
>>
>> Who controls the custom interface? If you can control then the simplest
>> solution is to prevent them doing or's of conditions (though perhaps this
>> may not fly with your customers). Alternatively have the interface output
>> an intermediate form which you can then control the compilation of.
>
> The custom interface, you may think of it as a simplified Guvnor, is under
> my total control as I've implemented it.
> The problem is, that the user can use it to write these kinds of rules.
> In theory, rule rewriting could be possible, but I'm not sure I can detect
> these kinds of dependencies for any kind of rule that may be written.
No, I think they should be rewritten as a series of 16 rules (one for each '||'.
You could remove the option from the user of being able to 'or' together
conditions and require each thing to be written as separate rules. This should reduce the
Cartesian products for the majority of cases (although creative users could still possibly
write statements like (fact1 != "thiswillneverhappen" && fact2 !=
"thiswillneverhappen2"...)/
> It there is a way that these kinds of cartesian product of activation
> candidates can be estimated before hand (either by analyzing the rule or
> by some other means), it would be great.
> Any ideas are welcomed.
It depends on how accurate you want it.
Simplist option is to restrict the number of facts that a rule can match against (if they
can only match against 3 facts the Cartesian product probably isn't too bad).
Slightly more complicated you can assume the worst case scenario that every value of each
fact type is included and multiple the count of each included fact together, if it exceeds
a configured limit you decide that potentially the rule is too complicated.
Getting much more complicated is to perform a much more accurate estimation of each fact
based upon the constraints. You could either do this in code (perhaps a db query or some
other way to apply the constraint).
Another way to do this would be to decompose the rules so that you accumulate the result
of each fact constraint first, check whether too many facts have been included and then
use a from for each accumulation at the end (or something like that anyway).
Thomas
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received
this message in error, please immediately notify the postmaster(a)nds.com and delete it from
your system as well as any copies. The content of e-mails as well as traffic data may be
monitored by NDS for employment and security purposes. To protect the environment please
do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United
Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603
8808 40-00
**************************************************************************************
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3:18 a.m.
Thanks a lot Greg.
This is definitevely something I must look into.
-Stathis
Greg Barton wrote:
One way of detecting cartesian products is to model the LHS as a
graph,
with object patterns being nodes, and conditions that compare two objects
being an edge. If the LHS graph has unconnected subgraphs then it
contains a cartesian product. You can make this more sophisticated by
excluding classes that you know have few instances in working memory, like
control objects.
GreG
On Dec 23, 2010, at 3:37, "Swindells, Thomas" <TSwindells(a)nds.com>
wrote:
>>> I'd say that this rule should actually be written as 16 rules - one
>>> for
>>> each of the or'd together GoodsItems conditions, each of these rules
>>> would
>>> only depend on a single Fact and you won't get into this problem.
>>
>> True. This rule can be re-written as a series of 5 rules that do not
>> exhibit the explosion of activation candidates. I have done so and
>> everything worked fine.
>>
>>>
>>> Who controls the custom interface? If you can control then the
>>> simplest
>>> solution is to prevent them doing or's of conditions (though perhaps
>>> this
>>> may not fly with your customers). Alternatively have the interface
>>> output
>>> an intermediate form which you can then control the compilation of.
>>
>> The custom interface, you may think of it as a simplified Guvnor, is
>> under
>> my total control as I've implemented it.
>> The problem is, that the user can use it to write these kinds of rules.
>> In theory, rule rewriting could be possible, but I'm not sure I can
>> detect
>> these kinds of dependencies for any kind of rule that may be written.
>
> No, I think they should be rewritten as a series of 16 rules (one for
> each '||'.
> You could remove the option from the user of being able to 'or' together
> conditions and require each thing to be written as separate rules. This
> should reduce the Cartesian products for the majority of cases (although
> creative users could still possibly write statements like (fact1 !=
> "thiswillneverhappen" && fact2 !=
"thiswillneverhappen2"...)/
>
>> It there is a way that these kinds of cartesian product of activation
>> candidates can be estimated before hand (either by analyzing the rule
>> or
>> by some other means), it would be great.
>> Any ideas are welcomed.
> It depends on how accurate you want it.
> Simplist option is to restrict the number of facts that a rule can match
> against (if they can only match against 3 facts the Cartesian product
> probably isn't too bad).
> Slightly more complicated you can assume the worst case scenario that
> every value of each fact type is included and multiple the count of each
> included fact together, if it exceeds a configured limit you decide that
> potentially the rule is too complicated.
> Getting much more complicated is to perform a much more accurate
> estimation of each fact based upon the constraints. You could either do
> this in code (perhaps a db query or some other way to apply the
> constraint).
> Another way to do this would be to decompose the rules so that you
> accumulate the result of each fact constraint first, check whether too
> many facts have been included and then use a from for each accumulation
> at the end (or something like that anyway).
>
> Thomas
>
>
>
**************************************************************************************
> This message is confidential and intended only for the addressee. If you
> have received this message in error, please immediately notify the
> postmaster(a)nds.com and delete it from your system as well as any copies.
> The content of e-mails as well as traffic data may be monitored by NDS
> for employment and security purposes. To protect the environment please
> do not print this e-mail unless necessary.
>
> NDS Limited. Registered Office: One London Road, Staines, Middlesex,
> TW18 4EX, United Kingdom. A company registered in England and Wales.
> Registered no. 3080780. VAT no. GB 603 8808 40-00
>
**************************************************************************************
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
6:16 a.m.
New subject: [SOLVED] Too many ACTIVATION "candidates"
Greg,
thank you for your advise.
That helped me tackle the problem.
-Stathis
Greg Barton wrote:
One way of detecting cartesian products is to model the LHS as a
graph,
with object patterns being nodes, and conditions that compare two objects
being an edge. If the LHS graph has unconnected subgraphs then it
contains a cartesian product. You can make this more sophisticated by
excluding classes that you know have few instances in working memory, like
control objects.
GreG
On Dec 23, 2010, at 3:37, "Swindells, Thomas" <TSwindells(a)nds.com>
wrote:
>>> I'd say that this rule should actually be written as 16 rules - one
>>> for
>>> each of the or'd together GoodsItems conditions, each of these rules
>>> would
>>> only depend on a single Fact and you won't get into this problem.
>>
>> True. This rule can be re-written as a series of 5 rules that do not
>> exhibit the explosion of activation candidates. I have done so and
>> everything worked fine.
>>
>>>
>>> Who controls the custom interface? If you can control then the
>>> simplest
>>> solution is to prevent them doing or's of conditions (though perhaps
>>> this
>>> may not fly with your customers). Alternatively have the interface
>>> output
>>> an intermediate form which you can then control the compilation of.
>>
>> The custom interface, you may think of it as a simplified Guvnor, is
>> under
>> my total control as I've implemented it.
>> The problem is, that the user can use it to write these kinds of rules.
>> In theory, rule rewriting could be possible, but I'm not sure I can
>> detect
>> these kinds of dependencies for any kind of rule that may be written.
>
> No, I think they should be rewritten as a series of 16 rules (one for
> each '||'.
> You could remove the option from the user of being able to 'or' together
> conditions and require each thing to be written as separate rules. This
> should reduce the Cartesian products for the majority of cases (although
> creative users could still possibly write statements like (fact1 !=
> "thiswillneverhappen" && fact2 !=
"thiswillneverhappen2"...)/
>
>> It there is a way that these kinds of cartesian product of activation
>> candidates can be estimated before hand (either by analyzing the rule
>> or
>> by some other means), it would be great.
>> Any ideas are welcomed.
> It depends on how accurate you want it.
> Simplist option is to restrict the number of facts that a rule can match
> against (if they can only match against 3 facts the Cartesian product
> probably isn't too bad).
> Slightly more complicated you can assume the worst case scenario that
> every value of each fact type is included and multiple the count of each
> included fact together, if it exceeds a configured limit you decide that
> potentially the rule is too complicated.
> Getting much more complicated is to perform a much more accurate
> estimation of each fact based upon the constraints. You could either do
> this in code (perhaps a db query or some other way to apply the
> constraint).
> Another way to do this would be to decompose the rules so that you
> accumulate the result of each fact constraint first, check whether too
> many facts have been included and then use a from for each accumulation
> at the end (or something like that anyway).
>
> Thomas
>
>
>
**************************************************************************************
> This message is confidential and intended only for the addressee. If you
> have received this message in error, please immediately notify the
> postmaster(a)nds.com and delete it from your system as well as any copies.
> The content of e-mails as well as traffic data may be monitored by NDS
> for employment and security purposes. To protect the environment please
> do not print this e-mail unless necessary.
>
> NDS Limited. Registered Office: One London Road, Staines, Middlesex,
> TW18 4EX, United Kingdom. A company registered in England and Wales.
> Registered no. 3080780. VAT no. GB 603 8808 40-00
>
**************************************************************************************
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
4877
days inactive
4884
days old
8 comments
4 participants
participants (4)
-
Greg Barton -
rouvas＠di.uoa.gr -
Swindells, Thomas -
Wolfgang Laun