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