-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to set exchange per consumer #221
Comments
Let's first clarify the terminology here. You do not "subscribe to exchanges." You subscribe to queues, and bind them to exchanges. What are we trying to accomplish here and how it is suggested that we do it in the terms above? |
Thanks for the clarification :) I was setting up dead letter queues in order to re-route messages that caused ruby exceptions on their respective consumers. The idea behind is that if a message caused an exception, the consumer code probably needs to be fixed before it can try to process that message again. A basic requeue would just end-up in a redelivery loop right? From the documentation, we can bind dead letter queues to another exchange. While it's possible to bind it to the exchange Hutch uses, I was thinking being able to set exchange per consumer would give more flexibility. |
How would using a separate exchange then work with |
I would agree to introducing a way to bind consumer's queue to more exchanges (e.g. an array of names). Overriding exchange per consumer makes the whole model Hutch is built around confusing and inconsistent. |
Don't you end-up with the same question about on which exchange to publish the message on? Or are you willing to publish the message to all exchanges? |
It will be for things that are published outside of Hutch (such as dead lettering). |
Currently running into the same conundrum. The topology of our AMQP is already set and in use. I want to consume a variety of messages that are being published to various exchanges. Is our topology poorly designed? I didn't think using a god-exchange for everything feels right, but it seems thats what Hutch wants to work with? |
You can do this without multiple exchanges. First, when sending a message to the deadletter exchange, make sure that 'dead-letter-routing-key' is set to 'deadletter', rather than leaving the original routing key in place. Then, just bind a consumer to the 'deadletter' queue using:
You can find the original routing key in the message properties, eg:
|
Currently the worker use the main broker connection which define on which exchange to subscribe to. Would be nice if we could specify the exchange on a per consumer basis.
Something like this probably:
It would take by default the exchange defined in the global configuration if not specified in the consumer.
The text was updated successfully, but these errors were encountered: