How to detect crashed process instance in jbpm 4.1 ?

[muellere]

We are using JBPM 4.1 and need to implement some kind of recovery logic to cope with the problem of crashed process instances.

The application is a server application resposible to execute various workflows. We are using the persistence layer which assures that process states are saved to the database.

In case the application crashes, e.g. because of a hardware failure we need to restart the application and resume the various activities which have been in progress when the application crashed.

Since there is no automatism available, a process instance of a workflow  will recover in its last saved state and will not continue until I trigger an appropriate transistion.

So far so good. My problem is no the following:

I need to find the crashed activities of process instances.

My current idea is:

• check all process instances which are not suspended or ended
• check whether type of last activity is state or task
• if this is not the case check whether activity is currently locked by another jbpm instance

But how to do this. Will the method "isActive" work also in case the activity was locked before by the jbpm instance which crashed ? How is the optimistic locking implemented ? Does this work similar to "selectForUpdate" in the database and disappears when the instance has crashed ?

Hopefully anyone can help,

Elisabeth

[marco.rietveld]

What I've seen done with jbpm 3 (which jBPM 4 resembles), is that a webservice was built over the jBPM engine api. You can use the jBPM engine api to figure out what the status is of different process instances (your suggestsion touch on some of them).

If you need help with the engine API, let me know. I'm pretty sure I know which methods you could use.

Marco

[muellere]

Hi Marco,

thanks for your answer ,but the problem is a  little bit different.

The API works fine as long as the jbpm engine can treat the exception/error during crash and reflect this situation by updating the process instance status.

The problem is all about process recovery in case of server crash, e.g. the classical power outage.

If such an error happens, a process instance will recover in the last saved state. This means that you do not know, whether a transition to another node has been triggered already and you do not know which transition has been taken, if at all.

In this situation the API does not help, I think.

So potentially I have to implement a history of transistions in a transaction external to the hibernate session. That's the only workaround I can come up with.

Elisabeth

[marco.rietveld]

Elisabeth,

Ah, indeed, I guess I missed that.

I guess the other things I might suggest in this case are the following:

- try to make all code in the actual jbpm 4 node/transition classes idempotent, and have any real operations be external to that code -- by placing the actual operations/actions in external webservices.

- In general, you want to limit code to nodes and not put it in transitions. Among a number of other reasons, these kind of situations are one reason why it's not a good idea.

If you're able to do the above, then you can use the jBPM api to detect which processes are not running/active and restart them or otherwise discard the original process and restart a new process with the same initial information as the original process.

Good luck!

Marco