<div>I notice in the examples for BasicPublish that sometimes for the IBasicProperties parameter ch.CreateBasicProperties() is used, and sometimes null is passed in. </div>
<div> </div>
<div>What is the benefit in using the ch.CreateBasicProperties() approach?</div>
<div> </div>
<div>thanks,</div>
<div>-Steven<br><br></div>
<div class="gmail_quote">On 11 December 2010 06:55, Steven Taylor <span dir="ltr"><<a href="mailto:taylste@gmail.com">taylste@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div>Hi Jerry,</div>
<div> </div>
<div>thanks fo the links, especially the <a href="http://www.rabbitmq.com/extensions.html" target="_blank">http://www.rabbitmq.com/extensions.html</a> one.</div>
<div> </div>
<div>this is what I pre supposed and wondered about with my "-ish" comments:</div>
<div> </div>
<div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div>"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."</div>
</blockquote>
<div> </div></div>
<div>
<div>This little phrase from you is an important one for me:</div>
<div> </div></div>
<div class="im">
<div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">"(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.)"<br>
</blockquote></div>
<div> </div></div>
<div>thanks,</div>
<div>-Steven</div>
<div>
<div></div>
<div class="h5">
<div> </div>
<div> </div>
<div class="gmail_quote">On 10 December 2010 21:11, Jerry Kuch <span dir="ltr"><<a href="mailto:jerryk@vmware.com" target="_blank">jerryk@vmware.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">Hi, Steven:<br><br>The doc for the Java client's method is here:<br><br><a href="http://www.rabbitmq.com/javadoc/com/rabbitmq/client/impl/AMQImpl.Exchange.Bind.html" target="_blank">http://www.rabbitmq.com/javadoc/com/rabbitmq/client/impl/AMQImpl.Exchange.Bind.html</a><br>
<br>The ideas behind it are captured here:<br><br><a href="http://www.rabbitmq.com/extensions.html" target="_blank">http://www.rabbitmq.com/extensions.html</a><br><br>The 'exchange.bind' method is used to bind one exchange to another exchange, with behavior akin to how an exchange-queue binding works.<br>
<br>Using this you can create more elaborate or hierarchical routing topologies within your broker.<br><br>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.<br>
<br>(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.)<br>
<br>Best regards,<br><font color="#888888">Jerry<br></font>
<div><br>On Dec 10, 2010, at 12:31 PM, Steven Taylor wrote:<br><br>is there any information available on ExchangeBind()? Looks similar to QueueBind.<br><br>-Steven<br><br></div>
<div>On 10 December 2010 20:29, Steven Taylor <<a href="mailto:taylste@gmail.com" target="_blank">taylste@gmail.com</a><mailto:<a href="mailto:taylste@gmail.com" target="_blank">taylste@gmail.com</a>>> wrote:<br>
Just notice an ExchangeBind(...) function.<br><br>So is it better to cluster similar ideas by exchange or with routing keys? Previously I was clustering similar ideas by exchange.<br><br>thanks,<br>-Steven<br><br></div>
<div>
<div></div>
<div>On 10 December 2010 19:44, Jerry Kuch <<a href="mailto:jerryk@vmware.com" target="_blank">jerryk@vmware.com</a><mailto:<a href="mailto:jerryk@vmware.com" target="_blank">jerryk@vmware.com</a>>> wrote:<br>
<br>On Dec 10, 2010, at 11:21 AM, Steven Taylor wrote:<br><br>> 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.<br>><br>> I'm using the C# .Net client at the moment (might like to add another language client or two in future).<br>
<br>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.<br><br>> 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.<br>
<br>I believe more of those are going to be forthcoming, so, as they say, "watch that space."<br><br>> 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.<br>
<br>Absolutely. We're happy to help.<br><br>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.<br>
<br>Also there's an upcoming book on Rabbit that you might find useful:<br><br><a href="http://www.manning.com/videla/" target="_blank">http://www.manning.com/videla/</a><br><br>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.<br>
<br>Jerry<br><br><br><br><br></div></div></blockquote></div><br></div></div></blockquote></div><br>