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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @
www.jboss.com