[rules-users] Too many ACTIVATION "candidates"
rouvas at di.uoa.gr
rouvas at di.uoa.gr
Thu Dec 23 04:11:31 EST 2010
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 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