with the default logging.conf the timestamp is present as in all other web2py-related logging ....
PS: are you sure that the worker is not killed/restarted by any chance (see the worker_name in the scheduler_run table) On Tuesday, March 26, 2013 11:33:53 AM UTC+1, Paolo valleri wrote: > > I executed again demo1, I run it several times, I got even in this case > elapsed time between two consecutive executions around 360 and even more > instead of 300. What can I do to understand what is not working correctly? > Moreover, I would suggest to add the timestamp to the scheduler debug log. > > > Paolo > > > 2013/3/25 Niphlod <[email protected] <javascript:>> > >> >> >> On Monday, March 25, 2013 10:46:12 PM UTC+1, Paolo valleri wrote: >>> >>> 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. >>> >> >> The point is that the thread that manages some logic every heartbeat >> seconds is the one in charge of "waiting" 5 loops to trigger the additional >> logic to pick up new tasks (a repetitive task is just a new task to >> execute). If the process "doing the work" is busy processing the task and >> the underlying thread reaches the "let's assign tasks" loop, the logic will >> be skipped (it's unuseful to assign tasks if a worker is already processing >> them). So it can happen that even if the "assignment" time has come, if the >> worker is processing tasks it will skip the "assignment" >> >> 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? >>> >> >> Nope. As I said it guaranteed that even in the case that the assignment >> loop falls into the timeframe of a RUNNING task, at the next round it will >> be picked up >> >> >>> 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<http://web2py.com/books/default/chapter/29/13#Start-the-scheduler-as-a-Linux-service-%28upstart%29> >>> >>> >> >> SQLite locking is the most probable cause. >> The fastest way is to see what's happening is starting the scheduler with >> debug logging .... >> web2py.py -K appname -D 0 >> >> -- >> >> --- >> 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 >> [email protected] <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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
