<div dir="ltr">So we're doing some active investigation regarding connection resets in Rabbit connections. It turns out that the F5 load balancers we use have been configured with a tcp idle timeout at 300 seconds, causing connection reset warnings every 5 minutes for our connections to the rabbit boxes. The F5 load balancers act as a proxy, not a router/gateway on TCP/IP connections and so have some pretty specific timeouts and rules. The question comes in has anyone else been using F5 boxes to virtualize their connections to a Rabbit cluster, and if so what settings do you use including monitors/resets/etc.? From what I've been told, most network devices drop TCP/IP connections after an hour automatically (i.e. switches, routers, etc.) and force a reconnect - not sure if Rabbit handles this?<div>
<br></div><div>There is a work around at the moment we're looking into. It looks like most (if not all) Rabbit interfaces have a heartbeat setting that would allow connections to be maintained with that reset still on, but that means setting every client and server would need to be configured with a heartbeat to generate at least some traffic. I'd have figured if nothing else there would have been some messages going back and forth between a client and server, if nothing else to say "Still no new messages - no one loves you." </div>
<div><br></div><div style>Other questions related to the above: Is the AMQP protocol designed to have the clients just sit idle, no communication with the servers until a message comes in (which from TCP Dumps appears to be what's happening though perhaps I've not waited long enough)? How long would they sit idle by default before asking "hey, server, you still alive and connected to me?" If there is no check, and the client hasn't received a message in a day at what point do you retry your connection to verify you're even still connected? It sounds like in this case you could have a consumer of a queue lose it's connection and never realize that it's lost, because it's just sitting idle waiting for responses. Then you'd have a server just sitting backlogging messages waiting for a client (or worse depending on configuration, just dropping all the messages).</div>
<div style><br></div><div style>Just trying to get a low level idea of how the TCP/IP communications work between clients and the rabbit servers and configuration ideas and how to setup load balancers to work with Rabbit. Looked at the AMQP 0-9-1 specifications and not seeing a whole lot defined on how AMQP implementers are supposed to work with TCP/IP traffic (other than some heartbeat definitions).</div>
<div style><br></div><div style>Thanks!<br>Jason</div></div>