Possible bug when using forall and collection operations
165 views
Skip to first unread message
Matthew Ross
Dec 14, 2017, 7:58:21 PM12/14/17
to Drools Usage
Hi All,
I'm new to Drools and learning from the book "Mastering JBoss Drools 6". In the examples provided at:
there is an example rule in Chapter 02 called order-discount-rules.drl
When testing this rule I found that the results are not correct. The rule seems to always fire not matter what. I believe the issue is with the $lines assignment:
$o: Order( $lines : orderLines.size >= 2, $customer: customer, discount == null )
This doesn't look like proper syntax to me. So, when I modify that line to look like this:
$o: Order( orderLines.size >= 2, $lines : orderLines, $customer: customer, discount == null )
The rule starts getting skipped when it's supposed to be skipped. i.e. if the data doesn't match the condition, the rule condition doesn't evaluate to true.
However, when the rule is supposed to be triggered (because the test data matches the rule conditions) the rule only gets triggered sporadically. i.e. if I run the rule with a positive test case 10 times, the rule only gets triggered maybe 5 out of 10 times.
Further, I found that if I assign a salience of -100 (the lowest priority of all rules), then the rule gets triggered 10 out of 10 times. That is because this rule depends on other rules being fired, which modify the data in memory to produce the state required for this rule to trigger.
This indicates to me that the rule is only being triggered when the engine happens to initially evaluate this rule later than the rules this one depends on. Either the engine has randomly decided to run this rule last, or I have to tell the engine to run it last.
Finally, this indicates to me that there is a bug in Drools that prevents this type of query from knowing about changes to its data in memory. Even though the other rules run after this one, and the state of the data creates a positive test case for this condition, this rule doesn't get re-triggered. It's always evaluated only once.
P.S. I tried this logic in both Drools 6.3.0.Final and 7.0.0.Final and found they behave the same.
Any and all help would be appreciated on this. I think the code examples in drools6-dev-guide should be updated to reflect the correct syntax.
Matthew Ross
Dec 15, 2017, 4:56:55 PM12/15/17
to Drools Usage
UPDATE - When I remove the hashCode override in the Item class, the rule starts working as expected. This seems to indicate that Drools is reliant on the hashCode method to determine when a Fact gets updated in memory. If the underlying structure of the memory is something like a HashMap then I can see why this bug might exist. Anytime a Fact that already exists in memory is updated such that its hashCode value changes, Drools should be actively removing the current fact from memory and inserting it anew, so that the fact is referenced correctly. If not, then this bug might appear.
I think the default hashCode method is working because it's just referring to the object's location in memory, as opposed to an aggregate hash value of the fields.
Can anyone shed further light on this issue? Is this a bug in Drools or am I missing something?
Mario Fusco
Dec 16, 2017, 3:34:12 AM12/16/17
to Drools Usage
"such that its hashCode value changes" ???
Sorry but the hashCode of an object should NEVER change. This is not a Drools issue, but just plain Java. If your Object implementation won't work as key of a simple HashMap how can you expect that it will work with something much more complex like a rule engine?--
You received this message because you are subscribed to the Google Groups "Drools Usage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drools-usage+unsubscribe@googlegroups.com.
To post to this group, send email to drools...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/drools-usage/aa0bdfb6-28c4-492b-ab73-85046c2b1215%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages