Sockets in CLOSE_WAIT state
diego at woitasen.com.ar
Tue May 14 05:24:28 PDT 2013
I found the issue and the solution I think.
THere is the commit in my repo:
decoder_error() should be called always if an error condition is
detected in the decoder to be sure that all resources all released,
specially the sockets :)
On Wed, Apr 24, 2013 at 8:41 PM, Diego Woitasen <diego at woitasen.com.ar> wrote:
> On Wed, Jan 2, 2013 at 11:24 PM, Juli Mallett <juli at clockworksquid.com> wrote:
>> 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
> It's been a long time. After few months I started again to debug
> this bug trying to fix it. I was able to reproduce it with release
> 0.8.0 and the latest trunk (today checkout).
> The only way that I found to reproduce the issue easily is under
> this configuration:
> wget -> wp client -> wp-server -> squid
> and then executing:
> wget --max-redirect=0 www.clarin.com.ar
> Using wp client as proxy. It fails 99% of the times.
> I couldn't reproduce it using netcat and haven't had time to write a
> test case, but with Squid using default config and wget it's very easy
> to reproduce. The problem appears when Squid and Wget tear down the
> connection at almost the same time. If you try it with other pages
> sometimes fails, sometimes not.
> I went deep in to the code and I think that I found two bugs related
> with this problem:
> 1- WP signalling isn't working properly. When the socket appears in
> the CLOSE_WAIT state I see the EOS msg from the server to the client
> and the EOS_ACK from the client to the server. When the socket is
> closed properly, I see the EOS and the EOS_ACK in both ways. (what's
> the right behavior? I think the latest one).
> 2- When the problem appears, the client closes the socket, it sends
> the FIN,ACK and ACK just after the EOS/EOS_ACK exchange. The server
> isn't detecting that the socket was closed because a read is never
> scheduled again from the socket. I undertand that signalling is not
> working fine, but WP should handle this case.
> I'll continue to debug and to try to fix this issue in the next days.
> Hints are welcome.
> Diego Woitasen
More information about the wanproxy