1 Reply Latest reply on Sep 18, 2011 3:09 PM by Geoff Pole

    StatefulKnowledgeSession signalEvent method

    Geoff Pole Newbie



      Can anyone help me to understand why the signalEvent method on the StatefulKnowledgeSession calls the ProcessInstancesWaitingForEvent query even when I provide the processInstanceId parameter?


      The ProcessInstancesWaitingForEvent seems to retrieve all workflow instances that are awaititing a particular event.


      I am seeing this behaviour in the context of this workflow:



      When I start the workflow with process variables that make it take the lower path the workflow begins and waits for the first signal.



      ProcessInstance process = session.startProcess("data-v0.0.2", processVariables);


      At this point I am able to signal the first event and the ProcessInstancesWaitingForEvent is NOT called. The workflow quickly moves and waits for the second signal.


      session.signalEvent("Signal1", null, process.getId());


      At this point I can signal the second event which does succeed but this time it appeas to be calling the ProcessInstancesWaitingForEvent query to find all workflows waiting for the signal2 event..


      session.signalEvent("Signal2", null, process.getId());


      The time that this takes is directly proportional to the number of workflow instances that I have waiting for the signal2 event.


      Can anyone help me to understand why ProcessInstancesWaitingForEvent is being called? It seems like this is unnecessary given that I am providing the processInsnanceId. Also I'm not sure why this happens when I signal event 2, but not when I signal event 1.


      The jbpm versions I have used are the ones bundled in the jbpm 5.10-Final installer download.


      Thanks very much,



        • 1. Re: StatefulKnowledgeSession signalEvent method
          Geoff Pole Newbie



          In case this helps others.


          I had this slightly backwards. It wasn't the second signal event call that was making the ProcessInstancesWaitingForEvent run. Instead this query appears to run every time a process enters an 'End' node. Presumably it does this so that it can find any workflows that may be listening for an End event.


          I don't know the reason why the ProcessInstancesWaitingForEvent runs so slowly (Oracle 11g) when there are many workflow instances that are waiting for events, but I did find that by applying this index reduced the running time from around 45 seconds to under 1 second with 20000 workflow instances.


          CREATE unique INDEX  idx_eventtypes_id_elem

             ON EventTypes (instanceid, element)


          I tested this up to 100000 workflow instances and the query still runs sub second.