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
