Sockets in CLOSE_WAIT state

[Diego Woitasen]

I found the issue and the solution I think.

THere is the commit in my repo:
https://github.com/diegows/wanproxy/commit/b77d0c76eb6fc31588cc85ceec1cb6d65b4ab9d4

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 :)

Regards,
  Diego

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:
>>> Hi,
>>>  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?
>>>
>>> Regards,
>>>  Diego
>>>
>>> --
>>> Diego Woitasen
>>> _______________________________________________
>>> wanproxy mailing list
>>> wanproxy at lists.wanproxy.org
>>> http://lists.wanproxy.org/listinfo.cgi/wanproxy-wanproxy.org
>
> Hi,
>   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.
>
> Regards,
>   Diego
>
> --
> Diego Woitasen



-- 
Diego Woitasen