Resolution: Won't Fix
Affects Version/s: 6.1.26
Fix Version/s: None
Number of attachments :
I'm seeing an issue when embedding Jetty 6.1.26 in an application that uses org.mortbay.jetty.bio.SocketConnector. HTTP requests are being handled properly, but lsof shows that socket file handles are hanging around, and after running for a while my app throws a "Too many open file descriptors" error.
If I force a full garbage collection, all of the file handles are cleared. It appears that it's not so much an issue of leaking Java Socket objects, as not calling .close() on them and relying on the finalizer to do it. In my case, garbage collections are infrequent enough that this doesn't happen before I'm out of file handles.
By testing a number of different versions of Jetty I've found that the issue was introduced in 6.1.26. Looking at the diffs, I suspect it might be a result of the change made for
JETTY-547. It seems that the NIO SelectChannelConnector calls .close() on its sockets when the next IO attempt after the socket.shutdownOutput() call throws an Exception, but I'm not seeing the same behaviour with the BIO SocketConnector.
I've been testing using the attached Java program and the "ab". Running the attached program with:
Then using ab to fire a bunch of connections:
and then using lsof to verify that there's an awful lot of this business:
Using JVM version:
JETTY-547, I'm not sure I'm game to guess where the right spot to call Socket.close() is here, so sorry to open an issue that isn't accompanied by a fix. I'm happy to help with further testing if I can be of any use.