1 Reply Latest reply on Jan 31, 2012 8:51 AM by mscetin

    java.io.EOFException while upgrading to jBPM 5.2

    mscetin
    mscetin Jan 23, 2012 6:38 AM

      We are in the process of upgrading to jBPM 5.2 (from 5.1). As I could not find any explicit notice about the upgrade process in 5.2 documentation, I assumed version 5.2 is backwards compatible with version 5.1.

       

      Apperantly, there are some incompatibilities. We got java.io.EOFException error while unmarshalling the existing jBPM 5.1 process timers (see the stack dump below).

       

      Caused by: java.io.EOFException
          at java.io.DataInputStream.readShort(DataInputStream.java:315)
          at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2769)
          at java.io.ObjectInputStream.readShort(ObjectInputStream.java:946)
          at org.jbpm.marshalling.impl.ProcessMarshallerImpl.readProcessTimers(ProcessMarshallerImpl.java:204)
          at org.drools.marshalling.impl.InputMarshaller.readSession(InputMarshaller.java:310)
          at org.drools.marshalling.impl.InputMarshaller.readSession(InputMarshaller.java:196)
          at org.drools.marshalling.impl.DefaultMarshaller.unmarshall(DefaultMarshaller.java:93)
          at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:91)
          ... 67 more

       

      When I compare 5.1 and 5.2 versions of org.jbpm.marshalling.impl.ProcessMarshallerImpl class, among other changes I see that implementation of readProcessTimers and writeProcessTimers are different. Is there any script or utility available to upgrade existing 5.1 timers (and/or any other process instance data) to 5.2 format?

       

      P.S. IMHO, persisting session or process instance data in binary format has to be re-evaluated as it creates lots of difficulties while investigating operational issues. If it was done for flexibility then a human readable format (e.g. json or xml) would be a better choice.

        • 1. Re: java.io.EOFException while upgrading to jBPM 5.2
          mscetin
          mscetin Jan 31, 2012 8:51 AM (in response to mscetin)

          I have solved this problem by writing a small application and I will briefly explain it in case other people find it useful. As I am not 100% sure about the completeness of my workaround (it worked for me but every Business Process has its own peculiarities), I am not posting the code as a generic solution.

           

          In my workaround I modified few jBPM and Drools sources to upgrade my existing SessionInfo and ProcessInstanceInfo records. In this small application, I read the existing session and process instances using jBPM 5.1 code and forced writing them using jBPM 5.2 code. The list of modified sources are:

           

          • org.drools.marshalling.impl.InputMarshaller
          • org.drools.marshalling.impl.MarshallerReaderContext
          • org.drools.marshalling.impl.MarshallerWriteContext
          • org.drools.reteoo.BetaMemory
          • org.jbpm.marshalling.impl.ProcessMarshallerImpl
          • org.jbpm.persistence.processinstance.JPAProcessInstanceManager

           

          Additionally, I populated two new columns (processSessionId and processId) added to Task table with jBPM version 5.2.

            • Actions