>scheduler tables can be dropped manually
Done
>deleting scheduler.py also.
Done
>But I still don't think that it's the way to fix the issue you're facing.
Well I'm not able to understand which is this problem, as when I create a
scheduler in a new app tasks are running.
For the moment creating a new scheduler is my better idea, if you have a
better one thanks.
Anyway now I've got this error when I try to open the scheduler table, for
example scheduler_task.
My db string have now migrate=True, fake_migrate_all=True.
My only other idea is rebuild all the app starting from a new one, but if I
can resolve it in a shorter way I prefer.
Traceback (most recent call last):
File
"/home/tasko/webapps/w2p_2_12_3/web2py/applications/hydrover_oleodinamica/controllers/appadmin.py",
line 238, in select
nrows = db(query).count()
File
"/home/tasko/webapps/w2p_2_12_3/web2py/gluon/packages/dal/pydal/objects.py",
line 1992, in count
return db._adapter.count(self.query,distinct)
File
"/home/tasko/webapps/w2p_2_12_3/web2py/gluon/packages/dal/pydal/adapters/base.py",
line 1311, in count
self.execute(self._count(query, distinct))
File
"/home/tasko/webapps/w2p_2_12_3/web2py/gluon/packages/dal/pydal/adapters/postgres.py",
line 360, in execute
return BaseAdapter.execute(self, *a, **b)
File
"/home/tasko/webapps/w2p_2_12_3/web2py/gluon/packages/dal/pydal/adapters/base.py",
line 1378, in execute
return self.log_execute(*a, **b)
File
"/home/tasko/webapps/w2p_2_12_3/web2py/gluon/packages/dal/pydal/adapters/base.py",
line 1372, in log_execute
ret = self.cursor.execute(command, *a[1:], **b)
ProgrammingError: relation "scheduler_task" does not exist
LINE 1: SELECT count(*) FROM "scheduler_task" WHERE ("scheduler_task...
Il giorno venerdì 18 dicembre 2015 11:58:15 UTC+1, Niphlod ha scritto:
>
> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
