It was a huge PITA, but I think I have fixed this. There were two
leaks in JPA. The first was caused by registering a class file
transformer, but never unregister it. The second is caused by a class
loader cache in OpenJPA, and which must be cleared directly when the
app is destroyed (I wish they used weak references).
I only verified the fix by inspecting the heap dump to assure that
after the application is undeployed we return to having only one class
loader in the vm. If you have time, can please verify on Windows and
if this is fixed close the JIRA issue.
Thanks,
-dain
On Jan 16, 2008, at 2:32 PM, Dain Sundstrom wrote:
Finally, got time (energy) to look at this.
I think (and I could be wrong) the bulk of this patch is to convert
OpenEJB to the XBean JarFileClassLoader and to explicitly close all
JarFiles and class loader resource input streams. Unfortunately,
switching to the JarFileClassLoader only fixes the problem when
OpenEJB is run standalone. When we are embedded in Tomcat or JUnit,
we don't control the class loader. This means that in these other
modes we can't relying on the explicit close method of the
JarFileClassLoader, and instead we must make sure that our class
loaders are garbage collected when the application is undeployed.
This is a lot more difficult, but is still practical and something
that was working OpenEJB 3....
Somewhere in the last few months we seem to have regressed when it
comes to the GCability of our application class loader.
Specifically, JPA is holding on to the class loader again. I am
working on a patch to clear this up, and I hope to be able to create
a test case for the GCability of our class loader.
As for this patch, I don't think we should apply it. I'd prefer
that we don't switch standalone to JarFileClassLoader as it will
mask the problems that will pop up in the other modes. I would also
prefer that we don't add the explicit close of the JarFile and class
loader resource stream as it adds extra unneeded complexity to this
code since they will be closed automatically when GCed from the
stack (these are method local variables).
A few notes on the patches:
- In the future, please don't mix reformatting with new code in
patch files, as it makes it difficult to review the new code
- OpenEJB doesn't use xbean-spring
- TemporaryClassLoader has very different behavior then
JarFileClassLoader and one shouldn't be swapped for the other
without lots of thought (this is possibly the cause of the CMP2JPA
problems)
This is just my opinion, and am curious what others think about this.
-dain
On Jan 14, 2008, at 12:38 PM, Dain Sundstrom wrote:
Looking...
-dain
On Jan 14, 2008, at 4:52 AM, Jacek Laskowski wrote:
On 1/12/08, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
Alternatively, I can take a look at this next week.
Okey, I had a nice and pleasant weekend trying to fix it, but even
though module jars can be deleted with the patch I submitted to
OPENEJB-746 openejb doesn't like it as far as CMP2JPA stuff goes.
Dain, could you take a look into it and see why I'm stuck with the
issue you described long time ago - Do mapped superclasses work at
all
in OpenJPA? (http://www.mail-archive.com/[EMAIL PROTECTED]/msg02045.html
).
I'm unable to fix it myself.
https://issues.apache.org/jira/browse/OPENEJB-746
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
