Federated Exchange Upstream / Downstream Names

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Federated Exchange Upstream / Downstream Names

Chris-3
Hello,

I was wondering if someone could please advise me on the best approach to accomplish the following:

I essentially want to federate an exchange such that the "upstream" exchange name is different than the exchange name that the downstream queues bind to.

Maybe a use case would explain it better... 

Imagine Broker A, Broker B, and Broker C.  Each federates a  direct exchange based on their name (for example, "A.requests", "B.requests", "C.requests").  Within each broker, however, I don't want consumers to need to know the broker name-- they should be able to bind their queues to (direct) exchange "Incoming.requests" and receive messages to "A.requests", "B.requests", or "C.requests" respectively.

The best I can come up with is to actually make the federated exchanges be "fanout" exchanges, then within each broker, create the local "Incoming.requests" direct exchange, and use E2E bindings to bind the "Incoming.requests" to the federated exchange (for example "A.requests").

Is this how you would recommend it?  Does this defeat RabbitMQ's smart routing?  (will it cause all messages to be sent to the federated exchange since it is fanout, or will it be smart enough to consider the queue bindings on the E2E bound 'Incoming.requests' direct exchange?)

If I'm not making sense, feel free to ask me to clarify.

Thanks!
Chris

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Federated Exchange Upstream / Downstream Names

Michael Klishin

On oct 8, 2013, at 12:53 a.m., Chris <[hidden email]> wrote:

> Imagine Broker A, Broker B, and Broker C.  Each federates a  direct exchange based on their name (for example, "A.requests", "B.requests", "C.requests").  Within each broker, however, I don't want consumers to need to know the broker name-- they should be able to bind their queues to (direct) exchange "Incoming.requests" and receive messages to "A.requests", "B.requests", or "C.requests" respectively.

Have you considered using a topic exchange and bind as *.requests?
Granted, prefix wildcards are not very efficient but if you only have a few dozens of queues
bound you may even notice.

MK




_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

signature.asc (506 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Federated Exchange Upstream / Downstream Names

Simon MacMullen-2
In reply to this post by Chris-3
On 07/10/2013 21:53, Chris wrote:
> I essentially want to federate an exchange such that the "upstream"
> exchange name is different than the exchange name that the downstream
> queues bind to.

You can set an "exchange" property on an upstream or an upstream set,
which will override the name of the upstream exchange to connect to.
It'll likely mean you need to define one upstream per downstream exchange.

I see this is not explained terribly well in the documentation. Will fix.

<snip alternate approach>

> Is this how you would recommend it?

If I understand your use case, the approach above would be simpler.

> Does this defeat RabbitMQ's smart routing?

Yes it would. Federation only takes account of routing decisions made in
the federated exchange, not any exchanges using it as a source through
e2e bindings.

Cheers, Simon

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Federated Exchange Upstream / Downstream Names

Chris-3
In reply to this post by Michael Klishin
Hi Michael,

I'm sorry-- I'm not sure I follow.  

If I did use a topic exchange, and all brokers federated that same exchange, then senders could specify the 'A', 'B', or 'C' in the routing key, but... the consumers in 'A', 'B', and 'C' would still need to know where they are ('A', 'B', or 'C') in order to bind their queue on the right key.  Binding on '*.requests' would give them all traffic.

On the other hand, if each broker federated a *different* topic exchange, then we're back in the original situation-- now binding on '*.requests' would work, but the consumers would need to know where they are to bind their queue to the right exchange.

Maybe I'm misunderstanding?

-Chris


On Mon, Oct 7, 2013 at 11:16 PM, Michael Klishin <[hidden email]> wrote:

On oct 8, 2013, at 12:53 a.m., Chris <[hidden email]> wrote:

> Imagine Broker A, Broker B, and Broker C.  Each federates a  direct exchange based on their name (for example, "A.requests", "B.requests", "C.requests").  Within each broker, however, I don't want consumers to need to know the broker name-- they should be able to bind their queues to (direct) exchange "Incoming.requests" and receive messages to "A.requests", "B.requests", or "C.requests" respectively.

Have you considered using a topic exchange and bind as *.requests?
Granted, prefix wildcards are not very efficient but if you only have a few dozens of queues
bound you may even notice.

MK




_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss



_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Federated Exchange Upstream / Downstream Names

Chris-3
In reply to this post by Simon MacMullen-2
Hi Simon,

Ah!  I didn't notice that bit about upstream sets, but now that you mention it, I can see what you mean...  I'll look into that.  I'm a little concerned about my other approach since it would create more traffic than necessary.  In the end, maybe I will just need to make a way for consumers to dynamically determine their broker's dedicated exchange names.  But first I'll look further into the upstream sets!

Thanks,
Chris


On Tue, Oct 8, 2013 at 4:41 AM, Simon MacMullen <[hidden email]> wrote:
On 07/10/2013 21:53, Chris wrote:
I essentially want to federate an exchange such that the "upstream"
exchange name is different than the exchange name that the downstream
queues bind to.

You can set an "exchange" property on an upstream or an upstream set, which will override the name of the upstream exchange to connect to. It'll likely mean you need to define one upstream per downstream exchange.

I see this is not explained terribly well in the documentation. Will fix.

<snip alternate approach>


Is this how you would recommend it?

If I understand your use case, the approach above would be simpler.


Does this defeat RabbitMQ's smart routing?

Yes it would. Federation only takes account of routing decisions made in the federated exchange, not any exchanges using it as a source through e2e bindings.

Cheers, Simon



_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss