Hello, had a look at the actual code this weekend and the problem is that the scheduler goes into a default wait state of 1hr if it can not find an active scheduler with a nextcall date in the future. So basicly there needs to be atleast one active job with a 'valid' nextcall date to avoid this.
I commited a small fix that adds the option 'Add Runtime' to scheduler jobs. If this option is enabled the nextcall date will be now()+runtime of job+call interval, instead of nextcall+call interval. Enabling this option should keep the scheduler alive. Also i noticed that the client executes job runs if you update job records. Which i think is a bug, in theory that same job might already be running when you update a job record. To fix this now only the scheduler timer gets reset when you update a job record via client. Finally i implemented some simple statistics for scheduler jobs, once you enable the option 'Track Runtime' it will save data for longest/shortest/average and last runtime of this job. The branch is up and ready for merging: https://code.launchpad.net/~openerp-community/openobject-server/edannenberg_frequentcronjobs regards, Erik Dannenberg bloopark systems ----- Original Message ----- Hello, Raphaël recommended to forward this from the magentoerpconnect mailing list. So here we go: Just a little heads up on the openerp scheduler. It seems the scheduler in v5 (no idea if its the same in v6 but i would guess so) has some serious design flaws. Scenario: Lets say we have 2 jobs that are running every 5 minutes. Each of those jobs takes 3 minutes to run. So the scheduler will grab the jobs it needs to execute and call them one by one. After each job run it sets the time for the next call on each called job. The problem is that the whole run took 6 minutes while the dates for the next call are based on the previous call date. What now happens is that the time for the next call is already in the past and hence the scheduler simply won't call the jobs anymore. Now there is that checkbox 'repeat missed' which i think is what is supposed to fix that. Let's see what happens: So the jobs run for the first time, the next call date is set in the past and hence no more job execution. Until you restart the server, on restart openerp will execute the 2 jobs for each intervall it missed repeatly, and then happily sets a next call time in the past. So after that the jobs will still cease to keep running. Conclusion: If you set up a couple of frequent jobs you have to take into account the whole runtime for all jobs, the call intervall for each job needs to be longer then the total runtime of all jobs. Else you will run into problems. Personally i think at its current form the scheduler is not usable for frequent job calls and needs a redesign. A quick fix might be to set the next call time based on the runtime of the job, ie at the end of the job run set next_call to now()+call_intervall. Ofcourse this will not work if you want jobs to execute at a fixed time, but should be ok if all you need is short intervalls. regards, Erik Dannenberg bloopark systems _______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
