Quorum Queue Priorities

[Dominic Morneau]

Hi!

I saw that priorities are not planned for quorum queues, and multiple queues should be used instead. I was wondering how to implement this in practice.

In our case we have tasks that take up to ~1hr to process, and must be done one at a time by the workers (they use a lot of storage).

If we consume from both a high priority queue and normal priority queue with prefetch=1, it's possible we receive two messages at a time. We can't hold on to the normal priority message, because it would be really bad to block it for up to 1hr while another worker may have become available a minute later. That leaves us with either doing a nack, or requeuing it, and neither option looks great: with nack the messages risk hitting x-delivery-limit, and with requeue we lose FIFO ordering.

I'm thinking a workaround might be to delay subscribing to the normal priority queue by 1-2s, to make sure no high priority message arrives first, such that nacks are still possible but unlikely.

Any other ideas?

Thanks,

Dominic Morneau

[Luke Bakken]

message, because it would be really bad to block it for up to 1hr while another worker may have become available a minute later. That leaves us with either doing a nack, or requeuing it, and neither option looks great: with nack the messages risk hitting x-delivery-limit, and with requeue we lose FIFO ordering.

You can indicate that the message should be re-queued when basic.nack is used -

https://www.rabbitmq.com/nack.html#usage

https://www.rabbitmq.com/amqp-0-9-1-reference.html#basic.nack

Use real-world testing to find an ideal delivery limit, and ensure a dead-letter exchange is configured.

Thanks,

Luke

[kjnilsson]

In this case you could unsubscribe from low priority messages when you receive a high priority message and resubscribe when you are finished.

If you have more infrastructure control you could simply deploy more and more powerful consuming application to process the high priority queues and leave

smaller / cheaper consumer to go through the low priority work. If you find that the low priority queue is backing up you could configure a message ttl policy (to come in 3.10/3.11) to move low priority messages to the high priority queues if they have waited too long to be processed.

With multiple queues you have many options but yes they aren't all quite as intuitive as a single priority queue.

Cheers

Karl