Aug 18, 2006. A number of developers on the JDC have posted comments suggesting that his bug is not fixed in 5.0 update 7 on Linux. If you believe there is still a leak then please post a test case or leave a mail address so that we can follow up. So far all of the cases that we have examined have been cases where the closing of the file descriptor was delayed because the Selector is idle (meaning there aren't any events to wake it up). In those cases, the connection is closed but the file descriptor isn't released until the Selector wake ups.
The latest sdn comment (3 oct) says "In a relatively idle system that repeatedly polls a
deployment server for new artifacts, eventually I'll drain the avialable file descriptors
for the process leaving the VM wedged and unable to respond to new requests or make further
polling efforts. However, if I put the system under load such that full GCs are taking place,
the FDs are cleaned during the full GC."
Most likely this application creates a new thread everytime when need to "poll and process"
the request and then throws away the thread later. Yes, such a use scenario will cause a
temporary fd "leakage", before a GC kicks in. Part of fix of this bug is to have a
"phantom-reference-based cleaner" to clean/release up the fds used by the app thread (mostly
if the processing involves a "timeout" setting) when the thread is dead. So, yes, you need
the GC to start up the cleanup. In such a scenario, a thread poll is strongly recommended.
Not only the fd, the "thread" itself is also an expensive system resource, you might end up
of exhausting the thread resource before you hid the fd limit.
Let us know if this is not your case. And as mentioned above, it would be easy for us to
follow up if you can leave your contact info (email address).