I've developed different web applications using Tapestry and other projects using servlets, in both cases I've used Tomcat, versions 4 and 5, in I've always got OOME during development, that is, reloading the web application lots of times.
But all those problems disappear in production, once the applications where tunned (specially JVM) and bug free, they can run for a very long time, and never got an OOME ( supposing you choose the right memory heap ) It's a known issue that reloading an application in tomcat causes, in the short or mid term, OOME errors. In your case I woudn't bother so much, and I'd focuse in checking that the application runs correctly without using the reload facility. It's very useful to write some load tests and using httpunit or webunit. Also it was very useful to me to adjust the JVM parameters, for java 1.4.2 check the document: http://java.sun.com/docs/hotspot/gc1.4.2 In my experience, if you continue to have memory related problems without reloading the servlet container, you should: - check and adjust the memory heap (normal applications use lots MB), very useful to read the jvm document. - if problems persist, there's is probably a coding error, it's not dificult to get confused by the way Tapestry works, specially if mixed with other frameworks. hope it can help a bit. --- Saqib Rasul <[EMAIL PROTECTED]> wrote: > 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] > > ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
