Don't create AMQP exchange if not configured #3647
Conversation
hanej
changed the title
|
If I understand this correctly, the user would now need to define the exchange and the queue, as well as bind them before using the plugin? |
|
That is correct |
|
We will need to find a way to provide what you need without breaking backwards compatibility, perhaps we could modify the code to skip the creation of the exchange if |
|
That works. I’ll give it a shot.
…On Jan 9, 2018, 3:10 PM -0500, Daniel Nelson ***@***.***>, wrote:
We will need to find a way to provide what you need without breaking backwards compatibility, perhaps we could modify the code to skip the creation of the exchange if exchange is unset and then declare the exchange and queue only if they do not exist?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
hanej
changed the title
|
The change has been committed. It works with and without the exchange configuration option. |
| ) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("Failed to bind a queue: %s", err) | ||
| err = ch.QueueBind( |
There was a problem hiding this comment.
I think we should always QueueBind, so that the binding key works even if no exchange/queue is created.
danielnelson
added
area/rabbitmq
feat
|
It seems to me that this pull request is a work around for the limited configurability of the exchange declaration in the amqp plugin, and if we improved that there wouldn't be a need to skip declaring the exchange. I'm adding more configuration option around the creation of exchanges in #4228 and #3785, please let me know if the new options are sufficient. |
|
Closing, assuming this is no longer required. One related pull request is #5831 which adds passive queue declaration as well. |
Required for all PRs:
Removed AMQP publisher specific code and documentation from the consumer plugin. This has been validated in our environment. Fixes #3646