[rabbitmq-discuss] routing key advice + QueueBind(...)

[Jerry Kuch]

Hi, Steven:

The doc for the Java client's method is here:

http://www.rabbitmq.com/javadoc/com/rabbitmq/client/impl/AMQImpl.Exchange.Bind.html

The ideas behind it are captured here:

http://www.rabbitmq.com/extensions.html

The 'exchange.bind' method is used to bind one exchange to another exchange, with behavior akin to how an exchange-queue binding works.

Using this you can create more elaborate or hierarchical routing topologies within your broker.

We've also implemented but not yet released "internal exchanges," as per the AMQP spec, which are exchanges that can only be used "on the inside" in these exchange-to-exchange scenarios (i.e. an external client can't publish to them).  Thus, internal exchanges can of codify and protect their role as internal routing plumbing and not let clients leak messages into your routing setup in unexpected ways.  Internal exchanges ought to debut in a relatively soon to come release, but I don't know precisely when.

(In case you've already thought to worry, cycle eliminations and message de-duplications are taken care of by the broker, for both exchange and queue bindings, so you don't have to worry about a topological misstep creating perpetual messaging machines, ending up with unexpected duplicate deliveries, etc.)

Best regards,
Jerry

On Dec 10, 2010, at 12:31 PM, Steven Taylor wrote:

is there any information available on ExchangeBind()?  Looks similar to QueueBind.

-Steven

On 10 December 2010 20:29, Steven Taylor <taylste at gmail.com<mailto:taylste at gmail.com>> wrote:
Just notice an ExchangeBind(...) function.

So is it better to cluster similar ideas by exchange or with routing keys?  Previously I was clustering similar ideas by exchange.

thanks,
-Steven

On 10 December 2010 19:44, Jerry Kuch <jerryk at vmware.com<mailto:jerryk at vmware.com>> wrote:

On Dec 10, 2010, at 11:21 AM, Steven Taylor wrote:

> thanks for the reply.  That's good news on the multiple bindings.  The more that I get to know RabbitMQ, the more I like it.
>
> I'm using the C# .Net client at the moment (might like to add another language client or two in future).

I don't know that client very well myself, but poking around in its source code it has enough similarities to the Java one that the latter might still be somewhat instructive in cases.

>  I had found the api guide, and faq.  I haven't explored the java library yet. I looked at  + played with the .net examples: declareQueue, perf test, subscriber, etc.  I also looked at a bunch of the presentations such as the one that Alexis did at Google. BTW: the getting started guide with the python/java examples is quite good.

I believe more of those are going to be forthcoming, so, as they say, "watch that space."

>  I'm at the stage where I need to solve specific problems / issues + choose an optimum exchange / routing setups. I'm sure you've been there yourself i.e. high level pretty good. Low level -- like that example was easy, I can see how that worked, but still stumbling around a little bit in the code for my stuff type of thing. Getting there. If you guys can help me put my hands on some of these specifics I'd appreciate that.

Absolutely.  We're happy to help.

Filling in the gap between the high level structure and the details of the implementation with best practices and the locally tasteful idioms takes a bit of time, but, in general Rabbit, its code, and its documentation reward study.  The team and community are generally active and interested in helping out newcomers to the community.

Also there's an upcoming book on Rabbit that you might find useful:

http://www.manning.com/videla/

The first couple of chapters are available from the publisher in an early-access/preview edition.  It looks like it will fill an important niche in the Rabbit ecosystem as it comes together.

Jerry