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