nicholasdavidson
commented
11 years ago I'm not sure about your assessment, as I'm a little unclear on what your asking so forgive me if I explain the wrong thing or go off on a tangent.
We have two kinds of queue in pybit - the public distro-suite-arch-package style queues which are used for build-requests and as you correctly identify are used to make build-requests persistent. I.e. they are work queues. These are routed to by a direct-exchange not a topic exchange, but the key style we used was delimited by dots so we could switch to topic exchanges in future if it made sense. This was in retrospect perhaps a confusing choice.
An example of a queue would be debian-squeeze-armhf-deb, this would be listened to by all clients that were capable of building packages of that type.
The second type of queue we use is a private message queue per client which is used to enable multi-process communication as the build moves through its steps and so we can kill an in-progress job.
Some of our design decisions may be a bit archaic because we're using Debian Squeeze which has old versions of rabbitmq-server and the python amqp client libraries.
I'm curious about why PyBit choose to use queue exchange, topic style queue assignment and named queues. Forgive me as I'm still a bit green when it comes to using message queues even though I have minimally used them before. I may have come to the conclusion on my own, but it would be good to verify that is correct.
It appears to me that PyBit uses the named queues to maintain persistance. At first I though this was odd due to the use of a named exchange with topics, which would fulfill the need of sending the message to the correct queue. It seems redundant to send the message via topics as well as to a specific named queue. But this is necessary in order to always have somewhere to send the message, even if the worker is not runner at the time. Is this a correct assessment?