I have a situation where I need to resume process execution after restart of jBPM (restart of JBoss). I'm working with work item handlers and I want to have possibility to resume of execution of asynchronous work item handlers. Everything is working fine for my implementation if jBPM is running but problem is if I restarted jBPM (JBoss).
I implemented "go to shutdown" functionality which works in this way: if "go to shutdown" global attribute of system is set, then at the begining of method executeWorkItem return is called and work item is not executed at all. This means no work item is executed if this attribute is set in my system. Also no new process can't be created or started. After while all process are in wait state and state of processes is persisted.
After this JBoss is restarted.
Then I'll turn off "go to shut down" atttribute and call my resumeProcesses functionality. This functionality will takes all not finished work items from WorkItemInfo table and call executeWorkItem for every work item. This will cause that body of work item'll be executed and if success method completeWorkItem will be executed. This works if JBoss is not restarted but if JBoss is restarted, workitem is completed but process doesn't continue with execution of next node.
I'm confused because this is working if Jboss is not restarted so this means that process is not persisted "correcly". I found where is the problem. After JBoss is restarted every processInstace which is going to use have to be read from persisted state - see AbstractProcessInstanceMarshaller.readProcessInstance. In this method reconect method is called where correct listeners are added for all node instances, but I'm confused that there is a previous node used, not node of my last work item. This will cause that there are added only listeners for my previous work item which was already succesfully completed. This is difference if Jboss is not restarted because process instance is not loaded from persistent state and is used from session and there is corrrect node.
Is this how process persistence should work or is this some bug or I'm missing something about this. Thank you for any advice.
Another plan is to modify process somehow in runtime and add event to wait for signal to achieve this resume functionlity but i think this is not a good idea.
Added info: This is only issue about work item handlers. If you have signal event in your process (common BPMN 2 wait state) everything works fine also after JBoss restart - if process waits for signal before restart then after restart you can continue process with no problem by signaling event for this process.
Message was edited by: Rudi Fisher