All,
We've noticed that our Tomcat 6.0.37 instances have increasing overhead
the longer they stay up. We've captured some heap dumps, expecting to
find memory leaks within our code, but found something different instead.
Jasper's BodyContentImpl is actually holding most of the non-collectible
garbage, in the internal char[] buffer. I've checked trunk of Tomcat 6,
7 and 8, and see that the same implementation is still used, so this
issue applies to all currently supported versions.
This issue appears to be well known:
*
http://stackoverflow.com/questions/10421908/is-there-a-fix-for-bodycontentimpl-jsp-tag-memory-leak-using-tomcat
* https://issues.apache.org/bugzilla/show_bug.cgi?id=43925
Specifically what we see happening is due to large pages being rendered
in JSPs - sometimes in the multi-megabyte range, especially for internal
tools. Apparently, some of the tags we use require buffering the output,
versus sending it directly to the Writer.
Now, we certainly can simply set LIMIT_BUFFER and forget about it (throw
away any buffers larger than 8k), but this isn't optimal for our
application. For about 75% of our requests, ~8k is the baseline page
size, with many larger than that. So, depending how the data size, we
could be reallocating multiple times, only to throw away the buffer at
the end.
We'd like to propose a different behavior, and are wondering what others
think about it. If it sounds like a good idea, we're certainly willing
to submit patches to implement it.
--Proposal--
Instead of a hard-coded DEFAULT_TAG_BUFFER_SIZE of 8k, make it
configurable. In addition, if LIMIT_BUFFER is set, provide another
configurable setting called something like MAX_TAG_BUFFER_SIZE (if not
set, defaults to DEFAULT_TAG_BUFFER_SIZE). This would give applications
a more predictable *range* of memory allocated for tag buffers, while
decreasing the frequency of reallocation.
--/Proposal--
We'd probably set DEFAULT_TAG_BUFFER_SIZE to 16k, and set
MAX_TAG_BUFFER_SIZE to either 64k or 128k, based on real-world
performance testing.
One other, slightly less defined question - is there a reason we're
managing char arrays ourselves, instead of using something like Java's
StringBuilder or Javalution's TextBuilder? StringBuilder would reduce
code maintenance, while something like TextBuilder would also reduce
array allocation.
We'd love to hear your thoughts.
Thanks,
Scott Severtson
Lead Platform Architect
Digital Measures
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
