-
1. Re: Jbpm 5.4 timer persistence
swiderski.maciej Aug 9, 2013 1:59 AM (in response to ventmonkey)1 of 1 people found this helpfulWhy 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
-
2. Re: Jbpm 5.4 timer persistence
ventmonkey Aug 9, 2013 10:38 AM (in response to swiderski.maciej)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
-
3. Re: Jbpm 5.4 timer persistence
swiderski.maciej Aug 12, 2013 1:09 AM (in response to ventmonkey)1 of 1 people found this helpfuloverdue 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
-
4. Re: Jbpm 5.4 timer persistence
ventmonkey Aug 26, 2013 5:23 PM (in response to 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
-
5. Re: Jbpm 5.4 timer persistence
swiderski.maciej Aug 29, 2013 1:40 AM (in response to ventmonkey)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