ODE
  1. ODE
  2. ODE-436

NPE in test:axis2-war when using Hibernate

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3.2
    • Fix Version/s: 1.3.2
    • Component/s: None
    • Labels:
      None

      Description

      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)

        Issue Links

          Activity

          Hide
          Alexis Midon added a comment -

          This issue is not reproducible in ODE 1.X branch.

          Show
          Alexis Midon added a comment - This issue is not reproducible in ODE 1.X branch.
          Hide
          Alexis Midon added a comment -

          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.

          Show
          Alexis Midon added a comment - 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.
          Hide
          Alexis Midon added a comment -

          trunk r720709

          Show
          Alexis Midon added a comment - trunk r720709
          Hide
          Alexis Midon added a comment -

          on the road to 1.3.1

          Show
          Alexis Midon added a comment - on the road to 1.3.1

            People

            • Assignee:
              Alexis Midon
              Reporter:
              Alexis Midon
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development