sorry, just tried, can't reproduce the issue. Can you post the logs of the schedulers ? Maybe start them adding *-D 0* to activate the DEBUG level What normally goes on is: - you start "dir", it's the first one so it becomes the "TICKER", but it doesn't see any "metrics" worker so it doesn't assign tasks - you start "metrics", after a while the "dir" worker sees it and starts assigning tasks to "metrics" - etc.
Il giorno mercoledì 19 dicembre 2012 04:31:32 UTC+1, JimK ha scritto: > > I'm not sure what the issue was but replacing the gluon/scheduler.py file > with the older one fixed the problem. There were a lot of changes in 2.3.2 > so it's hard to pinpoint what broke things. > > On Tuesday, December 18, 2012 6:36:29 PM UTC-8, JimK wrote: >> >> There appears to be a major bug with the scheduler workers with 2.3.2 in >> tasks are stuck in the ASSIGNED state if that worker group was not the >> first one started. This problem did not exist until I upgraded to 2.3.2 >> this morning. >> >> I have 2 task groups in my service (dir, metrics). >> >> I start the workers after starting the server like so (art is the >> application name): >> /usr/bin/python2.6 /var/www/web2py/web2py.py -K art:dir >> /usr/bin/python2.6 /var/www/web2py/web2py.py -K art:metrics >> /usr/bin/python2.6 /var/www/web2py/web2py.py -K art:rap >> >> If I start the "dir" worker first and the "metrics", my "dir" group tasks >> complete fine but the "metrics" group tasks are stuck in the ASSIGNED state. >> To prove my theory, I then killed all of the workers and stared the >> "metrics" worker first and then "dir" worker. As hypothesized, the >> "metrics" group tasks complete but the "dir" group tasks are stuck in the >> ASSIGNED state. >> >> Any ideas??? >> > --
