[
https://issues.apache.org/jira/browse/OFBIZ-5496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13873345#comment-13873345
]
Ritu Raj Lakhera commented on OFBIZ-5496:
-----------------------------------------
Thanks for looking in this.
I have a query on this. When a particular job is going to rollback at the time
of polling then pool is also loosing the ownership because JTA has reverted the
changes(runByInstanceId) from DB.
And Code will again give the chance to poll this particular job (see
JobManager.java line 141 in version 12.04).
I think code should also release the job from polling list because next
iteration will again poll the same job in poll list.
So two different job thread will create the separate future job (See init
method of PersistedServiceJob.java).
I'm also also attaching the patch file(JobManager_1204_Generate_Issue.patch)
which can produce the issue and create the double future job for a schedule,
please take a look.
> 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)
