|
From: | Santos Das |
Subject: | Re: [libmicrohttpd] Sockets remain in CLOSE_WAIT state |
Date: | Sat, 5 Jan 2019 19:45:16 +0530 |
CLOSE_WAIT
Indicates that the server has received the first FIN signal from the client and the connection is in the process of being closed
So this essentially means that his is a state where socket is waiting for the application to execute close()
A socket can be in CLOSE_WAIT state indefinitely until the application closes it.
Faulty scenarios would be like filedescriptor leak, server not being execute close() on socket leading to pile up of close_wait sockets
On 1/5/19 5:51 AM, Santos Das wrote:
> Hi Christian,
>
>
> We see that at the end of the load run, the connections at the TCP
> server remain in CLOSE_WAIT state. We didn’t see this for single call.
> Also, I wanted to tell you that all our connection are initiated from a
> single IP as that is the load balancer IP and we are behind that.
The single IP should hardly matter.
> We also observed that it gets stuck in the CLOSE_WAIT state and remains
> there forever , i.e Sockets are seen in this state even after the
> default of TCP connection timeout.
What kind of method do you use to generate the response?
> From all my study, it points out the TCP stack will keep the connection
> in CLOSE_WAIT state till the application call close on the socket.
Right, so the question now is why the socket is not closed. Two
reasons are clearly coming together: (1) you disabled the timeout,
(2) for some reason MHD believes the response is not done. So we
should also figure out why your response is not considered "finished" by
MHD.
> Do we know when MHD call close normally ? Is there any instrumentation
> that could tell us why /whether FIN is sent from the Server or NOT ?
You could just 'strace' and look for the close() call, but that won't
tell you where exactly the issue is.
[Prev in Thread] | Current Thread | [Next in Thread] |