-------- Original Message --------
Subject: Re: Fwd: File Descriptor leak?
Date: Fri, 18 Aug 2006 14:48:54 +0100
From: Alan Bateman <Alan.Bateman_at_Sun.COM>
To: Jan.Luehe_at_Sun.COM
CC: jerome Dochez <Jerome.Dochez_at_Sun.COM>, Jim Driscoll
<Jim.Driscoll_at_Sun.COM>, Eduardo Pelegri-Llopart
<Eduardo.Pelegrillopart_at_Sun.COM>, Xueming.Shen_at_Sun.COM
References: <44E4DAC5.3060009_at_Sun.COM> <44E4E020.7010905_at_sun.com>
<44E4EA66.8010108_at_Sun.COM> <44E4F54F.3020603_at_sun.com>
<44E54249.9050005_at_Sun.COM>
Jan Luehe wrote:
> :
>
> Right, but in his forum post
> (http://forum.java.sun.com/thread.jspa?threadID=665921),
> he reports that the number of open files was still high.
The thread pre-dates the release of 5.0u7 so the socket adapter bug may
have been a factor.
I see Binod replied to the thread suggesting that the "quick start"
feature be turned off. The "quick start" feature hacks into our
SelectorProvider implementation so that listener channels are created
for each of the app server components. I believe some of those
components aren't NIO based so socket adapters are used to get a Socket
interface to the channel and this could lead to the leak.
One other point is that we have a problem on Linux with poll(2). If
there is a thread blocked in Selector.select waiting for events, and if
one of the registered channels is asynchronously closed, then the
underlying connection will not be closed until the select method (poll
system call) completes. This is a Linux kernel bug. It doesn't lead to a
leak but rather it just means that open file descriptors hang around a
bit longer than might be expected. If the Selector is busy then the
problem doesn't arise because a Selector deregisters and releases file
descriptors after each select. Another point is that this issue doesn't
happen with the 2.6 kernel and JDK6. The reason is that we use the newer
epoll event notification facility which doesn't suffer from this
problem. I've putback the new epoll-based SelectorProvider for 5.0u9 but
it will require a system property to enable it (couldn't change in the
default SelectorProvider implementation in an update release).
One other thing is that the lsof output in the thread lists a lot of
pipes. It would be interesting to find out if these are
Pipe.SourceChannel/Pipe.SinkChannels or if they are something else. NIO
Pipes aren't used very much - do you know if the app server uses them?
>
> Regarding the NIO file descriptor leak:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6215050
> ("SocketChannel created in CLOSE_WAIT and never cleaned up.. File
> Descriptor leak")
>
> It's been marked as fixed in JDK 6 and JDK 5.0u7, but people are still
> complaining:
>
>
> Submitted On 31-JUL-2006
> * <mailto:me_at_andreas-schaefer.com> *
>
> This bug seems not to be closed. If we ar making a socket connection
> to localhost, to check the running web service from within the
> JVM, then there are remaining file descriptor's leaks:
I don't think we have a bug but I will mail this person and see if he
can provide a test case or at least a better explanation for why he
things there is a problem.
-Alan.