tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anurag Kapur <anuragka...@gmail.com>
Subject Re: Tomcat 5.5.25 | Memory leak in Web Application
Date Tue, 19 Oct 2010 11:36:35 GMT
Hello all,

Can one of you please help answer the last set of queries I have on this
please?

Thanks
Anurag


On Mon, Oct 18, 2010 at 3:02 PM, Anurag Kapur <anuragkapur@gmail.com> wrote:

> Thanks Chris/Mark/Charles/Pid for your help with this. The issue has been
> fixed after using the JVM argument :-
>
> -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true
>
> I get a healthy heap utilization graph on the same web application under
> similar load test conditions as indicated in the graph in the link below
>
> http://3.bp.blogspot.com/_Oq9OlP-8ap0/TLxLM-dsf_I/AAAAAAAACPk/SolVOyYpAuI/s1600/heap_utilization_post_fix.jpg
>
> The application sustains the load over a 2 hour period without showing any
> signs of degradation as it did earlier.
>
> Before closing this chapter I wanted better clarity on a couple of
> questions:-
>
> >> Also, yes, ours being a content management application, we have large
> >> body tags. We use several tag libraries that come with the CMS
> >> implementation to fetch content from the CMS.
> >
> > Usually CMS applications /manage/ content, rather than hard-coding it.
> > What kind of huge body tags do you have?
>
> 1. I am not quite sure if I have the correct answer to your question but I
> think the most probable reason is that we use tags provided by the CMS to
> cache the HTML response (JSP caches). The body of these tags can hold large
> chunks of HTML response. Can this be a suitable explanation to your
> question?
>
> 2. The large character arrays I saw in the heap dumps had a lot of empty
> elements. For example, the first 500 or so elements in the array were empty
> and then the HTML response was seen in some elements again followed by empty
> elements and then actual HTML content again. This pattern was spread across
> the entire character array. Can these correspond to white spaces? Can this
> be because I do not have *trimSpaces *option enabled as mentioned here:- http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html#Production
> Configuration<http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html#Production+Configuration>
> ?
>
> 3. What does the JVM argument actually
> do? -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true
> I understand it does not turn off tag pooling and instead limits the size
> of the buffer. Can you please elaborate what this means? What happens when a
> body tag which exceeds a certain threshold of size?
>
> Regards
> Anurag
>
> On Wed, Oct 13, 2010 at 7:16 PM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Anurag,
> >
> > On 10/12/2010 5:47 PM, Anurag Kapur wrote:
> >> I have probably attached an incomplete snapshot of the memory
> >> utilization graph.
> >
> > I'm only looking at what is on your blog. That graph looks good. Perhaps
> > you could update your blog with a graph that illustrates your conclusion.
> >
> >> I have done a few tests with the JVM argument suggested in the bug
> >> report. The initial tests look good.
> >
> > Good.
> >
> >> Also, yes, ours being a content management application, we have large
> >> body tags. We use several tag libraries that come with the CMS
> >> implementation to fetch content from the CMS.
> >
> > Usually CMS applications /manage/ content, rather than hard-coding it.
> > What kind of huge body tags do you have?
> >
> > Good luck,
> > - -chris
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.10 (MingW32)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iEYEARECAAYFAky193MACgkQ9CaO5/Lv0PC8ZwCeOCRg4pGeK7QjTVkeV7tNJUcD
> > GBgAnRO63f4ed/ZRewJcgLC7FwJwLg20
> > =ZC7S
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message