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 -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ I am now available for general use under a modified BSD licence.
