Hi Michael, I sent this reply once already, but the [email protected] site rejected it for some reason. I'll try again by doing a simple reply (with no history)...
Hi Michael, I didn't see the screen shots attached... But, I looked at your configuration. One thing that jumped out at me is this property: <entry key="openjpa.RuntimeUnenhancedClasses" value="supported" /> This indicates that you are running with the "not ready for prime time" subclassing support. For production environments, we do not recommend running with this option. WebSphere has even turned this off in their environment to prevent users from accidentally running with this option. And, most recently, OpenJPA 2.0 turned this off as the default to prevent accidental usage. Bottom line is that the enhancement processing is preferred, both from a functional and performance standpoint. I'm not positive that this is where the memory leak is coming from, but it's an excellent first guess. :-) Especially since we do not perform any memory leak tests with this option turned on. My suggestion would be to turn this off. I can't tell what version of OpenJPA you are running with, so the safest way to turn it off is to set the value to "warn" or "unsupported". And, then use one of the enhancement mechanisms [1] that fit your environment. Since I don't know how well the -javaagent meshes with the Spring environment, the best mechanism might be to put the enhancement processing into your build. If you want another read on the enhancement processing, here's a blog post [2] that might help. If you can try this and let us know if the memory leak still exists, that would be great. If it does exist only with the subclassing support, then it probably won't get much attention. If it does exist with enhancement, then we'll be much more interested. Thanks for your help, Kevin [1] http://openjpa.apache.org/builds/2.0.0/apache-openjpa-2.0.0/docs/manual/manual.html#ref_guide_pc_enhance [2] http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.html
