can't reproduce the issue, even with SQLite. Using the demo1() function from the w2p_scheduler_test app, if I schedule it with period=300, repeats = 0, this is what I get back
r1: 2013-03-25 21:32:56 r2: 2013-03-25 21:38:12 -- 316s r3: 2013-03-25 21:43:28 -- 316s r4: 2013-03-25 21:48:31 -- 303s r5: 2013-03-25 21:53:36 -- 305s On Monday, March 25, 2013 8:57:09 PM UTC+1, Paolo valleri wrote: > > Hi, given the fact that I left untouched the heartbeats value and that my > worker was performing only the test task, I got odd starting values: > t1: 2013-03-25 15:34:43 > t2: 2013-03-25 15:40:48 ( t2 started after 6m + 5s = 365seconds ) > t3: 2013-03-25 15:46:52 ( t3 started after 6m + 4s = 364seconds ) > t4: 2013-03-25 15:52:08 ( t4 started after 5m +16s = 316seconds ) > t5: 2013-03-25 15:57:22 ( t5 started after 5m +14s = 314seconds ) > > Given these starting values, it seems that only the last one is under 315. > I think we should investigate more how scheduler runs repetitive tasks. > > > > Paolo > > > 2013/3/25 Niphlod <nip...@gmail.com <javascript:>> > >> The scheduler is not as "precise" as you would because there are some >> design considerations to think of.... >> >> The "uber-costraint" is that a worker can execute only one task at a >> time --> if the scheduler is busy with something else, queued tasks can be >> "delayed" down the line >> If the worker is free, new tasks are checked every 5*heartbeats seconds, >> so (unless immediate=True) you can get a timeframe for execution that spans >> in the worst case scenario with the default values by 15 seconds >> >> This means that in the worst case scenario you could have a repeating >> task with a 300 seconds period that are actually executed every 315 seconds. >> >> To clear out doubts, for repetitive tasks, as documented in more detail >> in the w2p_scheduler_tests app, the start time of the next execution is >> calculated adding period seconds after the start time of the current >> execution. >> Lockings on the db can add more "imprecision", cause by the default the >> scheduler is eager to store/update whatever it needs to, to ensure >> consinstency between the real executions and the data stored on the tables. >> >> >> On Monday, March 25, 2013 4:23:56 PM UTC+1, Paolo valleri wrote: >>> >>> Dear all, >>> I started to use scheduler. I've created a simple starting example task: >>> https://github.com/ilvalle/**scapp/blob/master/models/**scheduler.py<https://github.com/ilvalle/scapp/blob/master/models/scheduler.py> >>> and with the great niphlod's plugin cs_monitor_plugin I created an >>> initial repetitive task. >>> However, although I set repeats: 0 and period: 300, tasks are not >>> repeated as expected exactly every 300s. The first five tasks were executed >>> at: >>> 2013-03-25 15:34:43 >>> 2013-03-25 15:40:48 >>> 2013-03-25 15:46:52 >>> 2013-03-25 15:52:08 >>> 2013-03-25 15:57:22 >>> The time between two consecutive execution is not so straightforward. >>> what am I missing? Is there a way to impose more accuracy ? >>> >>> paolo >>> >> -- >> >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "web2py-users" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/web2py/u_PgzKLuQmw/unsubscribe?hl=en. >> To unsubscribe from this group and all its topics, send an email to >> web2py+un...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
