jBPM timer questions

[zhangjing2000]

1. Is there a way to use an external timer service rather than use the built-in one?

2. The reason I asked the first question is I found there might be some problems in jBPM timer service implementation. I found it is relying on Drools timer service and a timer instance is stored in SessionInfo table. we run into two issues because of this

a. If by accident, the process instance, which timer is attached to, is removed from database, the timer will not be removed and will continue wake up and try to put itself into command executor to run, which always throws exception. Because it is in SessionInfo, it is very hard to manually delete it, and once past due, it will be scheduled to run immediately after load from database. Sometimes we found it will continue spawn new threads recursively, eventually will exhaust all threads in JVM. Please advise how to avoid this situation.

b. We also found whenever redo the process deployment, it will create a new timer for existing process instance. This might because process instance is resumed in a new session, which cannot find timer, thus a new timer instance is created, but we cannot be exactly sure the root cause.

Your feedback is really appreciated. 

[swiderski.maciej]

Jing Zhang wrote:

1. Is there a way to use an external timer service rather than use the built-in one?

yes, you would need to implement timer service yourself. Although please keep in mind that in version 6 jBPM comes with Quartz based timer service out of the box which should allow better management of timer tasks.

Jing Zhang wrote:

2. The reason I asked the first question is I found there might be some problems in jBPM timer service implementation. I found it is relying on Drools timer service and a timer instance is stored in SessionInfo table. we run into two issues because of this

a. If by accident, the process instance, which timer is attached to, is removed from database, the timer will not be removed and will continue wake up and try to put itself into command executor to run, which always throws exception. Because it is in SessionInfo, it is very hard to manually delete it, and once past due, it will be scheduled to run immediately after load from database. Sometimes we found it will continue spawn new threads recursively, eventually will exhaust all threads in JVM. Please advise how to avoid this situation.

b. We also found whenever redo the process deployment, it will create a new timer for existing process instance. This might because process instance is resumed in a new session, which cannot find timer, thus a new timer instance is created, but we cannot be exactly sure the root cause.

the main thing to keep in mind is that timer is considered ksession state data, meaning it will only reside in that given session instance. So when it's removed that timer instance will be lost and thus process instance will remain not triggered. To properly dance timer you need to cancel timer node instance to properly remove it from the state and thus not causing it to be retriggered. Alternatively you can cancel/abort entire node instance container - which is usually process instance or sub process instance.

HTH