[rules-users] Why so many ACTIVATION/DEACTIVATION events?

Tue Sep 1 16:37:02 EDT 2009

Thanks for the reply, Wolfgang.

If I understand your scenario correctly, I think you are describing the expected activation patterns during the firing of this rule. I agree with your description, and our logs show something very similar. 

Responding to your specific suggestions - 
1. The data model is a given - we have no control over it.
2. No-loop true is used on all our rules, including this one. In the example, I had removed rule attributes for brevity.
3. Unfortunately, the data semantics are also not under our control, and the rule has to test all these objects in order to work right.

Further diagnosis indicates that what looked like multi-activated rules are actually not all the same rule instance, even though their content is the same - the log4j appender being used was improperly trimming the ends of the distinguishing identifiers when it logged them. However, although these rules are different instances of the rule, their conditions are identical, so I'm still puzzled why a set of conditions that are not met in the data will lead to an activation / deactivation. I'm going to have to dig deeper, I guess.

Thanks.

Tom Murphy
Business Process Consultant
Wells Fargo HCFG - CORE Deal Decisioning Platform
800 S. Jordan Creek Parkway | West Des Moines, IA 50266
MAC: X2301-01B
Office: 515 324 4853 | Mobile: 941 320 8014
This message may contain confidential and/or privileged information.  If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein.  If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message.  Thank you for your cooperation.

Date: Tue, 1 Sep 2009 08:04:46 +0200
From: Wolfgang Laun <wolfgang.laun at gmail.com>
Subject: Re: [rules-users] Why so many ACTIVATION/DEACTIVATION events?
To: Rules Users List <rules-users at lists.jboss.org>
Message-ID:
	<17de7ee80908312304y52499c00m88f3a45c6b225825 at mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"

Hi Tom,

your understanding of "Activation" is fine, so let's see what happens if
your rule "RS..." fires. (I'm abbreviating names.)

Initially, neither PolSet nor PolSetId are there, so "RS..." activation #1
is on the agenda, fires and executes the consequence.

Now, PolSet is created and inserted as a new fact. This causes reevaluation
of all rules, including "RS..." (with its activation #1 still executing).
The not(PolSet and PolSetId) is still true, and therefore the LHS yields
true, and "RS..." activation #2 is put on the agenda. Continuing with #1,
PolSetId is created and inserted, causing reevaluations of all rules. Now
the not(PolSet and PolSetId) is false, so that "RS..." #2 is removed again.

As for a remedy, you might consider several approaches. Notice that I have
to guess what else might be going on, so I could be way off with (3), for
instance.

(1) Is it really necessary to have PolSet and PolSetId as two separate
facts? (It might still be possible to have PolSet as an *object* for
establishing linkage to the parental TransDet, without being a *fact*.)
(2) Add the rule attribute no-loop true to "RS..."
(3) If the absences of PolSetId alone is sufficient for triggering the
rule(s), omit PolSet from rule "RS..." and add another rule which creates
the "missing link" when you have a TransDet, the existence of at least one
PolSetId and no matching PolSet, to create the latter.

Cheers
-W

2009/9/1 <Tom.E.Murphy at wellsfargo.com>

>  We have a fairly complex object model, but we?re still puzzled ? I
> thought that the definition of ?Activation? was that the data matched on all
> conditions of a rule, and therefore the rule was entered into the agenda
> (activated).
> If that is true, I cannot figure out why we?re experiencing this.
> As our number of rules increases, we?re seeing exponential increases in
> repetitive activation/deactivation pairs, even on rules where we know the
> data does not match the conditions.
>
> Example:
> The following rule (abbreviated here) creates an object of type PolicySet
> if there are none that match the conditions.
> I would expect this rule to activate once, then fire, wherein the matching
> PolicySet is created, and then never activate again since the absence of a
> matching PolicySet object is never again true.
> However, in a rule base of ~4,000 rules, we see this rule activating 975
> times and deactivating 975 times. This is just one example ? nearly all our
> rules do this, and it is seriously impacting decisioning performance.
>
> Have I misunderstood the meaning of ?activation?? Can anyone help me
> understand this?
>
> rule "RS6090.1.12_RF7007_50001012"
>         when
>                 LendingProduct ( $exitStrategyType1 : exitStrategyType )
>                 Features ( $lienPriority1 : lienPriority )
>                 DecisionResultsInfo ( $dealRiskCategory1 : dealRiskCategory
> )
>                 TransactionDetail ( $parentTransactionDetail1Id : myId )
>                 not
>                 (
>                         PolicySet ( $parentPolicySet_1_Id : myId, parentId
> == $parentTransactionDetail1Id )
>                         and
>                         PolicySetIdentifier ( parentId ==
> $parentPolicySet_1_Id
> ,  lienPriority == $lienPriority1
>                                 , exitStrategyType == $exitStrategyType1
> , dealRiskCategory == $dealRiskCategory1)
>                 )
>         then
>                 // Content removed? rule creates the policy set and the
> policy set identifier, and initializes all appropriate elements
>                 // After doing so, why does it activate/deactivate 1800+
> times in a rule base of 4000 rules?
>                 System.out.println("6090 fired.");
> End
>
> Thanks.
> *Tom Murphy
> **Business Process Consultant
> Wells Fargo HCFG - CORE Deal Decisioning Platform
> 800 S. Jordan Creek Parkway | West Des Moines, IA 50266
> MAC: **X2301-01B
> **Office: **515 324 4853** | Mobile: 941 320 8014
> **This message may contain confidential and/or privileged information.  If
> you are not the addressee or authorized to receive this for the addressee,
> you must not use, copy, disclose, or take any action based on this message
> or any information herein.  If you have received this message in error,
> please advise the sender immediately by reply e-mail and delete this
> message.  Thank you for your cooperation.*
>
>
>
>