<div dir="ltr">Tim,<div><br></div><div style>Thank you for that information - I hadn't realized that was the case with HA queues. So, in our situation we may be better off configuring the load balanced pool to be Active / Passive so that messages will always be flowing directly to the node that is running the master queue process (thereby eliminating the intra-node network overhead)?</div>
<div style><br></div><div style>Regards,</div><div style><br></div><div style>Richard</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 18, 2013 at 10:47 AM, Tim Watson <span dir="ltr"><<a href="mailto:watson.timothy@gmail.com" target="_blank">watson.timothy@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF"><div>Richard,<br></div><div><br>On 18 Mar 2013, at 16:55, Richard Raseley <<a href="mailto:richard@raseley.com" target="_blank">richard@raseley.com</a>> wrote:<br>
<br></div><div></div><blockquote type="cite"><div><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><font face="arial, sans-serif">We are using highly available queues, so this wouldn't be the case (right?).</font></div></div></div>
</blockquote><div><br></div><div>Even with HA the master queue process still resides on just one node an all messages will be sent to it.</div><div><br></div><div>Cheers,</div><div>Tim</div><br><blockquote type="cite"><div>
<div dir="ltr"><div><font face="arial, sans-serif"> I understand that there is intra-node communication required to support this.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Regards,</font></div><div><font face="arial, sans-serif"><br></font></div><div><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><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><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><div><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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>rabbitmq-discuss mailing list</span><br><span><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a></span><br>
<span><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></span><br></div></blockquote></div><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></blockquote></div><br></div>