2010-2-24

02:44 cominatchu
i am wondering i there would be a reason the output of rabbitmqctl list_queues -p / name messages consumers would be incorrect?
02:44 cominatchu
for instance i get: celeryctl_worker37 0 1
02:44 cominatchu
celery 458 37
02:44 cominatchu
celeryctl_worker19 0 1
02:44 cominatchu
celery 458 37*
02:45 cominatchu
but i don't believe there are 458 jobs in the queue
08:18 tim__
I have an interesting problem with a periodic task and the beat server. I'm running in Django, python manage.py celeryd -B and the periodic task I have defined executes fine, no problems at all. I stopped celeryd and started again, this time without the beat option e.g. python manage.py celeryd and the funny thing is that the periodic task is still going! It keeps executing
08:19 tim__
This wasn't what I was expecting, I was really expecting that it wouldn't execute because there was no beat server. Any suggestions? I only have two celery worker servers, both on seperate machines and they both show . beat -> OFF in the terminal window
08:26 underseapilot
tim__ - maybe a stray beat process still running?
08:27 tim__
Thanks - I was just about to say I think I've found it...
08:28 tim__
When I run ps aux | grep celeryd I can see some celeryd -B processes still there. I must of killed the wrong process before
09:17 asksol
tim__: celery 1.0.1 will be released soon, fixes a bug with the -B option
09:18 asksol
that is that the celerybeat process is not shutdown properly
09:57 padt
asksol: jesper was tweeting this morning about 2.4 support in case you didn't notice
09:59 asksol
yeah
09:59 asksol
working with him now
09:59 asksol
I was waiting for him to test it
10:14 padt
ah. cool
14:22 asksol
fixed a bug in master with eta tasks not being executed
14:22 asksol
that is, it's not present in 1.0, just recent changes
17:35 stovenator
asksol: Just wanted to let you know I figured out how to do a periodic task for multiple instances of a class
17:35 stovenator
code here works without modification needed for celery 1.0.0 : http://pastebin.com/KiypHWtV
22:58 tim
Can anyone explain the difference between python manage.py celeryd -B VS python manage.py celerybeat? I expected they would be the same, but they behave differently. With a four core machine, running celeryd - B I end up with five processes (presumably four normal celeryd and one beat server). When I run celerybeat I end up with only one celerybeat server, which I'd expect, BUT the celerybeat server doesn't seem to execute the
22:58 tim
periodic tasks, where as the celerd -B option does.
22:59 tim
OK, don't worry - just as I was writing this I figured out what I was doing wrong :-)
23:00 tim
For the record, just realised they ARE doing the same thing, but when I run a celerybeat only I have no worker running to process the tasks, whereas with celeryd -B I get both workers and the beat server which is why it looks like its working /DOH
23:06 otherjacob
asksol: what's the biggest deployment of celery you know of in terms of number of daemons? wondering if there's any known issues in growing the amount
23:13 tim
How do the number of daemons / workers relate to the queues, especially in Django where the queues / bindings are specified in settings.py so they are shared? Does each worker listen to all queues? Or if there were four workers and two queues, do two listen to one queue and two to the other?