[jboss-jira] [JBoss JIRA] (DROOLS-1030) Nullpointer in JpaTimerJobInstance.call on startup
[
https://issues.jboss.org/browse/DROOLS-1030?page=com.atlassian.jira.plugi...
]
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)