[jboss-jira] [JBoss JIRA] (JBRULES-3103) "A and not(B after A)" type rules don't fire when session clock has negative values (pre Unix epoch)

[Edson Tirelli (Resolved) (JIRA)]

     [ https://issues.jboss.org/browse/JBRULES-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli resolved JBRULES-3103.
------------------------------------

    Resolution: Done


Fixed. Thank you for reporting and the extensive analysis.
                
> "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.Beta2
>
>
> 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira