when you dropped tables, did you remember to delete the corresponding
*.table files from the databases/ folder ?
On Friday, December 18, 2015 at 12:47:38 PM UTC+1, Gael Princivalle wrote:
>
> >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.
