Sockets in CLOSE_WAIT state
juli at clockworksquid.com
Wed Jan 2 17:24:53 PST 2013
If you can reproduce it with a single connection, it should be very
easy to track down with logging statements. I would guess that it's
one of two things:
(1) the polling mechanism isn't telling the upper layers when the
remote side has closed the connection, and so the upper layers don't
realize they need to close the connection
(2) could be a bug in the zlib or xcodec pipes causing them to not
generate EOS and make the proxy close the connection.
There's other possibilities, but I'd start by instrumenting as much as
possible to figure out if anything is reacting to the FIN, and whether
anything should be reacting to the FIN.
On Wed, Jan 2, 2013 at 5:04 PM, Diego Woitasen <diego at woitasen.com.ar> wrote:
> I was testing Wanproxy for HTTP (with Squid behing the Wanproxy
> Server) and I'm running out of file descriptors frequently. In the
> server side, netstat shows a lot of CLOSE_WAIT sockets. This looks
> like a bug in the code, which is not closing all the sockets properly.
> Any hint to find where the bug is?
> Diego Woitasen
> wanproxy mailing list
> wanproxy at lists.wanproxy.org
More information about the wanproxy