[
https://issues.apache.org/jira/browse/ODE-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12926408#action_12926408
]
Kurt Westerfeld commented on ODE-894:
-------------------------------------
Tammo, we cannot use the hibernate back-end even though we'd really like to.
What we're seeing is that there are all sorts of character truncation issues
with various INSERT statements, past some 255 character limits that we do not
see with the JPA back-end.
Another point I'd make is that the cascade operations that the MEX DAO Impl for
JPA to persist it's reply/receive messages works for nearly 100% of the time,
and the rows end up in the database. In this case, the row hasn't made it
there yet, or is never going to make it for some reason. I did trace this a
few weeks ago and I saw the message DAO impl make it onto the setter of the mex
dao impl, but when another thread retrieved the mex dao impl it was not there
(again, not sure if it's about to be there or not).
Forcing the issue with an getEM().persist() seems safe and orthogonal to the
current setup--it's a oneliner that I think can't do any harm and does fix our
issue.
I'll work on a testcase if I find some cycles.
Thanks,
Kurt
> 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.
