MetPX / sarracenia

https://MetPX.github.io/sarracenia
GNU General Public License v2.0
44 stars 22 forks source link

Prefetch count is applied to all consumers on a channel (RabbitMQ) #1233

Open reidsunderland opened 5 days ago

reidsunderland commented 5 days ago

I'm just documenting what is currently happening, I'm not sure if this is a problem or a bug. It is possibly confusing and could possibly be worth changing, but there might not be a practical difference.

When I was looking at the consumers on a queue in RabbitMQ, they showed a prefetch count of 0, which seemed wrong.

By passing True to the basic_qos method, we are setting a global consumer prefetch count, which is shared by all consumers on a channel when using RabbitMQ. https://www.rabbitmq.com/docs/consumer-prefetch#sharing-the-limit

https://github.com/MetPX/sarracenia/blob/e90cd7625dac5ae02358a68a9f8daac670f8a207/sarracenia/moth/amqp.py#L351-L352

This means that the prefetch count for each individual consumer shows up as 0 in the GUI, but if you look at the channel, you will see that the global prefetch count is whatever value you configured in sr3.

Since we only have one consumer per channel, I'm not sure if this matters.

The document linked explains that if you have 2 consumers on the same channel, each with a prefetch count of 20, but a global prefetch count of 25, the total maximum number of un-acked messages across the 2 consumers is 25 (i.e. less than the total of 40).

It does not explain what happens if you only set a global limit and leave the per-consumer limit at 0. I'm wondering if this means that the actual effective prefetch count might be 0 for each consumer...

Setting per-consumer limits by changing the True to False would at least be more informative to people looking at the RabbitMQ GUI.

reidsunderland commented 5 days ago

I don't think there's a practical difference in our use case. With the current settings, where the global prefetch count for the channel is set to XX and the per-consumer prefetch count is set to 0, the queue still has 25 unacked messages at a time, indicating that it's working.

This is the difference when looking at the queue. The existing code shows prefetch 0:

image

reidsunderland commented 5 days ago

While reading about quorum queues, I coincidentally noticed that global QoS (prefetch counts) are not supported for Quorum Queues. So for future proofing, we probably should change our code to set per-consumer QoS.

https://www.rabbitmq.com/blog/2023/03/02/quorum-queues-migration#global-qos-for-consumers