I didn't get your point, with one repetitive task, should I start the scheduler with two or more workers? If so, I will try it. Actually I have just seen the stop time, on average the task completes it cycle in just a few seconds (~1-2). Given that, is what you have suggested still valid? Last but not least, demo1 has gone in timeout after one successful cycle, this is very odd, How I can debug the scheduler application and find its errors? I am running scheduler as a linux service, as described here: http://web2py.com/books/default/chapter/29/13#Start-the-scheduler-as-a-Linux-service-%28upstart%29
Paolo 2013/3/25 Niphlod <niph...@gmail.com> > I don't think that's the issue cause next_time_run gets calculated from > the start_time of the previous task, i.e. if I put time.sleep(60) in > demo1(), I still get the same execution times... > > The only bit missing at this point is remembering that if you have a > single worker it can't ASSIGN a new task while a task is RUNNING, so if, > e.g., your task is still RUNNING while the scheduler reaches "the 5th > round" it will skip the assignment and do it on the 10th, i.e. the first > time it's not processing any task and 15 seconds are passed (still, worst > case scenario) > > > On Monday, March 25, 2013 10:07:45 PM UTC+1, Paolo valleri wrote: > >> My task is available here: https://github.com/ilvalle/** >> scapp/blob/master/models/**scheduler.py<https://github.com/ilvalle/scapp/blob/master/models/scheduler.py> >> As you can see the difference is related to the external request. Asap I >> will try your app too. >> >> Paolo >> >> >> 2013/3/25 Niphlod <nip...@gmail.com> >> >> 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> >>>> >>>>> 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/**sca****pp/blob/master/models/** >>>>>> schedule****r.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/**to >>>>> **pic/web2py/u_PgzKLuQmw/**unsubsc**ribe?hl=en<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. >>>>> >>>>> For more options, visit >>>>> https://groups.google.com/**grou**ps/opt_out<https://groups.google.com/groups/opt_out> >>>>> . >>>>> >>>>> >>>>> >>>> >>>> -- >>> >>> --- >>> 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<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. >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>> . >>> >>> >>> >> >> -- > > --- > 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+unsubscr...@googlegroups.com. > 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.
