Re: avoiding CLOSE_WAIT on client side after client/server timeout

  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
>
Received on 2011/10/08 13:52