You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "Adrian Crum (JIRA)" <ji...@apache.org> on 2014/01/16 12:20:19 UTC
[jira] [Assigned] (OFBIZ-5496) Schedule Job Manager is creating
more then one pending job for future.
[ https://issues.apache.org/jira/browse/OFBIZ-5496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adrian Crum reassigned OFBIZ-5496:
----------------------------------
Assignee: Adrian Crum
> 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)