3 Replies Latest reply on Jun 17, 2011 10:14 AM by byungwoojun

    A bug? Ksession.signalEvent and ProcessInstanceWaitingForEvent

    byungwoojun Newbie

      For the external intermediate event, the jBPM 5 user guide suggested using ksession.signalEvent(event, eventData) - BTW, got the ksession from JPAKnowledgeService. Then, the jBPM 5 will automatically finds a correct process instance to feed the eventData. During some tests, I found that the signalEvent using the ProcessInstanceWaitingForEvent NamedQuery does NOT work well. For example, I have a process flow with intermediate events. I quickly run the process flow multiple times. Then, there will be multiple entries in the EventTypes database. What the query does, it joins the EventTypes and the ProcessInstanceInfo database tables, returns a list of process ids with the same event name. If I ran the process flow three times, the query will return three pids. Which one to use? Normally, it uses the first one. In many cases, the signalEvent ends up using a wrong pid which does not belong. I experienced many problems here. The behaviors were NOT reliable.

       

      To me, it is a bug to me.

       

      If I use the ksession.signalEvent(event, eventData, pid) with the pid (which is different from the pid from the startProcess), it works reliably. The problem is how to find a proper pid for intermediate message event messaging.

       

      I looked at the EvenTypes database table. It has InstanceID and Element columns. Some of the element field data is as follows:

       

      InstanceID              Element

      -----------------------------------------------------------------------------------

      1356                       processInstanceCompleted:1357

      1357                       eventType1

       

      As you can see, the 1356 row points the 1357 row. In my opinion, the proper way to find a correct pid is drilling down the chain from the top-level pid which is getten from the startProcess. Instead of embedding the next pid part of the text data in the Element field, if we have the third column to point the next pid, we could use SQL chain query. Using the current schema, I need to get the 356 instance id, parse the element text (after the colon), then, get the row 1357 instanceid, so on....

       

      I looked at the 5.1.0.M1 code, but there is no change. So, is it a bug? Or, did I miss something here?

       

      bwj

        • 1. Re: A bug? Ksession.signalEvent and ProcessInstanceWaitingForEvent
          byungwoojun Newbie

          To me, that the name query ProcessInstanceWaitingForEvent used by the ksession.signalEvent does NOT return with the correct process/subprocess instance which has the intermediate event type when there are some left-over data entries in the EventType database table due to:

           

          - multiple process instances for the same process defintion are running (i.e., there are more data entries in the EventType database table). Of course, the process instances have the same event type name.

          - previous sessions failed and didn't clean up data entries from the EventType database table.

           

          There could be several ways to solve this. At this time, my team didn't want to add additional column to the database table, we solved the issues as follows:

           

          1. When we start the process, we store a unique correlation id, a session id and a process instance id (it will be the top-level process instance id) in a database table (e.g., correlation id, session id, process instance id).

           

          2. When an intermediate message arrives, we restore the session using the incomig correlation id from the database table. Using this table, we also find the top-level process instance id.

           

          3. Using this process id, we query the EventType database table to find the process or sub-process which has the proper event type. The EventTypes database table has two columns: instance id and element.

           

          e.g.,

          InstanceID              Element

          -----------------------------------------------------------------------------------

          1356                       processInstanceCompleted:1357

          1357                       eventType1

           

          As you can see, the 1356 row points the 1357 row. In my opinion, the proper way to find a correct pid is drilling down the chain from the top-level pid which is getten from the startProcess. Instead of embedding the next pid part of the text data in the Element field, if we have the third column to point the next pid, we could use SQL chain query. Using the current schema, I need to get the 356 instance id, parse the element text (after the colon), then, get the row 1357 instanceid, so on....

           

          Since we don't want to add additional column at this time, we created a function with two parameters: eventType, topLevelProcessInstanceId:

           

          - the function queries the EventType database table using the topLevelProcessInstanceId.

          - it parses the element column.

               - If the element contains the same eventType, it returns the processInstanceId.

               - Otherwise, it gets a sub-string after ":" (e.g., 1357). Use this sub-string (need to convert it to long) as a parameter along with the eventType (unchanged), and call the same function recursively until the element is equal to the event type. 

           

          4. After the function, we call ksession.signalEvent(eventType, eventData, foundProcessInstanceId);

           

          As you noticed, this method may end up querying multiple times depending on the depth of sub-processes. There could be some performance penalties. But, it works reliably regardless the EventTypes database table entries.

           

          If jBPM engine itself supports the correlation out-of-the-box, it would be great. But for now, we need to code for the correlation support.

           

          Any suggestions would be appreciated.

           

          bwj

          • 2. Re: A bug? Ksession.signalEvent and ProcessInstanceWaitingForEvent
            Esteban Aliverti Master

            This really seems to be a bug. It would be great if you could file a bug report: https://issues.jboss.org/browse/JBPM  Best Regards,

            • 3. Re: A bug? Ksession.signalEvent and ProcessInstanceWaitingForEvent
              byungwoojun Newbie

              I filed a bug report, jBPM-3240, for this.

               

              Thanks,

              bwj