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.
