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? |