The objects holding references to the character arrays that ultimately consume all the memory are of type org.apache.jasper.runtime.BodyContentImpl as indicated in the object reference tree below:
There was a bug reported in Tomcat 5.5.9 which says The problem is that this huge array never gets reset due to the object pooling implementation in Jasper (JspFactoryImpl maintains a pool of PageContextImpl objects. Each PageContextImpl object maintains an array of BodyContentImpl objects), so the memory it consumed is never returned to the heap. https://issues.apache.org/bugzilla/show_bug.cgi?id=37793 We do not use the suggest JVM argument in our Tomcat 5.5.27 JVM -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true Could adding this argument to the Tomcat JVM resolve the problem? -Anurag On Mon, Oct 11, 2010 at 1:55 PM, Anurag Kapur <anuragka...@gmail.com> wrote: > > Thanks Chris and Chuck for your help so far. > I have added my problem statement with Images to by blog > here: http://anuragkapur-techbytes.blogspot.com/2010/10/tomcat-5527-memory-leak-in-escenic-cms.html > > > On Sat, Oct 9, 2010 at 12:13 AM, Caldarale, Charles R > <chuck.caldar...@unisys.com> wrote >> >> > > Attachments are stripped: there is no image to view, here. >> > >> > I have attached the heap usage graph as a file this time (heap_usage.jpg) >> >> Please read Chris' statement again: attachments are stripped. If you want >> us to look at the pictures, you'll have to post them in some public location >> on the web. > > Heap utilization is like this: > http://3.bp.blogspot.com/_Oq9OlP-8ap0/TLMAno5Z2lI/AAAAAAAACPA/pUr70osY3HU/s1600/heap_usage.jpg > An object call reference tree snapshot that I wanted to show you is here: > http://2.bp.blogspot.com/_Oq9OlP-8ap0/TLMBRLiUzTI/AAAAAAAACPE/ogO2HI2uYig/s1600/object_reference_tree.jpg > >> >> > Or can the address of the object change in the >> > lifetime of the tomcat jvm? >> >> An object can move on each GC. >> > So how should I determine if an object (HashMap entry or character array) > that I saw in the first heap dump exists in the next hump dump I obtained > after the 4th Full GC? > Struggling to determine the root cause. Any further pointers would be much > appreciated. > Thanks > Anurag > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
