Jbpm 5.4 timer persistence

[ventmonkey]

Hello. I've read https://issues.jboss.org/browse/JBPM-3170 and wanted to get more info on this.   Jbpm3 would get a list of all events that were past their run time from persistence, and run those.  Is there any way to get a list of sessions or process instances that have timers that are past their run time?  I'm fine implementing my own timer, I just don't know which sessions to start.

Are there any plans to get persistence of timer events working in JBPM6?

In https://issues.jboss.org/browse/JBPM-3170 I see mention of a Quartz solution being worked on, but I can't find any further information.  Please help!

Thanks

Mason

[swiderski.maciej]

Why would you need to know that? Timers will be fired as soon as the session becomes active, even if the timer had passed it's origin fire time it will be fired as soon as session gets activated - that's called overdue timers. Timers do work properly with persistence, the only requirement for them is to keep session active.

That has been significantly improved in version 6, where use of quartz based timers is possible and even recommended in clustered environments.

HTH

[ventmonkey]

Thanks for your answer Maciej.  I will look into version 6.

I don't understand how to use overdue timers.  I do have a clustered environment.  Let's say I have a couple of hundred thousand process instances that are watiing at timers, which can be up to a couple of months from now, how do I know which sessions to reactivate?  If I had a list of session that needed to be reactivated I would gladly just use an EJB scheduler to do that.

Thanks,

Mason

[swiderski.maciej]

overdue timers are fired automatically after session has been restored.

To know what sessions need to be restored would depend on your session management strategy. What you could do is to try to group sessions and those with timers would belong to given group that might be identified by name - the grouping mapping would need to be outside of the runtime engine itself. That way when the process goes into timer node you'll have way to find out what session might be worth restoring. Alternatively to timer events you could use signal events and the ejb timer will do the work (signal ksession or process instance) based on time intervals - since you already plan to use ejb timers. So the ejb timer would simple look through the grouping/mapping to find what is awaiting signal and just load the given session and then send signal on it.

HTH

[ventmonkey]

Hello again. I am now working on implementing this within my company. Can you please tell me where I might be able to find documentation on the improved timer handling using Quartz in Jbpm6?  I've downloaded the 6.0.0 Beta 5 docs, but it doesn't seem to reference persistence or timers differently than 5.4 did. 

Thanks,

Mason

[swiderski.maciej]

Mason, here you can find some details about timers in terms of clustering. I'll be writing more dedicated documentation about it too in following weeks.

HTH