"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: Mark Proctor
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.
For more information on JIRA, see:
http://www.atlassian.com/software/jira