Skip to content
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

Open
gottfrois opened this issue May 3, 2016 · 8 comments
Open

Allow to set exchange per consumer #221

gottfrois opened this issue May 3, 2016 · 8 comments

Comments

@gottfrois
Copy link
Contributor

gottfrois commented May 3, 2016

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:

class FooConsumer
  include Hutch::Consumer

  exchange "another_exchange"
  routing_key "foo.bar"
end

It would take by default the exchange defined in the global configuration if not specified in the consumer.

@michaelklishin
Copy link
Member

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?

@gottfrois
Copy link
Contributor Author

gottfrois commented May 3, 2016

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.

@michaelklishin
Copy link
Member

How would using a separate exchange then work with Hutch.publish? Overriding exchanges in my opinion badly breaks the original Hutch model.

@michaelklishin
Copy link
Member

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.

@gottfrois
Copy link
Contributor Author

I would agree to introducing a way to bind consumer's queue to more exchanges (e.g. an array of names).

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?

@michaelklishin
Copy link
Member

It will be for things that are published outside of Hutch (such as dead lettering).

@naveedkakal
Copy link

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?

@tlloydthwaites
Copy link
Contributor

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:

consume 'deadletter'
queue_name 'deadletter'

You can find the original routing key in the message properties, eg:

original_routing_key = message.properties[:headers]["x-death"][0]["routing-keys"][0]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants