Quorum Queues Length Limit

[maestro]

Hi team,

I've noticed a bit surprising length limit behaviour in quorum queues.

It seems like the effective length limit is `x-max-length + 1` when `x-overflow` is set to `reject-publish`.

The steps to reproduce the behaviour:
1. run a container from the official docker image `rabbitmq:3.12.2-management` (at least 3.8 and 3.11 versions would do as well)
2. log in to a management UI as a default user
3. add a new quorum queue with `x-max-length: 1` and `x-overflow: reject-publish` arguments
4. publish a message to the queue
5. publish one more message (success, 2 messages in the queue)
6. try to publish once again (failure, `rejected Unable to publish message. Check queue limits`)

Keeping in mind that the quorum queues need some time to notify the publishing channels about the limit reached I tried to wait a couple of minutes after the step 4 — the results were the same.

Publishing via amqp091-go client (using the single publishing channel for steps 4–5) gave the same result.

With `x-max-length: 2` it is possible to publish 3 messages. With `x-max-length: 3` it is possible to publish 4 messages etc. And it is possible to to publish 1 message with `x-max-length: 0`.

I've tried classic queues with the same settings and quorum queues with `x-overflow` set to `drop-head` — length limit worked as expected and the effective limit exactly matched the `x-max-length` value.

Is it something to be worked on or probably to be mentioned and highlighted in the docs on Quorum Queues?

[kjnilsson]

Hi,

The max length with reject-publish of a quorum queue isn't strictly enforced and can overshoot and when we implemented it we reused some code to do the calculation which resulted in the off by one behaviour. Given it isn't strict we didn't feel this was a massive issue and went for maintainability instead of apparent correctness. We did not envisage limits to be set very low. Perhaps 100k or more. At that point correctness matter less.

Does it stop you from achieving something?

Cheers

Karl

[maestro]

Hi Karl, thanks for the details.

The behaviour has no impact on my team's projects at the moment. We've got rid of the only (and quite questionable) use case that relied on the exact low max-length value.

It's the behaviour itself that seemed to me a bit non-obvious and potentially confusing to the other users as well, so I decided to share the info with the team and the community.

Probably the docs could be updated in some way, e.g. by mentioning this specific case or adding some general precautions on the low max-length values?

I've also noticed that some examples on the https://www.rabbitmq.com/maxlength.html page contain pretty low max-length values, such as `"^two-messages$" '{"max-length":2,"overflow":"reject-publish"}'` policy (that appears to effectively be `three-messages` for a quorum queue =)

Cheers,
Eugene

[kjnilsson]

Yes it should probably be documented (although may change in future).

Feel free to submit a PR to https://github.com/rabbitmq/rabbitmq-website (to the live branch).

[maestro]

Ok, PR #1707 has been merged