[ops][largescale-sig] rabbitmq and the durability of reply_ queues

Arnaud Morin arnaud.morin at gmail.com
Mon Sep 5 18:04:15 UTC 2022


Hello,

Thank you for bringing that up.
I was thinking (but it seems I was wrong) that the fanout/reply queues
were used for a one shot message/reply.

Besides that, I am also wondering how much cpu power we will need to
replicate such queues?

I guess I can can do the math from what we are currently running in
production :)

Have you tried on a big cluster on your side?

Cheers,

Arnaud


On 02.09.22 - 08:19, Felix Hüttner wrote:
> Hi everyone,
> 
> the largescale-sig currently recommends the following rabbitmq policy [1]: '^(?!(amq\.)|(.*_fanout_)|(reply_)).*'.
> 
> If I found the history of this setting correctly, it resulted from this mailinglist thread [2] which came to the conclusion:
> 
> > * use durable-queue and replication for long-running queues/exchanges
> > * use non-durable-queue without replication for short (fanout, reply_) queues
> 
> However I am unsure if reply_ queues are actually shorted lived than the "long-running" ones.
> If we take the example of the cinder-scheduler we have the following queues:
> 
> * cinder-scheduler: Tied to the lifetime of the whole cinder-scheduler cluster; currently durable + replicated
> * cinder-scheduler.myhostname: Tied to the lifetime of the cinder-scheduler service, but not removed when the service stops; currently durable + replicated
> * cinder-scheduler_fanout_somerandomid: Tied to the lifetime of the cinder-scheduler service, but removed when the service stops; currently neither durable nor replicated
> * reply_somerandomid: Tied to the lifetime of the cinder-scheduler service, but removed when the service stops; currently neither durable nor replicated
> 
> If I read got all of the above correctly then reply_ and fanout queues are actually not shorter lived than the normal queue to send requests to that service.
> The only difference is that we remove them when the service itself stops.
> 
> Therefor I want to propose the question if we should not also make these queues durable and replicated.
> 
> Thank you
> 
> [1]: https://docs.openstack.org/large-scale/other/rabbitmq.html#pattern
> [2]: https://lists.openstack.org/pipermail/openstack-discuss/2020-August/016562.html
> 
> --
> Felix Huettner
> 
> Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hier<https://www.datenschutz.schwarz>.
> 



More information about the openstack-discuss mailing list