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 [email protected]. For more options, visit https://groups.google.com/d/optout.
