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 > > 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 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.
