RabbitMQ talks

Three valuable links to understanding RabbitMQ and Celery:

http://www.rabbitmq.com/resources/google-tech-talk-final/alexis-google-rabbitmq-talk.pdf
http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/
http://celeryproject.org/docs/userguide/routing.html#amqp-primer
http://celeryproject.org/docs/userguide/monitoring.html#guide-monitoring

In Celery the routing_key is the key used to send the message, while binding_key is the key the queue is bound with. In the AMQP API they are both referred to as the routing key.

Celery automatically creates the entities necessary for the queues in CELERY_QUEUES to work (except if the queue’s auto_declare setting is set to False). This statement implies then it will do all the work to talk to the RabbitMQ server to create the defined exchange name.

Useful commands:

camqadm queue.purge 
celeryctl inspect active
rabbitmqctl list_queues name memory
rabbitmqctl -p  list_queues
rabbitmqctl -p  list_exchanges

http://ask.github.com/celery/userguide/routing.html#changing-the-name-of-the-default-queue

The non-AMQP backends like ghettoq does not support exchanges, so they require the exchange to have the same name as the queue. Using this design ensures it will work for them as well.

http://celeryproject.org/docs/userguide/tasks.html#task-options

Task.ignore_result
Don’t store task state. Note that this means you can’t use AsyncResult to check if the task is ready, or get its return value.