[jboss-jira] [JBoss JIRA] (DROOLS-1098) Equals behaviour faulty when loading sessions after exception

[Artur Kronenberg (JIRA)]

    [ https://issues.jboss.org/browse/DROOLS-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187447#comment-13187447 ] 

Artur Kronenberg edited comment on DROOLS-1098 at 4/6/16 7:56 AM:
------------------------------------------------------------------

That makes sense, thanks. 
About must returning the same thing on a call to a method, can that be dynamic? 

For example, (I am going to use the model from the other bug) 


{code:java}
private LocalDateTime created = LocalDateTime.now();

public boolean isExpired(LocalDateTime toTest) {
				return created.isBefore(toTest);
}
{code}

And using a rule that provides toTest: 

{code:java}
rule "fact_expiry_automation"
    when
        $f : ExpirationFact( $time : time );
        $e : Expirable( evaluator.isExpired( $time ) == true);
    then
        log.info("Expiring fact: " + $e);
        retract($e);
end
{code}

(Update: created is set once, so the value of created is constant, while the value of toTest is "constant" with regards to the fact that inserts that value) 

This, in my head at least, returns the same value each time isExpired is called. This rule however triggers the same behaviour. (I know the comment about the session being dead still stands, just wanting to understand exactly what same result means).

Another follow up question: Does it matter, that identity fixes this problem while equality triggers the exception?  


was (Author: pandaadb):
That makes sense, thanks. 
About must returning the same thing on a call to a method, can that be dynamic? 

For example, (I am going to use the model from the other bug) 


{code:java}
public boolean isExpired(LocalDateTime toTest) {
				return LocalDateTime.now().isBefore(toTest);
}
{code}

And using a rule that provides toTest: 

{code:java}
rule "fact_expiry_automation"
    when
        $f : ExpirationFact( $time : time );
        $e : Expirable( evaluator.isExpired( $time ) == true);
    then
        log.info("Expiring fact: " + $e);
        retract($e);
end
{code}

This, in my head at least, returns the same value each time isExpired is called. This rule however triggers the same behaviour. (I know the comment about the session being dead still stands, just wanting to understand exactly what same result means).

Another follow up question: Does it matter, that identity fixes this problem while equality triggers the exception?  

> Equals behaviour faulty when loading sessions after exception
> -------------------------------------------------------------
>
>                 Key: DROOLS-1098
>                 URL: https://issues.jboss.org/browse/DROOLS-1098
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.3.0.Final
>         Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final
>            Reporter: Artur Kronenberg
>            Assignee: Mario Fusco
>         Attachments: test-standalone.zip
>
>
> This is in a series of debugging and I think a few issues boil down to this:
> https://issues.jboss.org/browse/DROOLS-1093
> https://issues.jboss.org/browse/DROOLS-1097
> This bug demonstrates how two identical sessions with identical input and rules produce a NPE when loading with equals behaviour vs identity behaviour. I am currently battling that issue and looking for a workaround. 
> Essentially, you can run the unit tests I attached in the test project: (ExceptionTest)
> testIdentity - passes 
> testIdentityWithReload - passes
> testEquals - NPE
> testEqualsWithReload- NPE
> The tests do the same thing: 
> * Create new persistent session 
> * Load facts into it
> * Run 20 times either reloading the session (depending on the test cases) or using the old session. Each run, insert one fact and run all the rules. Eventually the equals tests (I believe after iteration 2) NPE when trying to deserialise the session. Identity has no issues and functions correctly. 
> Let me know if you need anything else and please do let me know if there is a workaround. I am currently exploring the workaround avenue myself as well and will come back here with an update should I find one. 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)