Update the queue configuration
nico3dfx opened this issue · 2 comments
Hi,
I have an environment with N queues inside RabbitMQ.
All those queues don't have the "deadLetterRoutingKey" option and now I need it.
So with a new rascal configuration I added this option: "assert" is true and "check" is also true but when I start the application I have this message:
Error: Operation failed: QueueDeclare; 406 (PRECONDITION-FAILED) with message "PRECONDITION_FAILED - inequivalent arg 'x-dead-letter-routing-key' for queue 'my_service' in vhost '/': received the value 'service.dlq' of type 'longstr' but current is none"
Is there a way to "update" the queues opitions?
Nico.
Hi @nico3dfx,
No, unfortunately not. This is a limitation of RabbitMQ. You cannot redefine a queue or exchange. For queues you need to do something like...
Option 1 (keep the existing queue name)
- Stop all messages from being published to the queue
- Allow the queue to drain
- Stop consuming from the queue
- Delete the queue
- Recreate the queue
- Reapply the bindings
- Start consuming from the queue again
- Allow messages to be published again
Option 2 (use a different queue name)
- Create a new queue
- Consume from the old and new queue, tolerating duplicates
- Start publishing to the new queue
- Stop publishing to the old queue
- Wait for the old queue to drain
- Stop consuming from the old queue
- Delete the old queue
There are other options too - for example, you can define a shovel to copy messages from one queue to another, or you could maybe daisy chain queues together where the end queue had the dead letter routing configuration etc, but I'm not aware of any painless options unfortunately.
Something else you might consider in too, In RabbitMQ I believe you can define policies based on queue / exchange name. So for example, if you had a standard that said all work queues begin with the word "w_", and all dead letter queues begin with the "d_", you could apply default configuration to those queues and reduce the chance of forgetting important configuration and having to migrate again in future.
If doing it in RabbitMQ isn't an option, you could write a wrapper module for your Rascal configuration which did something similar.