AnsweredAssumed Answered

How to handle a race condition signaling an Execution

Question asked by blezek on Feb 17, 2017
Latest reply on Feb 23, 2017 by blezek



  We start long-running workflows that wait for a signal.  When certain events happen, we signal the workflow by searching for the list of Executions waiting on the signal (and some other criteria).  This can lead to race conditions because the incoming events can come in short order.  Here is example code:


    ExecutionQuery query = runtime.createExecutionQuery().processVariableValueEquals("Key", key).signalEventSubscriptionName(signalName);

    executions.forEach(ex -> {"Signaling workflow: " + ex.getId() + " with " + signalName);



        runtime.signalEventReceived(signalName, ex.getId(), signalVars);


The problem is that the long-running workflow performs a few checks right after the signal is received, then goes back to waiting on the signal (see image).  Because the above code can be called rapidly, between the query step and the signalEventReceived, the long-running workflow can go from waiting on the signal to being busy with other things.  I do synchronize in the Java code so that only one signal is sent at a time.  



We have tried a combination of "asynchronous" settings on the workflow after the intermediate signal catching event (the "Classify Series" and "Log Message", before it loops back to wait for the next signal).


If the events come slowly enough, the workflow returns to the signal catching event and all works well.


Question: How can I make sure the long-running workflow returns to waiting for the signal before the next signal needs to be sent?