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

[Steven Taylor]

I notice in the examples for BasicPublish that sometimes for the
IBasicProperties parameter ch.CreateBasicProperties() is used, and sometimes
null is passed in.

What is the benefit in using the ch.CreateBasicProperties() approach?

thanks,
-Steven

On 11 December 2010 06:55, Steven Taylor <taylste at gmail.com> wrote:

> 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/bb22d995/attachment.htm>