We have similar issues with out Spring + Hibernate + Tapestry App. After several redeploys, it kills the App Server wth an OutOfMemeoryException. Found some tips here:
http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669 Tried them, updgraded to the latest apache-Tomcat, but problems still occur. We are unsure if the issue is one of Spring or Hibernate or Tapestry. From looking at the Profiler, it seems that CGLib is holding onto references. We are still further investigating. Would love to hear if anyone else solved this issue. Regards, Saqib > -----Ursprüngliche Nachricht----- > Von: Joel Trunick [mailto:[EMAIL PROTECTED] > Gesendet: Wednesday, 26 October 2005 5:54 PM > An: Tapestry users > Betreff: Memory / Caching Issues > > All > > We are currently experiencing some bizarre memory issues in a tapestry > application. This application uses a lot of reflection via OGNL and > class generation via CGLIB. What happens is that after a period of > time, we have so many pinned objects in memory that large memory > allocations start failing due to fragmentation and we get the infamous > OutOfMemoryException even though there is plenty of total > heap space. > > The pinned objects we appear to be leaking are mainly > GeneratedMethodAccessorXXX CLASSES, although there are some > GeneratedConstructorAccessorXXX classes as well. Each such class > appears to have a corresponding DelegatingClassLoader, and > all three of > these classes are generated by the Java 1.4 reflection code. Note the > GeneratedMethodAccessorXXX are CLASS objects not actual instances. > HPROF shows that there are no breaks in the XXX numbers in the class > names (they are sequential from 1 through the highest, like 980 during > one simplistic run). > > However, we also need to point out that there is a single instance of > each of these classes for all classes with numbers above a certain > point. For example, in one run, HPROF shows that we have > class objects > for GeneratedMethodAccessor1 through > GeneratedMethodAccessor980, but we > have a single instance of classes GeneratedMethodAccessor557 to > GeneratedMethodAccessor980, inclusive (meaning there are no > instances of > 1 through 554). Now, you might think that we just haven't garbage > collected these yet, or they are on a cache, etc. However, there are > three problems with that argument: > > a) We have run GC at least 50 times and the lowest-numbered > GeneratedMethodAccessor object has *never* disappeared, even with > continued running of the application, > b) if there was a cache, it certainly should be limited to some more > sane number like 100, or even 250, and > c) if there is a cache, there should be some way to control > the size of > it. > > The environment we are running in is: > WebSphere 5.1.1.4 > IBM JVM 1.4.2 > AIX and Windows > Tapestry 3.0.3 > > We've been using a combination of Verbose GC, JProfiler and > HPROF to see > what's going on, but we have had problems getting all the details we > need to successfully diagnose this problem. We have no evidence that > this is a Tapestry problem, but wanted to poll the forum to see if > anyone has seen something similar. One thing that we have seen with > JProfiler is that OGNL appears to have a couple HashMap > caches that hold > on to Method objects, but the Javadoc for OGNL has no mention > of a cache > at all, so we wonder if there is something undocumented we could be > doing to OGNL to convince it to release these Methods. > Another thing to > note is what classes are part of which ClassLoader. Currently ALL > dependencies of our app reside in the EAR classloader space, > and all the > application specific classes (and CGLIB generated classes) are part of > the web application classloader. Finally, the thing that we > fund most > frustrating about this problem is it's lack of predictability. After > running the app for a while, we will run through one pass and see the > classes grow only by 1. We run the exact same pass through the app > again, and we will see the classes grow by 28. There is no true > discernable pattern - even as we traverse from one page to the next in > our app, a page transition that has caused zero classes to be > created in > the last 15 passes will suddenly create 12 new classes in > just one pass. > > Thanks in advance! > --m > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
