Did the part of the fix that deletes the jar (and any associated
unpacked directory) get added already?
-David
On Jan 16, 2008, at 6:28 PM, Dain Sundstrom wrote:
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
