tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Tomcat 5.5.25 | Memory leak in Web Application
Date Fri, 08 Oct 2010 21:07:59 GMT
Hash: SHA1


On 10/8/2010 3:15 PM, Anurag Kapur wrote:
> _Problem Statement_
> Memory leak in web application running on Tomcat

_Solution Statement_

Fix your memory leak

> _System Information_
> Tomcat 5.5.27

This statement plus the subject line are confusing me.

> _Observations and Investigation Done_
> Under load, the web application slowly runs out of heap space. The heap
> utilization graph suggests a memory leak type pattern.

Attachments are stripped: there is no image to view, here.

> Heap dumps were gathered to determine the root cause and observations
> are as below from the dumps:
>    1. HashMap entries from the below object reference tree seem to
>       consume over 80% of the used tenured generation space.
> org/apache/jasper/compiler/JspRuntimeContext
> Java/util/Collections$SynchronizedMap
> Java/util/HashMap
> Java/util/HashMap$Entry

If this doesn't grow, then it doesn't sound like a memory leak.

>    2. Heap dumps gathered during different times and after a Full GC
>       always indicate 100 entries

This indicates zero growth, so I would guess no memory leak.

>    3. The number of objects referenced by each HashMap entry vary
>       between 2-3
>          1. These are either a String and JspServletWrapper object
> or
>          2. A String, JspServletWrapper and _another HashMap Entry_.
>             This call reference tree of HashMap entries referenced by
>             another HashMap entry can repeat to a depth of approximately
>             8-10 nodes

That sounds weird.

> The above is indicated in an object reference tree obtained after
> analyzing the Heap dump as shown below
>    4. The maximum percentage of the memory occupied by the HashMap entry
>       object is by a character array that seems like the JSP servlet
>       response. HTML response (tags with content) can be seen in the
>       character array

Does this response text stay in memory indefinitely? When you say it's
the response, is it the actual response to a particular client, or is it
just static text from the JSP source? If the latter, this is completely
expected: the JSP compiles-in all static text.

> _Questions_
>    1. I am stuck at this point and have run out of ideas on how to get
>       to the root cause of this issue. Do you have any ideas/suggestions
>       to help identify the root cause?

Finding the roots to those references should help. For instance, what
page is holding on to all those entries? It's possible that the
JSPRuntimeContext requires these data even after the compiler has
compiled the code.

>    2. I google and found the following interesting links
>          1.
>             Is there any know issues, configuration that causes a memory
>             leak by caching of servlet responses in the container and
>             not flushing the cached objects?

The above seems to be a complaint about how JSPs work: they are
translated into .java files, then compiled and loaded. These loaded
class files contain lots of static strings. There's nothing to be done
about this.

>          2.$41c079a0$03b696c0@garethdqw0t9if%3E
>             We use a lot of JSTL in our web application. Are there any
>             known issues around memory issues as indicated on the link?

This one is seriously old: 2003 was a long time ago (even older than
your version of Tomcat). I don't think that post is relevant anymore.

You should consider upgrading. Check the changelog
( for changes to
Jasper between your version (5.5.25 or 5.5.27) and the latest (5.5.30).
You also might consider upgrading to Tomcat 6.0.

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message