AnsweredAssumed Answered

Possible bug in eventing - Activiti not ready to receive signal even after dispatching ACTIVITY_STARTED for signal catch node

Question asked by michalwrobel on Apr 8, 2014
Latest reply on May 12, 2014 by michalwrobel
I've been experimenting recently with events in Activiti 5.15.
I developed a process which has some tasks and intermediate signal catching events
and a client app which sends these signals after receiving ACTIVITY_STARTED event for appropriate signal catching node.

The problem is Activti doesn't always seem ready to receive the signal in the moment when ACTIVITI_STARTED event has been already dispatched.

Important notes :
- I haven't been able to reproduce this bug using activiti embedded in unit test on a simple process
- Activiti engine works inside webapp (the standard activiti REST war), which I extended to publish events using websockets. The client sends signals using REST API (POST runtime/signals)

Here's the diagram of the part of process relevant to this post :

And some simplified pseudocode of what happens in client app :

processInstanceId = createAndStartProcessInstance();  // performs all steps leading to op1-finished signal catching node
waitForEvent("op1-finished", "ACTIVITY_STARTED");   // it will only continue ONLY IF ACTIVITY_STARTED for op1-finished catching node is received, so node should be ready to receive signal   
//  sleep(300);   //when i uncomment this it ALWAYS work
signalOperation1Finished(); // this always succeeds but whithout sleep the signal isnt always received properly

checkIfProcessFinished(processInstanceId);  // fails often without 'sleep' because signal is sent 'too early'(?) and process hangs at waiting for signal

Interesting thing is that without 'sleep' signal fails to be delivered almost always just after starting webapp server and then after some repetitions of client test tends to succeed often, just like activiti engine underneath needs some kind of 'warmup' before it can perform in time.

The ACTIVITY_STARTED event is the last event sent by engine before process stops on event catching node so I have to send signal after receiving it, isn't it?
Quote from the documentation caught my eye "ACTIVITY_STARTED   An activity is starting to execute"
IS STARTING, not 'have been started' or something like that so… is it a bug? Or is some later event still lacking in the API?
When I can be sure the process node is ready to catch signal?
Obviously I cannot use 'sleeps' in production code..

- Have I found lacking feature or a bug? Is really engine not exactly ready to process signal in the exact moment of dispatching 'ACTIVITY_STARTED' event?