Process instance resume not seeing the exection while in wait state

[badrisudheer]

Hi,

We have recently upgraded from Activiti (upgrade(5.15.1->5.18.0.1)). The application uses activiti as an embedded engine via Spring configuration. We are still using job executor and not async executor that has been introduced in recent versions. We have observed an issue for one of the workflows where we have an Asychronous processing where the process instance goes into a wait state with a Timer set. However, we have logic in place to Resume from the wait state if in case the Asynchronous process gets completed earlier than the set Timer duration. We resume the execution by signaling the execution id (we retrieve this by using a process instance id that we persisted in our application specific table) using Runtime interface. So, after the upgarde, it has been observed that, for some process instance executions,  we are unable to retrieve the execution by using the process instance id in hand which used to work great before the upgrade and even after the upgrade it works for few process instance executions. Please note that our application runs on 2 nodes that means each node would have the application with an embedded activiti engine running.

Also, another observation is, we used to see the process instances in Activiti tables when the execution is in Wait State but, after the upgrade, we are not seeing any entries in Runtime tables. So, the understanding is, the question is - may be Activiti engine is not saving the state into Activiti tables when a Wait State is reached ?

If the state is not committed to DB and then when we are trying to Resume the flow by querying for the process instance using the process instance id in hand my be its coming back as its not found ?

Any help would be greatly appreciated.

Thanks
Sudheer

[trademak]

Hi Sudheer,

If you observe that you don't see any entries in the runtime tables when reaching a wait state, then there's a problem. Of course we still store the process instance state when reaching a wait state, because that's fundamental to the Activiti Engine. Can you share some information about the process definitions you are using, or event better share a unit test that shows this issue?

Best regards,

[badrisudheer]

HI Tijs,

I am also leaning towards that there may be a problem with 5.19.0 version. We had to roll back our application to use 5.15.1 and It seems everything is back to normal and I do see the Runtime details now with 5.15.1 version in place. Essentially, we have an order level workflow which has callActivitity (multi) step that invokes another item level workflow for as many items come in the order request. The item level workflow has few sub processes in it's flow. Each sub process essentially submits a request to another enterprise service as part of a Service Task and goes into a Wait State with a Timer. As per our understanding, Activiti engine tries to execute a process instance with-in memory but, when a Wait state is reached with a Timer then, Activiti engine would persist the state into Activiti runtime tables (mainly, ACT_RU_EXECUTION with the ACT_ID_ details  and ACT_RU_JOB with a TYPE_ as timer). So, this table did not have any data when we used 5.19.0 and when we rolled back to 5.15.1, we do see the data. So, my thinking, as the data not there in these runtime tables when we were running on 5.19.0, the spring scheduler (this is something that we wrote to be able to signal using Runtime interface to resume the workflow if the enterprise service completes the request processing within the set Timeout duration on Timer) that tries to Query the process instance in-order to get to the Execution is unable to find the process instance. As I said, this has been working great on 5.15.1 but, not sure what needs to be done to make it work when we upgrade to 5.19.0. I have to see how to set up a unit test to reproduce this but, I hope that I explained what's going on.

Thanks again for your help in this regard
Sudheer

[jbarrez]

Not sure if I'm following … the explanation above is very specific. but hard to follow.
Do you happen to have a sample process definition (and unit test?) that clearly demonstrates this problem?

Between 5.15 and 5.19 there is more than one year, so a lot could have happened …