dev@grizzly.java.net

potential file descriptor leak with failed SocketChannel creation(s)

From: charlie hunt <charlie.hunt_at_sun.com>
Date: Mon, 23 Apr 2007 10:00:31 -0500

FYI ....

There's potential file descriptor leak in
java.nio.SocketChannel.open(SocketAddress address) when the connection
initiation fails, (i.e. any test case that does a negative test can
potentially leak file descriptors). The work around is to explicitly
call SocketChannel.close() if the SocketChannel.open(SocketAddress
address) fails.

In addition, when using the SocketChannel.open() followed by a
SocketChannel.connect(SocketAddress address), the expectation in the
implementation of SocketChannel is that the programmer explicitly call
SocketChannel.close() if the connect(SocketAddress address) fails.

A JDK bug is filed under bug id 6548464 for the file descriptor leak.

Note, I have not looked at Grizzly to see if we have a potential file
descriptor leak.

The work around is to not use the convenience method
SocketChannel.open(SocketAddress address). Instead change to using the
SocketChannel.open() followed by a SocketChannel.connect(SocketAddress
address). Then use a try/catch block construct such as this one:

SocketAddress sa = new InetSocketAddress("bogus.com", 34567);
SocketChannel sc = sc.open();
try {
   sc.connect(sa);
} catch (IOException x) {
  try {
     sc.close();
  } finally {
     throw x;
  }
}

charlie ...

-- 
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>