tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <>
Subject Re: 7.0.25 to 7.0.27 requires -Xmx32m to go to -Xmx512m
Date Fri, 13 Apr 2012 02:09:32 GMT
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 jaxws,
>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:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message