<div dir="ltr">Matthias,<div><br></div><div>I am glad that you were able to anticipate where I was heading - that means I am not completely insane (at least as it relates to this). =]</div><div><br></div><div>Yes, I understand that they are actually two separate queues (I am treating them as one logical one for purposes of discussion). In this case the lack of order preservation and visibility from one cluster to the other isn't an issue for us. We decided not to go with two queues for the transparency reasons you mentioned. </div>
<div><br></div><div>Thanks so much for your time today.</div><div><br></div><div>Regards,</div><div><br></div><div>Richard<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 19, 2013 at 3:27 PM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@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="im">On 19/03/13 22:12, Richard Raseley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are four servers named rmq01, rmq02, rmq03, and rmq04. Servers<br>
rmq01 and rmq02 are clustered; servers rmq03 and rmq04 are clustered (so<br>
we now have 2x two node clusters).<br>
<br>
On both clusters we create a vhost named "default", a direct exchange<br>
named "default", a queue named "default", a user "default" (which has<br>
read, write and config access to the aforementioned objects) with a<br>
password of "default" and apply the ha-all mode to the "default" vhost.<br>
<br>
We place these two identically configured clusters inside of a load<br>
balanced pool with a "least queue depth" configuration. We then<br>
configure the consumers and producers associated with this app to<br>
connect to the VIP (which maps to the load balanced pool) to send<br>
messages to the "default" exchange and consume messages from the<br>
"default" queue.<br>
<br>
Assuming we have more producers and consumers than we do RabbitMQ nodes<br>
(and they get distributed properly), we've now increased our throughput<br>
- as we now have two master queue processes to work with on this<br>
"single" queue.<br>
</blockquote>
<br></div>
I thought that's where you were heading :)<br>
<br>
You really have two queues in the above. Message order is no longer preserved between messages ending up in different (real) queues. And consumers on one (real) queue will never see the messages published to the other. If that is ok in your use case then fine.<br>
<br>
You could get the same effect by just having two queues in the same cluster, though obviously that requires them to be named differently and hence is not transparent to clients.<span class="HOEnZb"><font color="#888888"><br>
<br>
Matthias.<br>
</font></span></blockquote></div><br></div></div></div>