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 <[email protected]> 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
