If you refer to the original post, you will see that we definitely have profiled this app repeatedly, but pinned objects based on classloader and reflection issues have been very troublesome to track down.
One alert reader here mentioned a bug in the 1.4 JVM we use, we are exploring a possible patch as the remedy for our situation. I didn't mean to raise concerns over Tapestry memory, but knowing what to expect from Tapestry (and OGNL) in regard to caching, helps us determine where the memory leak may originate. In this case, the best guess right now is actually the JVM. Joel -----Original Message----- From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] Sent: Friday, October 28, 2005 7:20 AM To: Tapestry users; [EMAIL PROTECTED] Subject: Re: AW: Memory / Caching Issues Hmmm...It would be interesting if someone experiencing these oome errors could somehow run one of these profiles on their appserver to get more of a definitive picture? (Like jprofiler or something? I know there are many out there, but a basic table summary of how many objects are in memory of each obj type could help). Probably not a fun task, but if there is a little leak somewhere it would be doing us all a favor if someone who is experiencing it tracked it down and reported back. On 10/28/05, Paolo Donà <[EMAIL PROTECTED]> wrote: > > On 10/28/05, ausias vives <[EMAIL PROTECTED]> wrote: > > > > > > Exactly, what I was saying is that if you get OOMEs > > only after reloading the application several times is > > most likely to be related with some tomcat issues. [cut] > > > I just switched my tapestry4 app from Tomcat 5028 to Bea Weblogic 8.1 SP2 > and I'm experiencing the same reloading OOME issues I had with tomcat... > So it doesn't seem a tomcat bug. I'm running with tapestry caching > enabled. > > I'll dig more but I'm pretty sure it's not my app fault. > > Paolo > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
