hmm... seems like we still have the same problem, unless i was supposed to copy more files than just scheduler.py
loaded around 12,000 records into slow_track, while fast_track has very few, but some should be executed by now... 3 workers are properly running (main, slow_track, fast_track), but no tasks are being executed at this point. restarted apache, stopped and started scheduler several times. that's the situation at this point... not sure if i could test something more specific to figure out what is going on? On Sat, Oct 20, 2012 at 9:05 PM, Adnan Smajlovic <adnan.smajlo...@gmail.com>wrote: > will try to replacing scheduler.py in production and load some serious > data again, since all is setup there for the full process, so we can have a > real test :) > > I understand the concept with main being the default group, but wasn't > sure if I was doing something wrong. All clear now :) Thanks for fixing it, > and will let you know results soon. > > > > On Sat, Oct 20, 2012 at 4:10 PM, Niphlod <niph...@gmail.com> wrote: > >> >> >>> The main group worker got created even though I didn't call it... Not >>> sure why, but i guess because there are lot of leftover tasks queued (500k) >>> and some were assigned when I stopped the process. >>> >>> Remind that a group_name for tasks is required for the scheduler to >> work. >> However, the default value is 'main', so when you do >> db.scheduler_task.validate_and_insert(function_name='test') >> what is really happening is >> db.scheduler_task.validate_and_insert(function_name='test', >> group_name='main') >> >> If you start a scheduler with default values, it processes tasks with >> group_name = 'main', so when you do >> web2py.py -K crm >> what is really happening is >> web2py.py -K crm:main >> >> This is meant to avoid the hassle of group_name(ing) tasks for users that >> don't need different group_names but allow "power-users" (like you :P) with >> the added flexibility of having different ones. >> >> --
