ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexis Midon (JIRA)" <j...@apache.org>
Subject [jira] Commented: (ODE-436) NPE in test:axis2-war when using Hibernate
Date Wed, 26 Nov 2008 01:36:44 GMT

    [ https://issues.apache.org/jira/browse/ODE-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650834#action_12650834
] 

Alexis Midon commented on ODE-436:
----------------------------------


In ODE the message exchange id (mex id) is a string used as the unique id of a the MessageExchangeDao.
Depending on the DAO implementation this information might be persisted in database.

In ODE 1.X, for the Hibernate implementation, the mex id is actually a long converted into
a string in org...daohib...MessageExchangeDaoImpl#getMessageExchangeId. This id is also the
primary key of the underlying table BPEL_MESSAGE_EXCHANGE and is generated by the database.


But in ODE trunk, the mex id is now generated by the caller of BpelDAOConnection#createMessageExchange
and is a 128-bit Global Unique Identifier, which is not convertible into a long. So, in trunk,
BPEL_MESSAGE_EXCHANGE has an additional column MEXID (string) to save the guid.

The NPE reported here is due to a bug in org.apache.ode.daohib.bpel.MessageExchangeDaoImpl#getMessageExchangeId.
Actually the current implementation still returns the database id (the long) instead of the
mex id (the guid). Actually the MessageExchange is cached by org.apache.ode.bpel.engine.MyRoleMessageExchangeCache
base on the mex id. 
When the reference is put into the cache, the mex id come from the freshly created MyRoleMessageExchangeImpl
instance with the proper GUID. When the reply is received the org.apache.ode.daohib.bpel.MessageExchangeDaoImpl
(the buggy one) is loaded from the database based on the GUID. And the look up call from the
cache uses a wrong id and cannot retrieved the MyRoleMessageExchangeImpl instance with the
waiting future. In that case the cache creates and returns a new instance with null futur.
Hence the NPE.

This issue does not happen with JPA because the mex id (the guid) is also the primary key.


To use the trunk  on an existing 1.x hibernate database, a migration script would have to
be ran previously to populate BPEL_MESSAGE_EXCHANGE.MEXID with BPEL_MESSAGE_EXCHANGE.ID.



> NPE in test:axis2-war when using Hibernate
> ------------------------------------------
>
>                 Key: ODE-436
>                 URL: https://issues.apache.org/jira/browse/ODE-436
>             Project: ODE
>          Issue Type: Bug
>    Affects Versions: 1.3
>            Reporter: Alexis Midon
>            Assignee: Alexis Midon
>             Fix For: 1.3
>
>         Attachments: 0001-make-sure-we-use-the-mex_id-instead-of-the-database.patch
>
>
> In trunk, when using Hibernate, ServiceFaultCatchTest and EndpointConfigurationTest (not
an exhaustive list) fail with the exception below.
> To reproduce execute this command:
> env JAVA_OPTS='-Dode.persistence=hibernate'  buildr ode:axis2-war:test:ServiceFaultCatchTest
> FATAL - GeronimoLog.fatal(120) | Internal Error
> java.lang.NullPointerException
> 	at org.apache.ode.bpel.engine.UnreliableMyRoleMessageExchangeImpl$2.run(UnreliableMyRoleMessageExchangeImpl.java:148)
> 	at org.apache.ode.bpel.engine.ODEProcess$ProcessRunnable.run(ODEProcess.java:1122)
> 	at org.apache.ode.bpel.engine.BpelServerImpl$ServerRunnable.run(BpelServerImpl.java:923)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
> 	at java.lang.Thread.run(Thread.java:595)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message