This repository has been archived by the owner on Mar 10, 2020. It is now read-only.
AMQPLib: Allow queue and durability to be part of the configuration #182
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why?
In AMQP mode, Ascoltatori creates a queue using an
asc_${uuid()}
as the name every time it is initialized. Also, it checks to ensure that the queue is not durable.What is the problem?
The new queue(s) are not bound to an exchange, or a routing key - since that is not part of the standard configuration. Which means, in turn, that the Administrators have to do something to ensure that each new queue is bound to an exchange with a routing key. In large scale systems, this is obviously not an option.
What does this PR do?
Very simply, it allows for the name and durability of the queue to be specified as part of the configuration for AMQPLib.
Benefits
RabbitMQ Administrators can now ask the DevOps folks to use a specific queue as part of the deployment process.
So, for example, if there is a cluster of servers that use a specific Exchange / Queue combination for receiving logs, audit trails, etc., they will all use the same queue with the same routing key. This allows for round-robin message dispatch by a "topic" exchange - essentially, a load-balanced use-case.