Message10759

Author nickmbailey
Recipients nickmbailey
Date 2016-02-19.20:52:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1455915121.67.0.258539730072.issue2470@psf.upfronthosting.co.za>
In-reply-to
Content
Jython's implementation of sockets/select is causing socket's to leak inside the twisted select reactor implementation.

I've uploaded a tarball with a script that demonstrates the problem. If you run './runjython.sh' you will see 10 http requests made and never cleaned up in the reactor. Running './runpython.sh' will demonstrate the same problem doesn't exist in python. 

I've tried to do some analysis of what the issue is on my own but some input from some people with more experience will be helpful.

I think what is happening is:

* We open a socket
* After successful connection, we add a callback to handle the underlying netty channel being closed: https://github.com/jythontools/jython/blob/master/Lib/_socket.py#L878
* After the http request, the netty channel is closed, our callback runs, and adds the PEER_CLOSED message to the sockets incoming buffer
* The _writable method of _realsocket depends on the channel being active and open: https://github.com/jythontools/jython/blob/master/Lib/_socket.py#L1123
* So after the netty channel closes, _writable will always return false. This means that select will never return this socket object as writable again and it will sit in a half closed state forever.

So I *think* the right solution is some additional logic in '_writable'. The underlying netty channel being closed doesn't necessarily mean we are down with that socket.
History
Date User Action Args
2016-02-19 20:52:01nickmbaileysetrecipients: + nickmbailey
2016-02-19 20:52:01nickmbaileysetmessageid: <1455915121.67.0.258539730072.issue2470@psf.upfronthosting.co.za>
2016-02-19 20:52:01nickmbaileylinkissue2470 messages
2016-02-19 20:52:00nickmbaileycreate