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
>