tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neil Aggarwal" <>
Subject RE: Tag Handler pool eating up Memory (and enablePooling is set to false)
Date Tue, 02 Dec 2003 17:27:04 GMT

> Yeah, it's possible (and probable) that the TagHandlerPool 
> maintains a 
> reference back to the ServletContext in which it lives. That 
> might kew 
> your results. I'm sure that the TagHandlerPool isn't actually 
> taking up 
> that much memory.

This is strange.  When I created a heap dump from my server
just now, it does not have any instances of TagHandlerPool
in the heap dump.  That is what I expected before, but I still
had them in my last dump.

> Do you have any of your own tag libraries, or are you using only 
> 3rd-party taglibs? If you are using your own, check to see if you are 
> holding on to references or something like (anything like 
> shared objects 
> between tags -- that kind of thing).

We are not using any 3rd party tag libraries.
We are using our our tag library.  I will look into that.

> If you have a profiler handy (something more robust that the heap 
> dumper), check to see how many instances of various types 
> there are. For 
> example, if you are using, then filter the object 
> list by and take a look at how many 
> instances there 
> are. If you find that there are thousands of references to 
> tag handlers, 
> then something is probably wrong with Tomcat. Otherwise, 
> several hundred 
> references doesn't sound horrible. It's possible that they 
> haven't been 
> GC'd yet.

Doing a quick grep on my summary results from the new heap dump,
I get this result:
      608,2,class com/slsideas/pagegen/tags/ValueTag
      608,2,class com/slsideas/pagegen/tags/SetPropertyTag$Converter
      608,2,class com/slsideas/pagegen/tags/SetPropertyTag
      608,2,class com/slsideas/pagegen/tags/ProcessTag
      608,2,class com/slsideas/pagegen/tags/IncludeTag
      608,2,class com/slsideas/pagegen/tags/IfNotExistTag
      608,2,class com/slsideas/pagegen/tags/IfExistTag
      608,2,class com/slsideas/pagegen/tags/BaseTag
      304,1,class com/slsideas/pagegen/tags/LoopTag
      304,1,class com/slsideas/pagegen/tags/IfNullTag
      304,1,class com/slsideas/pagegen/tags/IfNotNullTag
      304,1,class com/slsideas/pagegen/tags/IfNotEqTag
      304,1,class com/slsideas/pagegen/tags/IfLoopTag
      304,1,class com/slsideas/pagegen/tags/IfGreaterThanTag
      304,1,class com/slsideas/pagegen/tags/IfGreaterOrEqTag
      304,1,class com/slsideas/pagegen/tags/IfEqTag
      304,1,class com/slsideas/pagegen/tags/EscapeValueTag

The first column is the total bytes held by the instance inself (not
references), the second column is the number of instances that were
in the heap dump, and the last column is the type of the object.

I find it very hard to believe that we have over 2500 active instances
our tags.  This seems to imply they are not being garbage collected.

> I also noticed that you are using JDK 1.4.1. I've heard that this 
> version (it might only be the Sun distro -- can someone 
> confirm?) has an 
> implementation of StringBuffer that has a terrible memory leak. You 
> might want to consider upgrading to 1.4.2 if that's possible.

I ran some code to count all of the instances of java/lang/StringBuffer
and the total bytes they hold both in themselves and their references.
I got 2,925,512 bytes in 15,914 instances of java/lang/StringBuffer.
The heap dump shows 174,740,832 total bytes used in 892,512 total

I don't belive the StringBuffer is the cause of my problems.


Neil Aggarwal, JAMM Consulting, (972)612-6056,
FREE! Valuable info on how your business can reduce operating costs by 
17% or more in 6 months or less! =>

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

View raw message