<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>