[
https://issues.apache.org/jira/browse/ODE-894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kurt Westerfeld closed ODE-894.
-------------------------------
Resolution: Cannot Reproduce
I reworked my process and did the following:
1. Calling processes are no longer persistent (ie. declare
<in-memory>false</in-memory>)
2. Added:
<!-- Turn off generation of events which cause DB activity we don't
need -->
<process-events generate="none"/>
<!-- Cleanup everything, all the time when a process completes -->
<cleanup on="always" />
And the problem has gone away. I'm not 100% sure why, but I the issue is
blocking me any longer and doesn't seem to have a valid testcase I can provide.
> BPEL with <pick> followed by <invoke> fails with NPE when using JPA
> persistence
> -------------------------------------------------------------------------------
>
> Key: ODE-894
> URL: https://issues.apache.org/jira/browse/ODE-894
> Project: ODE
> Issue Type: Bug
> Components: BPEL Runtime
> Affects Versions: 1.3.4
> Environment: JBI distribution on servicemix 3.3.2
> Reporter: Kurt Westerfeld
>
> We have a bpel process which contains a <pick> followed by a few <assign> and
> an <invoke> operation. When running this process, we can resume the <pick>
> but soon afterwards an NPE occurs as in the following stack trace:
> 13:04:04,013 | ERROR | pool-5-thread-1 | SimpleScheduler |
> .simple.SimpleScheduler$RunJob 545 | Error while processing a persisted job:
> Job hqejbhcnphr5nd9dfp0pnt time: 2010-10-05 13:04:00 EDT transacted: true
> persisted: true details: JobDetails( instanceId: null mexId:
> hqejbhcnphr5nd9dfp0pns processId: {(endpoint-name-removed)-0 type:
> INVOKE_INTERNAL channel: null correlatorId: null correlationKeySet: null
> retryCount: null inMem: false detailsExt: {})
> org.apache.ode.bpel.iapi.Scheduler$JobProcessorException:
> java.lang.NullPointerException
> at
> org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:478)
> at
> org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerImpl.java:450)
> at
> org.apache.ode.scheduler.simple.SimpleScheduler$RunJob$1.call(SimpleScheduler.java:518)
> at
> org.apache.ode.scheduler.simple.SimpleScheduler$RunJob$1.call(SimpleScheduler.java:513)
> at
> org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:284)
> at
> org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:239)
> at
> org.apache.ode.scheduler.simple.SimpleScheduler$RunJob.call(SimpleScheduler.java:512)
> at
> org.apache.ode.scheduler.simple.SimpleScheduler$RunJob.call(SimpleScheduler.java:496)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NullPointerException
> at
> org.apache.ode.bpel.engine.MessageImpl.getMessage(MessageImpl.java:104)
> at
> org.apache.ode.bpel.engine.PartnerLinkMyRoleImpl.computeCorrelationKeys(PartnerLinkMyRoleImpl.java:294)
> at
> org.apache.ode.bpel.engine.PartnerLinkMyRoleImpl.findRoute(PartnerLinkMyRoleImpl.java:122)
> at
> org.apache.ode.bpel.engine.BpelProcess.invokeProcess(BpelProcess.java:233)
> at
> org.apache.ode.bpel.engine.BpelProcess.invokeProcess(BpelProcess.java:279)
> at
> org.apache.ode.bpel.engine.BpelProcess.handleJobDetails(BpelProcess.java:426)
> at
> org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:460)
> ... 12 more
> This problem then continues for a while, while the scheduling and refiring of
> this job continues.
> In diagnosing the problem, it was seen that the dao-jpa persistence has an
> issue in that the MessageDAOImpl class is never persisted with the MEX that
> created it. The NPE occurs when the internal <pick> resumes on a message
> exchange that is later scheduled, hydrated from persistence but the MEX does
> not contain the "receive" message.
> Specifically, the class org.apache.ode.dao.jpa.MessageExchangeDAOImpl is not
> doing is not doing a getEM().persist() on the MessageDAOImpl, and there is no
> cascading one-to-many setup to cause the MessageDAOImpl to be persisted. The
> hibernate dao does persist the message in this case, and testing with the
> hibernate back-end caused the issue to go away. However, we are experiencing
> other "primary constraint" violations with the hibernate back-end, so we want
> to use the JPA back-end.
> Here is a minimal patch which we tested which fixes the issue:
> Index:
> dao-jpa/src/main/java/org/apache/ode/dao/jpa/MessageExchangeDAOImpl.java
> ===================================================================
> ---
> dao-jpa/src/main/java/org/apache/ode/dao/jpa/MessageExchangeDAOImpl.java
> (revision 997965)
> +++
> dao-jpa/src/main/java/org/apache/ode/dao/jpa/MessageExchangeDAOImpl.java
> (working copy)
> @@ -128,6 +128,7 @@
> public MessageDAO createMessage(QName type) {
> MessageDAOImpl ret = new MessageDAOImpl(type,this);
> + getEM().persist(ret);
> return ret ;
> }
> We do not know whether this patch is the right way to fix this, but it does
> seem to be similar to the hibernate back-end. One issue with this minimal
> change is potentially not having the MessageDAOImpl cleanup in place--not
> sure how best to approach that.
> Another approach considered could be to harden the
> PartnerLinkMyRoleImpl.computeCorrelationKeys method to ensure it doesn't get
> an NPE when this message component is missing. Not sure which way is best.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
