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

Sat Dec 11 06:55:52 GMT 2010

Hi Jerry,

thanks fo the links, especially the http://www.rabbitmq.com/extensions.html
 one.

this is what I pre supposed and wondered about with my "-ish" comments:

> "The binding is semantically identical to exchange-to-queue bindings:
> unidirectional, binding keys and exchange types operate as normal, but both
> endpoints (the source and destination) of the binding are exchanges."
>

 This little phrase from you is an important one for me:

> "(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.)"
>

thanks,
-Steven

On 10 December 2010 21:11, Jerry Kuch <jerryk at vmware.com> wrote:

> 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20101211/b48a0fbf/attachment-0001.htm>