[jira] [Commented] (OFBIZ-5496) Schedule Job Manager is creating more then one pending job for future.

["Adrian Crum (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OFBIZ-5496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13873323#comment-13873323 ] 

Adrian Crum commented on OFBIZ-5496:
------------------------------------

Thank you for the bug report.

To clarify the problem:

When the Job Poller queues jobs, it sets the runByInstanceId field in the JobSandbox entity to "claim ownership" of the job (in case there are more than one Job Pollers running). The job is added to a List. If an exception is thrown during the polling process, the transaction will be rolled back - causing the runByInstanceId field in the JobSandbox to be "unset" (returned to null), BUT the job entry in the List is not removed. The job will be queued and run, and on the next polling interval the same set of jobs will be queued again (because of the previous rollback).


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