Hi Willy,
On 10/08/2011 09:16 AM, Willy Tarreau wrote:
Hi Alex,
On Sun, Oct 02, 2011 at 06:48:08PM +0200, Piavlo wrote:
Hi,
I noticed that both for tcp and http connections then client/server
timeout is reached and haproxy tears the connection - the client side
socket is CLOSE_WAIT.
Is there a clean way to make haproxy tear the connection to the client.
A CLOSE_WAIT on a machine means that a FIN was received from the remote
end on the TCP connection and that it was not yet processed by the
application (haproxy if you're seeing this on this machine).
The only situation I see where you can have CLOSE_WAIT sockets is when
a client actively disconnects from haproxy before getting a response.
Haproxy will then wait for the response (or timeout) to come and send
it to the client. During this time, the connection is in CLOSE_WAIT.
I don't know if this is what you observed, but you should never have
this when haproxy detects a timeout, because its closes the connection
itself, so by definition it cannot be in CLOSE_WAIT.
Perhaps I was not clear enough - the CLOSE_WAIT is not in the haproxy
client side connection - but in the client app itself which connects to
the server through haproxy. I'm seeing this both then client/server are
mysql-client/mysql-server or then client/server are
rsyslog-client/rsyslog-server. Once there is haproxy server or client
timeout due to inactivity - and haproxy closes the connection I see
CLOSE_WAIT on the client app socket for a very long time - if not forever.
So haproxy is the one that closes the connection. I never see CLOSE_WAIT
then there is no haproxy in the middle.
The question is why in both cases the client side apps would not process
the CLOSE_WAIT then FIN triggered by haproxy?
Thanks
Alex
Regards,
Willy
