Thanks for the suggestions guys..<br><br>Let me see if i can re-architect it the way u mentioned..<br><br>Regard<br>-Arun<br><br><div class="gmail_quote">On Sun, Feb 21, 2010 at 6:20 PM, Matthew Sackman <span dir="ltr"><<a href="mailto:matthew@lshift.net">matthew@lshift.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">On Sun, Feb 21, 2010 at 12:11:17PM +0000, Matthias Radestock wrote:<br>
> In that case simply make the queues non-durable and the messages<br>
> non-persistent. That way when R1 goes down the queue well and truly<br>
> disappears and you can re-create it on another node, i.e. your existing<br>
> logic would work just fine.<br>
<br>
</div>Yup. I was going to suggest not using a cluster, then having both<br>
consumers create the queues and subscribe on *both* nodes. Then you<br>
could stick a load balancer or just have a smart producer - provided<br>
the producer can send a message to one of the two nodes, that message<br>
well get to one of the clients. This seems to be more what you're<br>
after - HA rather than scalability.<br>
<div><div></div><div class="h5"><br>
Matthew<br>
<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</div></div></blockquote></div><br>