<div dir="ltr">Tim,<div><br></div><div>With regard to your comment:<br><br>"<span style="font-family:arial,sans-serif;font-size:13px">Ok, but you do realise that a single queue will reside on only one node, and therefore messages sent to other nodes in the cluster will still have to be routed/forwarded to the node on which the queue resides?"</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><font face="arial, sans-serif">We are using highly available queues, so this wouldn't be the case (right?). I understand that there is intra-node communication required to support this.</font></div>
<div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">Regards,</font></div><div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">Richard</font></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Mar 16, 2013 at 8:27 AM, Tim Watson <span dir="ltr"><<a href="mailto:tim@rabbitmq.com" target="_blank">tim@rabbitmq.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Richard,<br>
<div class="im"><br>
On 15 Mar 2013, at 20:04, Richard Raseley wrote:<br>
> The intent is to abstract all production and consumption operations via the VIP (which itself is mapped to a pool which contains all of our RabbitMQ nodes) so that there is a single configured endpoint. With regard to load balancing, it will load balance across the nodes so that if (for example) 10 producer instances opened up 10 channels to the VIP, 5 would have one node as an endpoint and 5 would have the other (assuming a 2 node cluster and round-robin configuration).<br>
><br>
<br>
</div>Ok, but you do realise that a single queue will reside on only one node, and therefore messages sent to other nodes in the cluster will still have to be routed/forwarded to the node on which the queue resides?<br>
<div class="im"><br>
> I understand that any timeout settings would have to be tuned for the application, but I was looking for some high level general guidelines (e.g. "in situation x, consider y and z"). We've ensured that our timeout is greater than the heartbeat interval.<br>
><br>
<br>
</div>I think heartbeats are the main (general) thing to be considered. Perhaps other users who're more familiar with production configurations such as these will have more to add though.<br>
<br>
Cheers,<br>
Tim<br>
<div class="HOEnZb"><div class="h5"><br>
> Regards,<br>
><br>
> Richard<br>
><br>
><br>
> On Fri, Mar 15, 2013 at 3:46 AM, Tim Watson <<a href="mailto:tim@rabbitmq.com">tim@rabbitmq.com</a>> wrote:<br>
> Hi Richard,<br>
><br>
> On 11 Mar 2013, at 20:55, Richard Raseley wrote:<br>
> > Is anyone able to share some "best practices" as it relates to using a F5 load balancer to distribute load between nodes of a RabbitMQ cluster?<br>
> ><br>
><br>
> Can you explain a bit more clearly what you're trying to achieve please? Using a load balancer to maintain connectivity to a cluster is recommended and quite common, but that isn't going to 'distribute load between nodes' per se. Are you trying to distribute the load of publishing over multiple nodes, or consuming, or what? There are various things to consider depending on your goals.<br>
><br>
> > I am most interested in the persistence and timeout settings which we should be using in conjunction with RabbitMQ.<br>
> ><br>
><br>
> There cannot be any specific settings that will work for all deployments - this will be application specific I would've thought. The only advice that springs to mind is if you are setting AMQP heartbeats on your connections, then make sure the proxy timeout is aligned with (i.e., greater than) these to avoid disturbing connections unnecessarily - but that's pretty obvious.<br>
><br>
> Cheers,<br>
> Tim<br>
> _______________________________________________<br>
> rabbitmq-discuss mailing list<br>
> <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
> <a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><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="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><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="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</div></div></blockquote></div><br></div>