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 <javascript:> <paolo....@gmail.com<javascript:> > > > >> 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 <javascript:>> >> >>> >>> 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-** >>>>>>>>> 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<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.
