[rules-users] How is this possible?

Edson Tirelli tirelli at post.com
Tue Jul 6 12:39:22 EDT 2010


   Nelson,

   How do you know one rule is firing, but not the other? Are you checking
the audit log or using an agenda listener for that? Otherwise, if you think
the rule is not firing because of your println in the consequence, you might
be looking at the wrong "symptom". There is a huge difference between
writing an "if" like that in the consequence of a rule and writing a
constraint like "hitId == "TIGR00549"" in the condition of the rule, because
the LHS of a rule is evaluated at "insert" time while the RHS is evaluated
at the consequence fire time.

   So, from the information given, trying to imagine a scenario to explain
why the syserr in the "test" rule shows up while the one in the first rule
doesn't, here is a possible explanation:

* You insert the fact HmmHit, it activates both rules, but in a given time,
before the "Hmm Hit" rule is fired, the value of hitId changes. In this
case, the rule would still fire, but the "if" in the consequence is only
evaluated after the change (during consequence fire time) and so evaluates
to false, not printing the message.

   This is a pretty simple use case and we have several customers/users with
thousands of rules and millions of facts in a single session and they are
not facing anything like you described. So, while a bug is always a possible
explanation, we need a way to reproduce your problem in order to give you a
proper answer.

    Edson

2010/7/6 Axelrod, Nelson <naxelrod at jcvi.org>

>  Hi,
>
> We’re having some troubling problems that can be best explained by the
> following two rules.  Based on the facts inserted into the stateful
> knowledge session, we expected both rules to fire for an Hmm Hit to
> TIGR00549, but only the “Test” rule fires.  Can anyone explain how this
> could possibly occur?  There are no other rules added to the knowledge
> base.  This was tested using Drools 5.0 on Windows XP and Linux
> environments.
>
>
>
> *rule* "HMM Hit"
>
>       *when*
>
>             hit : HmmHit( aboveTrustedHit == *true* )
>
>             p     : FeatureProperty( id == hit.hitId )
>
>             f     : Feature ( featureId == hit.queryId, properties *not* *
> contains* p )
>
>       *then*
>
>             *if* (hit.getHitId().equals("TIGR00549")) {
>
>                   System.err.println("HMM Hit rule: " + hit.getHitId() + "
> " + hit.getQueryId());
>
>             }
>
>  *end*
>
>
>
> *rule* "Test"
>
>       *when*
>
>             hit : HmmHit( aboveTrustedHit == *true*, hitId == "TIGR00549")
>
>             p     : FeatureProperty( id == hit.hitId )
>
>             f     : Feature ( featureId == hit.queryId, properties *not* *
> contains* p )
>
>       *then*
>
>             System.err.println("Test rule: " + hit.getHitId() + " " +
> hit.getQueryId());
>
> *end*
>
>
>
> Notably, this error is dependent on the amount and/or order of facts loaded
> into the knowledge session although we’re talking < 20k facts total.  We
> have repeatedly found problems when running system-level tests of our
> production rules that do not appear when we run our unit tests, with issues
> such as this one that only show up after loading some number of facts that
> are unrelated to the particular fact in question.   It’s difficult to debug
> because we can see that fact handles that satisfy the when conditions are in
> the knowledge session (i.e. the same facts that fulfill the Test rule), but
> we do not have any obvious way to debug why the expected HMM Hit rule does
> not fire.
>
>
>
> Nelson
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>


-- 
 Edson Tirelli
 JBoss Drools Core Development
 JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20100706/a32ae86b/attachment.html 


More information about the rules-users mailing list