[ https://issues.apache.org/jira/browse/OFBIZ-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15080525#comment-15080525 ]
Scott Gray commented on OFBIZ-6784: ----------------------------------- bq. Right the job run immediately, but the job is also planned one hour later. Weird, I thought this had been fixed already. reloadCrashedJobs shouldn't store recurrence/temporal info on the new job if the crashed job's status is SERVICE_RUNNING, because the init() of the crashed job will have already scheduled it before the server went down. It's just a matter of setting tempExprId and recurrenceInfoId to null before storing the new job. > JobSandbox : reload crashed job maybe duplicate pending service > --------------------------------------------------------------- > > Key: OFBIZ-6784 > URL: https://issues.apache.org/jira/browse/OFBIZ-6784 > Project: OFBiz > Issue Type: Bug > Components: framework > Affects Versions: Trunk > Reporter: Nicolas Malin > Assignee: Nicolas Malin > Labels: jobsandbox > Attachments: OFBIZ-6784.patch > > > When the JobPoller run reloadCrashedJobs() after an OFBiz restart, if you > have a large service that crash that already replenish the pool receive a new > run instant for it. > Example: If you have a service like loadExternalOrder that run each hours. > You stop your OFBiz during their activity and at restart you have : > * job1 loadExternalOrder RUNINNG > * job2 loadExternalOrder PENDING at t+1h (normal schedule) > * job1.1 loadExternalOrder PENDING at t+1h (crashed schedule) > I propose to exclude from the process reloadCrashedJobs() all jobs that have > already a new scheduled instance -- This message was sent by Atlassian JIRA (v6.3.4#6332)