When this happened to me, I also had trouble believing that Tapestry wasn't somehow involved, but it was my bug. I was keeping a static reference to a couple of big objects (Engine, DataContext) for reasons that seemed good at the time. The references were being released when a user logged out but not when the session timed out. Even with short low-workload sessions I was losing 1.5 MB per session, which didn't take many days to consume the 256 MB allocated. I found the problem quickly with JProfiler. (I was able to fix the problem well within JProfiler's 10-day evaluation period, but we bought a copy anyway. :-)
After fixing that, there were still a large number of objects hanging around that looked like leaks, but in fact they were in caches that didn't grow forever. For example: <class>[] 58,031 arrays, 4.2 MB owned by ognl.runtime. java.lang.reflect.Method 70,965 objects, 3.97 MB, also ognl. java.util.HashMap$Entry 100,136 objects, 2.4 MB, also ognl. org.objectstyle.cayenne.DataRow: 775 instances, 43.4K. java.util.ArrayList, 41,145, total size 987K. That looks like a lot of objects but the total memory consumption wasn't that much and it didn't keep growing. Our apps are extremely stable now, running for months without restarts, and Tapestry is blameless. (We can still lose a few megs to Tomcat if we do a hot redployment in production.) Running a profiler on one's app can be quite educational. ----- Original Message ----- From: "Jesse Kuhnert" <[EMAIL PROTECTED]> To: "Tapestry users" <[email protected]>; <[EMAIL PROTECTED]> Sent: Friday, October 28, 2005 8:20 AM 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]
