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 <ma...@apache.org> To: Tomcat Users List <users@tomcat.apache.org> Sent: Wednesday, April 11, 2012 6:50 AM Subject: Re: 7.0.25 to 7.0.27 requires -Xmx32m to go to -Xmx512m Pid <p...@pidster.com> 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? > > >p > > >> 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
