-
1. Re: JBeret JDBC Job Repository in EAP 7 Beta
jamezp May 16, 2016 5:59 PM (in response to johnnuy)The problem is during a crash there's no way to update the state of a job since the process is being destroyed. During a controlled shutdown the running jobs should all be stopped and go into a STOPPED status.
You can however restart jobs in that state. See [JBERET-154] Support restarting killed or crashed job execution - JBoss Issue Tracker for details about adding the jberet.restart.mode property to the restart.
--
James R. Perkins
-
2. Re: JBeret JDBC Job Repository in EAP 7 Beta
johnnuy May 16, 2016 6:15 PM (in response to jamezp)Hi James,
Thanks for the reply and the link to the restart property. The part I'm stuck at is programmatically detecting which jobs that are currently in a "STARTING", "STARTED" or "STOPPING" state, need to be restarted without having someone look at them.
I could write some code to validate the interval since the job status changed, against an expected interval for that status, but this would be a job specific calculation and not entirely reliable.
Is it possible to modify the behaviour of the getRunningExecutions() method to not return these jobs that need to be restarted?
-
3. Re: JBeret JDBC Job Repository in EAP 7 Beta
jamezp May 16, 2016 6:27 PM (in response to johnnuy)I can't think of a way for JBeret to know which jobs would require restarting.
Depending on your jobs are started you could use a @Startup EJB to query jobs in the STARTING, STARTED or STOPPING state and restart them. This could get a bit messy though if you have jobs being submitted immediately after a restart of the container.
--
James R. Perkins
-
4. Re: JBeret JDBC Job Repository in EAP 7 Beta
johnnuy May 17, 2016 9:18 AM (in response to jamezp)Ok thanks, delaying the job creation until all jobs have been recovered isn't the end of the world.