In case of multiple threads somehow invoke signalEvent() on same signal type to a given process instance, only one of the threads is supposed to the process to carry on.
How can I tell which one of the threads actually get the process instance continue executing the remaining tasks (I call this effective signalEvent)?
In jBPM API javadoc, signalEvent() has return type of void.
- Signals the process instance that an event has occurred. The type parameter defines which type of event and the event parameter can contain additional information related to the event. All node instances inside the given process instance that are listening to this type of (internal) event will be notified. Note that the event will only be processed inside the given process instance. All other process instances waiting for this type of event will not be notified.
type- the type of event
event- the data associated with this event
processInstanceId- the id of the process instance that should be signaled
So I am unable to tell if a signalEvent() is effective or not from the return value.
Currently I check the nodeId returned from process instance before calling signalEvent().
If the nodeId equals to the name given to the intermediate catch signal node, I treat it as the first thread signaling the process instance and invoke signalEvent() --> effective.
Otherwise, I skip signalEvent() and return some error code to indicate the process instance has been signaled already --> not effective.
However this doesn't seem to be the right way of doing it and it doesn't work perfectly either.
I use JMeter to send concurrent requests to signal the process instance. There should be only one successful response, but I get multiple successful responses.
My process has three intermediate catch signal events:
My test case is provided as follows and I do signalEvent() in different runs:
For "WaitAuthenticate", I get multiple success responses:
For "WaitAuthorize" and "WaitDeduct", I get only one success response as expected: