On Thu, Sep 4, 2008 at 9:32 AM, Scott Blum <[EMAIL PROTECTED]> wrote:
> I think this is a general problem with URL.openConnection() where you don't > explicitly grab the input stream and close it. I think my change should be > safe since ultimately I'm reading lastModified from File and ZipEntry, not > URLConnection. > You're right that it's a general problem with the input stream not being closed. getLastModified() happens to be a frequent cause, but its not the only way to do it. BTW: I think URLConnection actually does reclaim the FD if/when the > connection is finalized on most platforms. > Calling System.gc() or just having a GC occur because the JVM decides to is indeed enough to clean up the leaks. I only had limited ability to test this on the Solaris environment I was on, but it seemed that if you ran up the number of FDs used by lots of getLastModified() calls or other calls that create the InputStream but do not close it, then you can actually run out of FDs for other things if you are unfortunate enough to request too many FDs before a GC occurs. As I recall these other classes of FD requests could then cause the JVM to terminate. Thanks Fred > > > > > On Wed, Sep 3, 2008 at 9:38 PM, Fred Sauer <[EMAIL PROTECTED]> wrote: > >> The use of getLastModified() caught my eye, and I was wondering if >> there's a pseudo file descriptor leak on Solaris as described in this issue >> I filed with Findbugs: >> >> [ 2017517 ] Solaris getLastModified() File Descriptor Leak detection >> >> https://sourceforge.net/tracker/?func=detail&atid=614693&aid=2017517&group_id=96405 >> >> Fred Sauer >> [EMAIL PROTECTED] >> >> > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
