cancel
Showing results for 
Search instead for 
Did you mean: 

What happens to processes after server restart (Critical) ?

sazzadul
Champ in-the-making
Champ in-the-making
Hi,
I have an issue with activiti which seems to be a showstopper. I have raised this issue earlier in this forum but didn't get any proper answer.
Here is the scenrio: I hava a processdef(long running) with several servicetasks and if the server gets restarted during the execution of say servicetask3
then activiti will never continue it again when the server starts up again. I have defined all the servicetasks as asyn which does not help.

There isn't any api funtion eithter which can be used to continue the servicetask.

I see that there is a row in table ACT_RU_EXECUTION for servicetask3 with status active.
35205   3   35205   NULL   NULL   MyProcess:2:35204   NULL   servicetask3   1   0   1

I will effectively have thousands of such processes and to loose these will be devastating.

I am attaching the screenshot of my processdef.

Any help will be greatly appreciated.
6 REPLIES 6

sazzadul
Champ in-the-making
Champ in-the-making
Please let me know if this isn't supported and do guide me of a workaround/solution to the problem.

This is very critical for us to fix and we would very much like to go in production as soon as this issue is solved.

I can also add a similiar method like runtimeservice.signal() for service task if you just tell me where in code to look for.

Thanks in advance.

heymjo
Champ on-the-rise
Champ on-the-rise
This is probably not something that activiti can cater for. If you need your application to be restart-proof you'll have to do this yourself. Adding shutdown hooks is one thing but they are not guaranteed to execute so you're pretty much in the same boat.

How was your application coping with this before you added activiti ?


EDIT and why can't you just do a manual update to the table to reset the status from active?

trademak
Star Contributor
Star Contributor
Hi,

When you implement these service tasks using async continuations, the process execution should definitely be restarted after a server restart.
The job executor retries 3 times and then sets the job in a failed state. So maybe that happens in your case.
Then you can restart a job manually via the Activiti Explorer or automatically using the Activiti API.

Best regards,

sazzadul
Champ in-the-making
Champ in-the-making
First and formost thank you for your reply.

We are using IBM websphere process server which has has this restart-proof capability.

EDIT and why can't you just do a manual update to the table to reset the status from active?
I can very well update the status but that itself will not trigger the execution of my JavaDelegate class and thus not update the hist tabell.

So I need to send a sinal so that activiti engine continues the flow from where it left as I do for the case of Receivetask.

Adding shutdown hooks is one thing
I am not sure what you are pointing at here. Could you please elaborate ?

Thanks again.

sazzadul
Champ in-the-making
Champ in-the-making
When you implement these service tasks using async continuations, the process execution should definitely be restarted after a server restart.

Best regards,
OK, now I see the problem, you are quite correct about the job executor. It indeed run but from an another instance ( I saw this exception:
org.activiti.engine.ActivitiException: couldn't instantiate class storebrand.crm.servicetask.ServiceTaskThreeDelegate)

We have several webapps with job executor sharing the same db. But I guess the job execution is universal. So I need to add some functionality around
to make it work as a whole.

Then you can restart a job manually via the Activiti Explorer or automatically using the Activiti API.
I found the function call ManagementService.executeJob(String jobId)

And thanks a lot for your reply.

heymjo
Champ on-the-rise
Champ on-the-rise
About the shutdown hooks: never mind. I thought it would be possible to add some task clean up stuff as a VM shutdown hook, but this IBM process server already seems way beyond that.