<div dir="ltr"><div>I saw that heartbeats are turned on with 3.0.0 - the question is does 2.8.7 have heartbeat support by default on the server side or can it be turned on? �How is this different the SO_KEEPALIVE:</div><div>
<a href="http://www.erlang.org/doc/man/inet.html">http://www.erlang.org/doc/man/inet.html</a></div><div><br></div><div>�There's no details on the documentation about configuring the heartbeat on 2.8.7 setting if there is a configuration option for it. �I did find this:<br>
</div><div><a href="https://bugs.launchpad.net/nova/+bug/856764">https://bugs.launchpad.net/nova/+bug/856764</a><br></div><div style>AND</div><div style><a href="http://rabbitmq.1065348.n5.nabble.com/Timeout-for-hung-connection-on-rabbitmq-server-td21354.html">http://rabbitmq.1065348.n5.nabble.com/Timeout-for-hung-connection-on-rabbitmq-server-td21354.html</a><br>
</div><div style>I'm not sure what the difference is between a rabbit heartbeat and erlangs keepalive? �Or is heartbeat just turning on keepalive? �I'm going to look at the erlang configuration as a possible fix. �We're trying to do this on the server side so we don't have to modify all of our clients.</div>
<div style><br></div><div style>Here's a few more details on the exact issue we've encountered<br>RAB_SERVER <-> F5/Firewall/etc. <-> RAB_CLIENT</div><div style>the client and server don't have any traffic going through so they get disconnected in one of two ways. �If we used just a router and not a load balancer it seems most network firewalls auto disconnect with NO notification both clients after an hour of no TCP/IP traffic (from what I understand, SSH for example uses a TCP/IP Keepalive to keep their connections going). �The load balancer on the other hand does a graceful RESET to both client and server after our delay of 300 seconds. �We've tried increasing the delay, but it looks like 2.8.7 by default doesn't set any kind of heartbeat or keepalive so even if we set it to an hour, we'd still get resets.</div>
<div><br></div>Rabbit clients using spring & the shovel configuration itself handle resets of the connection pretty gracefully. �The issue is I'd rather not have resets as I don't trust all clients to be nice about reconnecting. �The spring code reconnects gracefully - the standard rabbit client doesn't seem to be as nice about reconnecting.<div>
<br></div><div>Jason<br><div>
<br></div><div><br><div>
<br></div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 18, 2012 at 6:52 AM, Emile Joubert <span dir="ltr"><<a href="mailto:emile@rabbitmq.com" target="_blank">emile@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Jason,<br>
<div class="im"><br>
On 17/12/12 22:53, Jason McIntosh wrote:<br>
<br>
> From what I've been told, most network devices drop TCP/IP<br>
> connections after an hour automatically (i.e. switches, routers,<br>
> etc.) and force a reconnect - not sure if Rabbit handles this?<br>
<br>
</div>The broker handles a closed connection by logging the event.<br>
<div class="im"><br>
> There is a work around at the moment we're looking into. �It looks like<br>
> most (if not all) Rabbit interfaces have a heartbeat setting that would<br>
> allow connections to be maintained<br>
<br>
</div>Yes, AMQP heartbeats are a suitable solution if intermediate network<br>
devices are closing idle connections too eagerly. Heartbeats are enabled<br>
by default in v3.0.0 if the client supports them.<br>
<br>
Another options is to write client applications to re-establish closed<br>
connections after a suitable delay.<br>
<br>
If consumers receive messages asynchronously instead of polling the<br>
broker for messages, and there are no messages to deliver then the TCP<br>
connection will carry no traffic.<br>
<div class="im"><br>
> Other questions related to the above: �Is the AMQP protocol designed to<br>
> have the clients just sit idle, no communication with the servers until<br>
> a message comes in<br>
<br>
</div>Rabbit does not impose limits on connection duration and idle<br>
connections are permitted to remain so indefinitely.<br>
<div class="im"><br>
> If there is no check, and the client hasn't received a message in a<br>
> day at what point do you retry your connection to verify you're even<br>
> still connected? It sounds like in this case you could have a<br>
> consumer of a queue lose it's connection and never realize<br>
<br>
</div>If connections are being severed silently without notification from the<br>
network stack then you must use AMQP heartbeats so that both sides of<br>
the connection become aware of it. Otherwise the network stack should<br>
provide notification that the connection has been interrupted.<br>
<div class="im"><br>
> Then you'd have a server just sitting backlogging messages waiting<br>
> for a client (or worse depending on configuration, just dropping all<br>
> the messages).<br>
<br>
</div>The broker will not drop messages due to broken connections and the<br>
protocol is designed so that a guarantee of message delivery can be<br>
offered even in the face of an unreliable transport.<br>
<div class="im"><br>
> Looked at the AMQP 0-9-1 specifications and not seeing a whole lot<br>
> defined on how AMQP implementers are supposed to work with TCP/IP<br>
> traffic (other than some heartbeat definitions).<br>
<br>
</div>The "connection" class relates to the transport, which must be<br>
stream-oriented.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
-Emile<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Jason McIntosh<br><a href="http://mcintosh.poetshome.com/blog/">http://mcintosh.poetshome.com/blog/</a><br>573-424-7612
</div></div>