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, <rou...@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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
