[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-core-libs-dev
Subject:    Re: RFR: 8132359 - JarURLConnection.getJarFile() resource leak when file is not found
From:       Rob McKenna <rob.mckenna () oracle ! com>
Date:       2019-11-25 16:09:24
Message-ID: 20191125160924.GB7185 () yoga
[Download RAW message or body]

I'm afraid so.

The option of changing the the JarURLConnection spec to indicate what
could happen when the class file is missing was discussed but that will
require some further thought. (and it may not necessarily result in a fix
for this problem, the assumption being that behaviour changes in this
code would be unwelcome)

    -Rob

On 25/11/19 13:49, Alan Bateman wrote:
> 
> Daniel's summary is useful but changing URLClassPath doesn't feel right. Are
> you in a hurry to find a solution to this? Just asking as I think I'd prefer
> to see other options explored that fixed it in the protocol handler instead.
> 
> -Alan
> 
> On 25/11/2019 13:31, Rob McKenna wrote:
> > Thanks Daniel,
> > 
> > cc'ing core-libs-dev in case there are any objections.
> > 
> >      -Rob
> > 
> > On 25/11/19 10:47, Daniel Fuchs wrote:
> > > Hi Rob,
> > > 
> > > That looks good to me. I wonder if that should go to corelibs for
> > > review as well.
> > > 
> > > The underlying issue here is that JarURLConnection open both its
> > > jar file and its jar file entry in its connect() method.
> > > However, it delegates the opening of the jar file to the cache,
> > > when uses cache is true.
> > > In this latter case, if opening the entry throws an exception,
> > > it can't close the jar file because the file might have come from
> > > the cache and it might still be used by someone else.
> > > But because getJarFile() calls connect() then there's no way
> > > to retrieve the jar file through that (failed) connection.
> > > 
> > > I agree that fixing the issue in URLClassPath is probably the
> > > less risky.
> > > 
> > > I see that your test caters for all possible setting of uses cache
> > > and combination of success/failure when opening the jar entry,
> > > so this give me confidence that the fix is working as intended.
> > > 
> > > best regards,
> > > 
> > > -- daniel
> > > 
> > > 
> > > On 24/11/2019 15:33, Rob McKenna wrote:
> > > > Hi folks,
> > > > 
> > > > If a FileNotFoundException is thrown when attempting to load a class
> > > > from a jar file, a reference to the open JarFile remains even after the
> > > > loader is closed. The test in the webrev demonstrates the problem by
> > > > attempting to delete the JarFile after attempting a class load.
> > > > 
> > > > The deletion will fail as the JarFile is still in use (i.e. open)
> > > > despite the fact that the loader has been closed.
> > > > 
> > > > Note: the behaviour depends on the URLConnections useCaches setting so
> > > > the test cycles through the combinations. (this helpfully found a problem
> > > > with an earlier fix attempt)
> > > > 
> > > > bug: https://bugs.openjdk.java.net/browse/JDK-8132359
> > > > webrev: http://cr.openjdk.java.net/~robm/8132359/webrev.01/
> > > > 
> > > > Thanks,
> > > > 
> > > >       -Rob
> > > > 
> 
[prev in list] [next in list] [prev in thread] [next in thread]