3 Replies Latest reply on Mar 20, 2015 10:19 AM by rocky13

    jBPM 5.4, Persistence, and Safe-Points

    franco.gasperino

      Community,

       

      Excuse the long-winded post. I'm trying to debug an issue with an integration project with the following components:

       

      • jBPM 5.4 final, Drools 5.5 final
      • Spring 3.2.x
      • Bitronix 2.1.x

       

      The core jBPM engine is heavily integrated with a custom stack allowing process instances to be created and run via all sorts of connectivity. The custom layer will take the process id & input parameters, delegate to a thread in an executor, which will:

       

      1. Instantiate the drools environment (with JTA support).
      2. Create the knowledge session.
      3. Create a custom WorkItemHandler, associate each custom service task with this handler.
      4. Create and associate the event handlers.
      5. Create and start the process instance.

       

      Everything executes as-expected, the JTA is performing commits and I can see the Hibernate activity inserting, updating, and deleting records from the Derby XA database.

       

      However, when testing a process instance which *should* trigger a safe-point, i see unexpected behavior. In this case:

       

      • Script "Hello" is a java/groovy/whatever script task.
      • ServiceTask "MockAsyncTask" is a java class, which is associated / registered with the custom WorkItemHandler.
        • executeWorkItem() does NOT call completeWorkItem()
        • Returns control to the jBPM engine, which should trigger a safe-point.
        • Causes return of startProcessInstance(), which will exit the worker thread in the executor.
      • Script "Bye" is a java/groovy/whatever script task.

       

      The workflow: Start -> Hello -> MockAsyncTask -> Bye -> End

       

      As expected, I see the behavior. I see that the ProcessInstance object associated has a state field of "2", which is active. Howevever, the hibernate update statements on the ProcessInstanceInfo table always have a state value of '0'. This is the breaking behavior.

       

      When I attempt to call the adapter layer with the session id, process instance id, work item id, and a payload:

       

      1. Instantiate the drools environment (JTA support).
      2. Load the existing knowledge session.
      3. Create a custom WorkItemHandler, associate each custom service task with this handler.
      4. Create and associate event handlers.
      5. Call completeWorkItem().

       

      The workItem does complete, and i see it deleted from the WorkItemInfo table. However, since the process instance state has been reloaded with a value of '0', the "Bye" script task is never fired.

       

      Any ideas? A full code dump would be huge, but I'm happy to inject some loggers if it would assist troubleshooting.

       

      Thanks!

       

      Franco

        • 1. Re: jBPM 5.4, Persistence, and Safe-Points
          franco.gasperino

          Any high-level thoughts from the community experts? The hibernate logs always appear as such:

          Hibernate:

              update

                  ProcessInstanceInfo

              set

                  id=?,

                  lastModificationDate=?,

                  lastReadDate=?,

                  processId=?,

                  processInstanceByteArray=?,

                  startDate=?,

                  state=?,

                  OPTLOCK=?

              where

                  InstanceId=?

                  and OPTLOCK=?

          2013-07-01 12:01:07.0968 TRACE pool-2-thread-1 org.hibernate.type.descriptor.sql.BasicBinder - binding parameter [1] as [BIGINT] - 1

          2013-07-01 12:01:07.0968 TRACE pool-2-thread-1 org.hibernate.type.descriptor.sql.BasicBinder - binding parameter [2] as [TIMESTAMP] - Mon Jul 01 12:01:07 PDT 2013

          2013-07-01 12:01:07.0969 TRACE pool-2-thread-1 org.hibernate.type.descriptor.sql.BasicBinder - binding parameter [3] as [TIMESTAMP] - Mon Jul 01 12:01:07 PDT 2013

          2013-07-01 12:01:07.0969 TRACE pool-2-thread-1 org.hibernate.type.descriptor.sql.BasicBinder - binding parameter [4] as [VARCHAR] - com.sample.tests.async.1

          2013-07-01 12:01:07.0969 TRACE pool-2-thread-1 org.hibernate.type.descriptor.sql.BasicBinder - binding parameter [5] as [BLOB] - [B@3c76ced6

          2013-07-01 12:01:07.0970 TRACE pool-2-thread-1 org.hibernate.type.descriptor.sql.BasicBinder - binding parameter [6] as [TIMESTAMP] - Mon Jul 01 12:01:07 PDT 2013

          2013-07-01 12:01:07.0970 TRACE pool-2-thread-1 org.hibernate.type.descriptor.sql.BasicBinder - binding parameter [7] as [INTEGER] - 0

          2013-07-01 12:01:07.0970 TRACE pool-2-thread-1 org.hibernate.type.descriptor.sql.BasicBinder - binding parameter [8] as [INTEGER] - 2

          2013-07-01 12:01:07.0970 TRACE pool-2-thread-1 org.hibernate.type.descriptor.sql.BasicBinder - binding parameter [9] as [BIGINT] - 1

          2013-07-01 12:01:07.0970 TRACE pool-2-thread-1 org.hibernate.type.descriptor.sql.BasicBinder - binding parameter [10] as [INTEGER] - 1

           

          I would think that parameter 7 would eventually move to a non-zero state on the safe point to indicate that the process instance is active.

           

          -- EDIT -- :

           

          Adding a breakpoint during the ProcessEventListener.afterProcessStarted() implementation associated, i see the kruntime associated with the process instance is:

          WorkflowProcessInstance1 [processId=com.sample.tests.async.1,state=1]

          So the working memory representation of the process instance has the correct state, but the persisted representation does not (STATE_PENDING=0, STATE_ACTIVE=1).

           

           

          TIA,

           

          Franco

          • 2. Re: jBPM 5.4, Persistence, and Safe-Points
            franco.gasperino

            Replying to myself...

             

            It appears this is an issue with the Hibernate, JTA (Bitronix), and Spring. When the configuration is Hibernate, Spring Transactions (sans JTA), and Spring, the process instance state is updated to ACTIVE. Will research more for other community members.

             

            Franco

            • 3. Re: jBPM 5.4, Persistence, and Safe-Points
              rocky13

              Did you get any solution to this? i am facing exactly the same issue