Thanks for reporting this issue.
Apologies, don't know the details of how this report was missed. Sun
bug-id 6588160 has been created from the webbug that you submitted.
If you want us to evaluate your patch, please read following webpage on
"how to contribute to the OpenJDK project" and sign the required agreement.
http://openjdk.java.net/contribute/
Seema
Jan Grant wrote:
I've tried to raise this in the past; the opening of the relevant bits
of the JDK have encouraged me to try again.
sun.security.krb5.internal.UDPClient has no close() method; and the
UDPClient-using code path in sun.security.krb5.KrbKdcReq (which has a
few other close-to-the-coalface errors) consequently leaks FDs (unlike
the TCP path, which has a try/finally that closes the socket properly).
We're seeing a krb5 client application (the Yale CAS SSO) keel over in
no time due to FD exhaustion. A trivial fix (the non-whitespace part of
the diff is 8 lines) sorts this out.
I've tried to report this in the past without much luck: engineers were
initially very responsive then it got picked up and kind of fell flat.
Whilst I'm chasing the beauracracy here to get a release signed, I think
the patch itself is so trivial it probably doesn't warrant much concern.
Full report is stashed here:
http://www.freebsd.org/cgi/query-pr.cgi?pr=110912&cat=java
including a patch against the contents of jdk_sec-1_5_0-src-scsl.zip;
this affects all platforms.
A unit test is hard to do; however if you look at support case 37763365
you should find a small piece of code (and associated typescipt) that
demonstrates the krb5 client slowly using up UDP sockets.
Eventually the GC will kick in and reclaim these; however, (1) relying
on GC to manage any resource other than memory is a bug; (2) we're still
seeing failures before GC has a chance to work.
Let me know what I can do to progress this; according to various reports
this fault has been around for a long time. It'd be good to knock it on
the head.
Cheers,
jan
