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.


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?


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
> 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