]
Edson Tirelli updated JBRULES-3103:
-----------------------------------
Fix Version/s: 5.4.0.Beta1
Priority: Critical (was: Major)
Assignee: Edson Tirelli (was: Mark Proctor)
"A and not(B after A)" type rules don't fire when
session clock has negative values (pre Unix epoch)
----------------------------------------------------------------------------------------------------
Key: JBRULES-3103
URL:
https://issues.jboss.org/browse/JBRULES-3103
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-core, drools-core (fusion)
Affects Versions: 5.2.0.Final
Reporter: Richard Calmbach
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.4.0.Beta1
See JBRULES-3100 for the gory details. The implementation described there causes two
bugs, so THIS IS NOT A DUPLICATE of JBRULES-3100. Rather, the bugs are related, and
because it is possible to fix one without the other, it makes sense to track both bugs
explicitly, so that the developers can ensure that both bugs get fixed. The summary of
this issue also conveys to users that this particular bug has already been reported.
So, *this* bug prevents rules of the form
$a: A()
not(B(this after $a))
or "A and not(B after A)" in pseudocode, from firing when they should if the
session clock has a negative value, say during a simulation or if the system clock is
turned back pre Unix epoch. This is confirmed for the pseudo clock, and I believe the
real-time clock is equally affected. The root of the problem is that "A and not(B
after A)" type rules get a duration of Long.MAX_VALUE assigned. When that gets added
to a non-positive current time, it results in a very large positive number for the trigger
time, which will never be reached by the session clock, preventing the rule from ever
firing.
The fix is probably to add the activation for such a rule to the agenda immediately,
rather than schedule it for adding. This would yield the same behavior as when you compare
the timestamps explicitly. For now, comparing timestamps explicitly instead of using
"after" is a workaround for this bug.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: