Re: [gevent] CLOSE_WAIT state, bug in gevent?

[Executier Godlike]

This might help:
http://stackoverflow.com/questions/1913408/tcp-connections-hang-on-close-wait-status


As I understand, you also have to close the socket on your side.
If I'm correct, the CLOSE_WAIT socket is always ready for reading,
but return 0 bytes (see man recv and "return value" section).
So be sure it's a problem in gevent, not in redis.py .

> I'm using the gevent.wsgi.WSGIServer to send requests to the
> backend( a server that running redis-server). The "TIME_OUT" of
> redis's config is set to 10 seconds, thus the connect would be closed
> by the redis-server when the connection is idle for 10s. Inside the
> wsgiserver, i use redis-py to genereate one instance.
> The problem is that after the connection is closed by the
> redis-server, the state of the socket becomes CLOSE_WAIT and the
> state never changes until the wsgiserver is killed.
>
> anyone meets similar problem and any help to fix the problem?

[Bo Wang]

I have figured out why so many CLOSE_WAIT socket exists. The redis-py maintains the connection_pool, when the redis-server closes the connection on its side, redis-py instance would not react immediately. When the socket whose peer-side closed by redis-server comes to use again, an error will be raised and redis-py instance would close it and re-establish to the redis-server. So the CLOSE_WAIT socket could disapper.

Thank you for you help! :)

在 2012年7月2日星期一UTC+8下午9时03分18秒，exe写道：