[rules-users] Too many ACTIVATION "candidates"
Swindells, Thomas
TSwindells at nds.com
Wed Dec 22 12:26:19 EST 2010
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 at lists.jboss.org [mailto:rules-users-
> bounces at lists.jboss.org] On Behalf Of rouvas at 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 at 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 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
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster at 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
**************************************************************************************
More information about the rules-users
mailing list