<div dir="ltr">Hi Simon -<div><br></div><div>That was a wealth of information. I was trying to add this to one of your blogs which would benefit all the readers but I couldnt find a relevant topic. I will see where I can publish this information so it will be useful for everyone.</div>
<div><br></div><div>Regarding this discussion -</div><div><br></div><div>>�<span style="font-family:arial,sans-serif;font-size:13px">setting basic.qos (which causes message delivery [queue] -> [consuming channel] to be synchronous inside the cluster).</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">what if the RabbitMQ client defines the channel as used only for Consuming or Publishing or both publishing and consuming. I do not know if there is a provision in AMQP or RabbitMQ can customize that.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">When a channel from a (RabbitMQ client) consumer is defined as consumer only, then there is no effect of this channel (connected from RabbitMQ client to slave node queue), because replicated queues can only be consumed from Master node. Will this provide async consumer replication?</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Thanks!</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Feb 13, 2014 at 10:07 AM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com" target="_blank">simon@rabbitmq.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On 13/02/2014 17:07, Arun Rao wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thank you so much, Simon, as always!<br>
<br>
I learnt from the documentation that queues are single threaded<br>
resource. What does this mean to delivering and acknowledging messages?<br>
If prefetch_count=10.<br>
</blockquote>
<br></div>
Queues are single processes, but they don't get involved with any of the work of communicating AMQP, they just accept and dole out messages to channel processes (possibly not on the same node) which do that.<div class="">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cross cluster traffic are they asynchronous?<br>
</blockquote>
<br></div>
The general pattern is: if something is asynchronous in AMQP, then any cross-cluster traffic associated with it is also asynchronous. So publishing a messsage across a cluster is asynchronous, but starting a consumer up with basic.consume is not.<br>

<br>
However, there are a couple of exceptions to that: publishing with mandatory=true (which is synchronous for [publishing channel] -> [queue] inside the cluster) and setting basic.qos (which causes message delivery [queue] -> [consuming channel] to be synchronous inside the cluster).<br>

<br>
So both of these can have nasty performance in clusters.<br>
<br>
With regard to mandatory publishing, it's just that way for historical reasons, and it will become async in 3.3.0 anyway.<br>
<br>
With regard to delivery when basic.qos is set, this is a painful one. As I said in the previous mail, turning on basic.qos means that the prefetch count is associated with the channel and hence could be shared between multiple queues. That means that each queue needs to synchronously check with the channel each time it wants to deliver a message, to see if some other queue has used up the prefetch count. It can't just keep a counter.<br>

<br>
We're exploring ways to improve this situation in 3.3.x; one option which we already have working is to provide a per-consumer prefetch option separate from basic.qos; another is to optimise the common case when basic.qos is used with a single consumer (although the transitions are a bit painful there).<br>

<br>
Cheers, Simon<br>
<br>
</blockquote></div><br></div>