Hi Raymond, thank you for your response.
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
On Mon, Apr 12, 2010 at 13:29, Jason von Nieda <firstname.lastname@example.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.