On Wed, Jul 20, 2016 at 02:27:28PM -0600, Tim Butler wrote: > 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.
OK. > 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. Well, it's still difficult for me to get the detailed sequence here. Could you please try to run strace -tts200 -o log -p $pid on the haproxy process during a successful case and a failed one ? It should show whether or not something unexpected happens. Thanks, Willy
