7 ms·
one queue for every worker instance, yes! this is for broadcasting remote control commands, but I don't see how this poses a problem? If you mean the one queue
by asksol 14y ago
one queue for every worker instance, yes! this is for broadcasting remote control commands, but I don't see how this poses a problem?
If you mean the one queue for every task behavior of the amqp result backend then that is also a yes.
Usually with replies in amqp you create one queue for every client, but Celery is often used in a web context
where the process that initiated the task may not be the same process that collects the reply, so this
is why it uses one queue for every task (it's also documented).
There's an experimental result backend for RPC-style replies, that uses transient messages and one queue per client:
http://github.com/celery/celery/tree/kombuRPC http://github.com/celery/celery/tree/kombuRPC
- rjurney 14y agoThat is a problem for me, because I want all events of one type running through one AMQP queue to monitor throughput, etc.
- asksol 14y agoSeveral ways to accomplish that, but I would recommend using kombu in combination with celery to have the task manually send messages. You could set the exchange type of the results exchange to be topic too, that way you would both have result queues and you could additionally bind a queue to the results exchange to get a copy of all the messages sent there. But if you don't need to listen for individual results then I'd rather just send messages manually. You have both connection and producer pools in Celery, so it's rather convenient to combine kombu with celery.