scheduler tables can be dropped manually deleting scheduler.py also. But I still don't think that it's the way to fix the issue you're facing.
On Friday, December 18, 2015 at 11:22:57 AM UTC+1, Gael Princivalle wrote: > > >delete what ? the istantiation ? > > Delete the scheduler.py file from models and all scheduler tables. > How can I do it? > > Il giorno venerdì 18 dicembre 2015 10:48:23 UTC+1, Niphlod ha scritto: >> >> >> >> On Friday, December 18, 2015 at 10:45:22 AM UTC+1, Gael Princivalle wrote: >>> >>> I've set a scheduler in a new application and tasks are running. >>> >>> So probably there's a problem when a app comes from a previous web2py >>> version. >>> >> >> as long as you let migration happen, no issues whatsoever. >> >> >>> Anyway I think it can be resolved deleting the scheduler and create it >>> again, but I've tried to: >>> Killing the worker - Ok >>> Delete Scheduler Ko >>> >>> When I delete the scheduler.py file from admin web2py creates it again. >>> >>> How can I delete the scheduler? >>> >> >> delete what ? the istantiation ? >> >> >>> >>> Thanks, regards. >>> >>> Il giorno giovedì 17 dicembre 2015 21:40:36 UTC+1, Gael Princivalle ha >>> scritto: >>>> >>>> Thanks Niphlod. >>>> >>>> >So, here it is the breakdown of the possible issues: >>>> >- are tasks QUEUED or ASSIGNED ? >>>> QUEUED. But if I set the net run time to now + 2 minutes I can check >>>> that task don't run. >>>> Status options don't have ASSIGNED. >>>> >>>> >If they are QUEUED, either they can't be executed yet (i.e. start_time >>>> in the future) or tasks are queued with a group_name that can't be >>>> processed by a worker . >>>> Main group for all. >>>> >>>> *>Check #1: there should be a scheduler_task row with group_name "in" >>>> scheduler_worker group_names* >>>> >- if tasks SHOULD be ASSIGNED but remain on QUEUED status, no worker >>>> is running or workers can't agree on who is "the ticker". >>>> Well worker is running and main is the group_name. >>>> >>>> *>Check #2 (there should be a scheduler_worker with is_ticker = True)* >>>> Yes it have. >>>> >>>> Check is complete. I think I will cancel the scheduler and create it >>>> again. Thanks for your help. >>>> >>>> Il giorno giovedì 17 dicembre 2015 21:21:56 UTC+1, Niphlod ha scritto: >>>>> >>>>> I thought more people liked to see the code : I find myself explaining >>>>> scheduler internals more often than I'd like to :P >>>>> >>>>> soooooooooo. worker names.... worker names are used to identify a >>>>> worker process (it's enforced as unique in the model)... >>>>> I'll reply to some ideal "FAQ" questions.... >>>>> - Why worker names are important ? Because tasks ASSIGNED to a >>>>> worker_name (assigned_worker_name in scheduler_task) get processed by >>>>> that worker, and that worker only >>>>> - Who chooses worker names ? the worker itself. It does so >>>>> concatenating the hostname and the PID, which results in a good (and >>>>> unique) way to identify a process. >>>>> - Who chooses that task "foo" gets processed by worker "bar" ? A >>>>> worker. It's when tasks from QUEUED go to the ASSIGNED status... The >>>>> worker >>>>> that does this is "the ticker". The ticker is "elected" with a dumb (and >>>>> slow) - but reliable - algorithm among workers: it's the only one that >>>>> can >>>>> "assign" tasks (either to itself or to other workers). The only thing >>>>> that >>>>> blocks a ticker to assign tasks to a worker is the group_name. >>>>> >>>>> So, here it is the breakdown of the possible issues: >>>>> - are tasks QUEUED or ASSIGNED ? If they are QUEUED, either they can't >>>>> be executed yet (i.e. start_time in the future) or tasks are queued with >>>>> a >>>>> group_name that can't be processed by a worker . >>>>> *Check #1: there should be a scheduler_task row with group_name "in" >>>>> scheduler_worker group_names* >>>>> - if tasks SHOULD be ASSIGNED but remain on QUEUED status, no worker >>>>> is running or workers can't agree on who is "the ticker". >>>>> *Check #2 (there should be a scheduler_worker with is_ticker = True)* >>>>> That should be it. >>>>> >>>>> >>>>> Note: if tasks are ASSIGNED to a worker that isn't there anymore (i.e. >>>>> is dead or, in your case, you changed hosting facility) it's not an >>>>> issue. >>>>> Any worker, periodically, checks if ALL other workers are alive (and >>>>> kicking) and if a worker isn't kicking it's removed from the >>>>> scheduler_worker table AND all tasks ASSIGNED to it gets redistributed >>>>> among live workers. This in addition to the ticker redistributing tasks >>>>> every once in a while if they're ready to be executed but not executed >>>>> yet >>>>> (it can, and it does happen, that a worker is busy processing a >>>>> long-running task while there are other tasks ready to be processed (by >>>>> other workers). Every worker gets a fair chance of doing something useful >>>>> instead of sleeping) >>>>> >>>>> On Thursday, December 17, 2015 at 9:02:11 PM UTC+1, Gael Princivalle >>>>> wrote: >>>>>> >>>>>> Hello to all. >>>>>> >>>>>> I've migrate my webfaction hosting to another webfaction hosting that >>>>>> run CentOS 7 (before it was a previous version of CentOS). >>>>>> I was running web2py 2.9.12, now I have web2py 2.12.3. >>>>>> >>>>>> I've got a strange problem with the scheduler. >>>>>> >>>>>> Workers are in the db, they run, they are assigned to tasks, but >>>>>> tasks don't run. >>>>>> When I've created new workers tasks have not take automatically the >>>>>> worker name. I've put all worker names by myself. >>>>>> >>>>>> Perhaps the problem is due to the worker names. >>>>>> In the previous hosting they were like that: >>>>>> s18060957#14459 >>>>>> >>>>>> And now they have the webserver name: >>>>>> web490.webfaction.com#12949 >>>>>> >>>>>> web2py seems to codify the webserver name, but in this new >>>>>> configuration it don't. >>>>>> Is it why Scheduler don't run tasks? >>>>>> How I can resolve that? >>>>>> >>>>>> Thanks, regards. >>>>>> >>>>> -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- 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/d/optout.
