I can make few tests but only tomorrow, I will be out for the rest of the week. If you send me a patch with the new log statement, I will come back with the result asap.
Paolo 2013/3/26 Niphlod <niph...@gmail.com> > whoa. seems that something wrong is happening trying to assing new > tasks.... > normally, every > web2py.scheduler.mapserver#7791 - INFO - TICKER: I'm a ticker > should be followed closely by the lines > web2py.scheduler.mapserver#7791 - INFO - TICKER: workers are 1 > web2py.scheduler.mapserver#7791 - INFO - TICKER: tasks are 0 > While in your case for several times those lines are not present.... > The fact is that the assignment is wrapped yet in a try except clause and > every exception should be logged as well, but your log doesn't show > anything of that. > > I can add more debug lines to the scheduler but this didn't ever happen on > all my platforms, so without reproducing it I'm a little bit unsure what > the fix can be. > > > On Tuesday, March 26, 2013 4:26:11 PM UTC+1, Paolo valleri wrote: > >> the flle! sorry... >> >> Paolo >> >> >> 2013/3/26 paolo....@gmail.com <paolo....@gmail.com> >> >>> If can be useful, I attached part of the log file in which demo1 is >>> executed. >>> First execution: 2013-03-26 15:52:31 >>> second execution: 2013-03-26 15:58:55 (+384s) >>> >>> Paolo >>> >>> >>> 2013/3/26 Paolo valleri <paolo....@gmail.com> >>> >>> >>> import sqlite3 >>>> >>> print sqlite3.version >>>> 2.6.0 >>>> >>> print sqlite3.sqlite_version >>>> 3.7.9 >>>> But, if the db lock is not the problem, the test application is very >>>> easy, where is it supposed to be the problem? >>>> >>>> >>>> On Tuesday, March 26, 2013 2:32:50 PM UTC+1, Niphlod wrote: >>>>> >>>>> I find hard to believe that with a single worker, with that function >>>>> that basically just prints something and an execution every 300 seconds >>>>> the >>>>> problem lies into a lock, unless the SQLite library available on your >>>>> system is reallly old. >>>>> >>>>> On Tuesday, March 26, 2013 2:21:21 PM UTC+1, Paolo valleri wrote: >>>>>> >>>>>> When yesterday I saw demo1 in timeout with ps auxf I have seen that a >>>>>> new process was created. For this reason I started to debug scheduler >>>>>> and I >>>>>> asked how to log etc. >>>>>> Moreover, I restarted the scheduler manually so I am not able to >>>>>> understand if the other different names are for an internal problem or >>>>>> something different. >>>>>> Do you think that should be fixed by using a different db engine? >>>>>> >>>>>> Paolo >>>>>> >>>>>> On Tuesday, March 26, 2013 12:42:14 PM UTC+1, Niphlod wrote: >>>>>>> >>>>>>> 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 <nip...@gmail.com> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 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/**defaul****t/chapter/29/13#Start-**the-* >>>>>>>>>> *sche**duler-as-a-Linux-**service-%**28up**start%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/ >>>>>>>>> **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.
