Thanks for any input, we did ensure that caching is on. Joel
-----Original Message----- From: Patrick Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 26, 2005 12:06 PM To: 'Tapestry users' Subject: RE: Memory / Caching Issues Joel, I've noticed some similar behavior when I have tapestry caching disabled, are you sure it's not something simple like that? Otherwise I could just offer my basic garbarge collection spiel, but it sounds like you don't need it. Sorry I can't offer more, --- Pat > -----Original Message----- > From: Joel Trunick [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 26, 2005 8:54 AM > To: Tapestry users > Subject: 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
