[
https://issues.apache.org/jira/browse/OFBIZ-5496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13873342#comment-13873342
]
Adrian Crum commented on OFBIZ-5496:
------------------------------------
Fixed in trunk rev 1558774, and in R13 branch rev 1558779.
R11 and R12 should have the improved Job Scheduler backported because the
previous design had many problems.
> Schedule Job Manager is creating more then one pending job for future.
> ----------------------------------------------------------------------
>
> Key: OFBIZ-5496
> URL: https://issues.apache.org/jira/browse/OFBIZ-5496
> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Affects Versions: Release Branch 11.04, SVN trunk, Release Branch 12.04,
> Release Branch 13.07
> Reporter: Ritu Raj Lakhera
> Assignee: Adrian Crum
> Attachments: JobManager_1104_1204.patch, JobManager_1307_trunk.patch
>
>
> Schedule Job Manager is creating more then one pending job for future. Issue
> is coming in sporadic manner when a transaction reach to its time out
> position.
> So schedule job is increasing with multiply by two or more after every
> execution and grabbing the whole application memory which may cause the out
> of memory error.
> Below is the algorithm structure of current implementation in version 12.04.
> 1 returnList;
> 2 pollDone = false;
> 3 While pollDone is equal false
> 4 Transaction Begin //Default time out 60 sec
> 5 localPollList;
> 6 update JOB_SANDBOX SET RUN_BY_INSTANCE_ID = 'ofbiz1', STATUS_ID =
> "SERVICE_QUEUED" WHERE RUN_TIME <= NOW() AND START_DATE_TIME = NULL AND
> CANCEL_DATE_TIME = NULL AND RUN_BY_INSTANCE_ID = NULL;
> 7 result = SELECT RESULTS FROM JOB_SANDBOX WHERE RUN_BY_INSTANCE_ID =
> 'ofbiz1', STATUS_ID = "SERVICE_QUEUED";
> 8 IF result is empty
> 9 pollDone = true;
> 10 ELSE
> 11 For each result row
> 12 Create the Persit Job Object and add to localPollList
> 13 EndFor
> 14 ENDIF
> 15 Add the localPollList to returnList
> 16 Transaction Commit
> 17 EndWhile
> 18 Return returnList
> Test Case Execution Step
> 1. If transaction reach to its time out position so an exception will come on
> step 16 which will roll back step 6.
> But on step 15 return list has increased with list of Job object.
> 2. In next iteration, If transaction does not reach to its time out position
> then on step 15 return list will again increase with list of same Job object.
> So return list will have duplicate Job object for one schedule job and each
> will create a pending Job for future base on recurrence info.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
