BIO connector leaks socket file handles under certain conditions

Hi there,

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:

javac -cp 'jetty-6.1.26/lib/*' JettySocketLeakTest.java
java -cp '.:jetty-6.1.26/lib/*' JettySocketLeakTest

Then using ab to fire a bunch of connections:

ab -n 1000 -c 5 http://localhost:8081/

and then using lsof to verify that there's an awful lot of this business:

java    31492  mst  359u  sock      0,6             156768718 can't identify protocol
java    31492  mst  360u  sock      0,6             156768841 can't identify protocol
java    31492  mst  361u  sock      0,6             156768844 can't identify protocol
java    31492  mst  362u  sock      0,6             156808533 can't identify protocol

Using JVM version:

java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Java HotSpot(TM) Server VM (build 20.4-b02, mixed mode)

Looking at 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.

Thanks,

Mark