[
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)
Locked
