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
> 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 <javascript:>>
>
>> 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/**
>>>> 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+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.


Reply via email to