[jboss-jira] [JBoss JIRA] (DROOLS-1030) Nullpointer in JpaTimerJobInstance.call on startup

[Artur Kronenberg (JIRA)]

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

Artur Kronenberg edited comment on DROOLS-1030 at 1/21/16 9:58 AM:
-------------------------------------------------------------------

This just happened again to me. I think this exception is related: http://pastebin.com/uStYMNg5 

I also managed to confirm that:
 * Breakpoint in JpaTimerJobInstance line 48 (before the getCommandService() call) does fix the issue. There seems to be a race as to when the CommandServiceTimerJobFactoryManager is available. 

 * Once the breakpoint is set and run through, the session "fixes itself", meaning that on a subsequent recreation the timertask is no longer run when creating the session. I seem to not understand when the timerJob is running and what for. But it appears that a session can be stored so that no timer-jobs have to be run. Is that correct? 


This just happened, it appears to be related so I'm attaching it for completeness: http://pastebin.com/MzjMdjm6


was (Author: pandaadb):
This just happened again to me. I think this exception is related: http://pastebin.com/uStYMNg5 

I also managed to confirm that:
 * Breakpoint in JpaTimerJobInstance line 48 (before the getCommandService() call) does fix the issue. There seems to be a race as to when the CommandServiceTimerJobFactoryManager is available. 

 * Once the breakpoint is set and run through, the session "fixes itself", meaning that on a subsequent recreation the timertask is no longer run when creating the session. I seem to not understand when the timerJob is running and what for. But it appears that a session can be stored so that no timer-jobs have to be run. Is that correct? 

> Nullpointer in JpaTimerJobInstance.call on startup 
> ---------------------------------------------------
>
>                 Key: DROOLS-1030
>                 URL: https://issues.jboss.org/browse/DROOLS-1030
>             Project: Drools
>          Issue Type: Feature Request
>          Components: core engine
>         Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final
>            Reporter: Artur Kronenberg
>            Assignee: Mario Fusco
>
> Hi,
> I have noticed Nullpointer exceptions when I try and reload a persisted session on startup. It is a bit hard to recreate (I am actually not managing it now since I deleted all old sessions to attempt recreation) but I figured maybe someone has an idea. Essentially I am getting this NPE twice:
> java.lang.NullPointerException: null
>         at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:50) [drools-persistence-jpa-6.3.0.Final.jar:6.3.0.Final]
>         at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:30) [drools-persistence-jpa-6.3.0.Final.jar:6.3.0.Final]
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_51]
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_51]
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.8.0_51]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_51]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_51]
>         at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
> When debugging I noticed the following behaviour which points to a race condition: 
> If I start my server and try to recreate the session, those NPEs happen 2x.
> If I start my server and put a breakpoint BEFORE creating the CommandService for execution, I can wait for a few seconds and the service can be found.
> It appears that the scheduler's timerJobFactoryManager is not fully there at the time the sessions is being loaded? Or something else is racing with the service creation. 
> Is there a way for me to make sure everything is fully instantiated before I use drools? Does a workaround exist? Is this even a bug? 
> Thanks and let me know your thoughts. If I run into this again I will attempt to try and reproduce it. Let me know if more info is needed!
> UPDATE:
> I noticed that the reason I can't reproduce it at the moment is that the JpaTimerJobInstance is never called with the newly persisted session. It appears that that timer job depends on something else to happen so that it thinks it needs to start the timerJob 



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