db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason von Nieda <ja...@vonnieda.org>
Subject Re: Derby causing a classloader leak
Date Mon, 12 Apr 2010 22:54:04 GMT
Hi Raymond, thank you for your response.

It's a few things. First, yes, the finalizer is not called in the case of
the leak. Second, I am using YourKit profiler and in the case of the leak I
can see many Derby classes still loaded along with the classloader that
loaded them. Also, I have been using jmap and jhat to dump the heap and look
at the loaded classes and in the cases that I am calling "leak" the Derby
classes are still loaded. Finally, the reason for all my work on this, if I
run this test code in a loop instead of a single run it eventually causes an
OOM PermGen space, which is the same error our app experiences after a few
restarts. By simply not running the two SQL statements the test can run
indefinitely without an OOM.

Thanks,
Jason




On Mon, Apr 12, 2010 at 3:40 PM, Raymond Kroeker <raykroeker@gmail.com>wrote:

> Can you describe the symptom of a leak?  Is it that the finalizer
> isn't called or is there some other criteria by which the judgement is
> being made?
>
> Raymond
>
> On Mon, Apr 12, 2010 at 13:29, Jason von Nieda <jason@vonnieda.org> wrote:
> > Hi all,
> > I have been tasked with finding a classloader leak in our application and
> I
> > have been slowly tracking it down to the Derby embedded driver. To test
> this
> > I wrote a small test case outside of our application that simply loads
> Derby
> > into a second classloader and causes it to create a drop a table. These
> > actions, even after the proper Derby shutdown procedures cause the
> > classloader to not be unloadable. Can someone take a look at the code
> below
> > and tell me if I am missing something, or is this perhaps a known issue?
> > I've done quite a bit of searching and the main thing I found
> > was https://issues.apache.org/jira/browse/DERBY-3745 which seems to have
> > been fixed.
> > I am using Derby 10.5.3.0.
> > Interestingly, I have found that loading the driver and opening a
> connection
> > doesn't cause the leak but any execution of a statement does.
> > The code I am using to test this is at http://pastebin.com/pJBdGBVT .
> Main
> > is the test case itself, Test is the class which is used to load Main
> into a
> > child classloader and TestClassloader is just an extension of
> URLClassLoader
> > that lets me see when it has been finalized.
> > Of note is that if I don't execute the two statements the case does not
> > leak. I have also tested this with hsqldb and after adding the Logging
> > shutdown at the end of stop() it also does not leak.
> > Thanks,
> > Jason
> >
>
>
>
> --
> ---------------------------------------------------------
> Raymond Kroeker
>

Mime
View raw message