[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=13151941#comment-13151941 ] 

Artur Kronenberg commented on DROOLS-1030:
------------------------------------------

Hi,

Some more experimentation and our chat pointed me towards a new direction and I believe this is how this is reproducible (worked 3 out of 3 times for me):

1. Setup persistence and a rule with expiry. My expiry is 5 minutes. 
2. Start Drools and execute first rule with one insert

( In my case the first rule internally adds X facts (event arrive, add facts). The event triggering that is set to expire after 5 mionutes). 

3. Drools now has persisted the new facts (all inserted facts expire after 24 hours). 
4. Shut down the engine. 
5. Wait for 5 minutes (or a bit more).
6. Restart the engine. 
7. Load the session, insert a new fact (event), run all rules - BOOM. http://pastebin.com/GxWs1JyF

I am not sure why it's 4 NPEs.

More info:

Went back and set a breakpoint. I wait for the logs to pass (i can tell by my logs when the session creation is absolutely done). Then let is rip -> No more exceptions. 

I will attempt to create a standalone example for this. 


> 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)