tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: 7.0.25 to 7.0.27 requires -Xmx32m to go to -Xmx512m
Date Fri, 13 Apr 2012 10:37:34 GMT
Peter <> wrote:

>Thanks for the response Mark - it is consistent with both observations
>that i noted in the original email (heap post startup was near 0, and
>disabling scanning resolves). I looked in the changelog in 26/27 and
>did not see anything in there that fits this?  If your hypothesis is
>correct , I suspect quite a few people will be in for a shock when they
>deploy 7.0.27 or later into a production env where memory footprints
>are much more managed then say in eclipse on your desktop ;)
>The issue might not be with the spec, but the tomcat implementation
>where by everything is getting loaded into ram during scanning. In
>7.0.25 - I could start a "typical" Spring application in 32mb. 7.0.27
>requires 512mb? 
>- Peter
> From: Mark Thomas <>
>To: Tomcat Users List <> 
>Sent: Wednesday, April 11, 2012 6:50 AM
>Subject: Re: 7.0.25 to 7.0.27 requires -Xmx32m to go to -Xmx512m
>Pid <> wrote:
>>On 11/04/2012 03:47, Peter wrote:
>>> hey Christopher,
>>> the app I used that uncovered the issue is one I use exclusively to
>>validate tomcat releases;) it is a "hello world" style app using
>>spring/servlet3.0. it has simple spring aop point cutting via jamon ,
>>simple spring jms (active mq) simple spring jaxrs, simple spring
>>simple spring mvc, simple spring security,... (spring 3.0.7)
>>> bunch of very simple examples that end up pulling in "many" jars.
>>Can you post it to github or somewhere public?
>>> I will grab a dump tomorrow,  thanks for response,
>>> peter
>I know exactly where this memory is going. During the scanning process
>Tomcat has to scan every single class in the application and its
>libraries and every class and interface in that class's hierarchy for
>annotations (we don't have a choice in this - the spec requires it).
>This can lead to the same class being scanned many times during startup
>and that is slow. Tomcat now caches the result of scanning a class
>which means each class only has to be scanned once. However, this does
>mean that all the results are in memory until the scan is complete. If
>you have a lot of libraries, that could require a lot of memory. If you
>know a JAR doesn't need scanning, add it to the jarsToSkip property. If
>it is a popular jar then create an enhancement request and we'll add it
>to the default list. The other option is to set metadata complete in
>the web.xml
>I haven't reviewed the scanning caching code but there may be some
>opportunities to reduce the memory footprint of the cache.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

The specification requires that every class and its hierarchy is scanned for annotations when
the web app start. It was the Spring folks complaining about the slow start time when we didn't
cache anything during the scan process.

As I have said before:
- If you don't need to scan jars, add them to the skip list. If they are common jars tell
us what they are and we'll add them.
- If you do need to scan them the memory usage is the price you pay for fast startup. I have
not reviewed the cache code to see if it could be more efficient.


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

View raw message