Hi Willy, First of all thanks for your time and your quick reply. This is my first dive into the code, so that is why the lack of polling seemed suspicious. I see the cached events no to avoid polling.
I applied both the 'timeout server-fin' and 'tcp-ut' changes with no affect. > The fact that you're working in TCP mode makes me think you're relying on > long timeouts, yes. > and if the server remains unreachable during this time, it > can have to wait for the timeout to expire. > ... > the new event 0x20 means "ready for write", "disabled for read". This > seems to mean for me that a close on read was received from the client and was > forwarded to the server side, and we're waiting for the server to close in turn > before forwarding this to the client. More than that, at the time the 2 client sessions reconnect, there are no server connections. The second set of traces I sent appear to show haproxy making multiple connection attempts to the server for the first reconnected client until the server connection succeeds. Then a server reconnect for the second session, but in the failure case the client is just hanging out "disabled for read". No data is read for the second session even though netstat shows a full recv buffer for the second socket and all sockets (client/haproxy/server) are in CONNECTED states. The clients connect to haproxy and then blast a bunch of data even though the haproxy server connections are still underway. Even if the clients closed after sending some data, wouldn't that data before the close make it to a server? In this case I'm not expecting the clients to close, but they could have a defect. -tim
