On 18/02/2016 00:05, Christopher Schultz wrote: > Mark, > > On 2/17/16 5:04 PM, Mark Thomas wrote: >> On 17/02/2016 11:11, Mark Thomas wrote: >>> On 16/02/2016 22:07, Ty wrote: >>>>> Exactly which versions were you using when you ran your >>>>> tests? >>>> >>>> According to my notes: 7.0.59, which should've been the most >>>> recent version available at the time (about this time last >>>> year). >>>> >>>> To clarify: that was the version we did a heap dump analysis >>>> of, and noted the memory increase related to Manifest objects. >>>> The version used for the test procedure in this thread's >>>> original message -- last performed last week -- was 7.0.67 and >>>> we did not do a heap analysis of it (only noting that at a >>>> glance it resulted in approximately the same amount of heap >>>> increase correlating with JAR scanning as we saw with last >>>> year's version). >>> >>> Thanks for the version info. >>> >>> I've started looking at this. The bulk of the memory is used by >>> JarResourceSet. It is caching a JarFileEntry object for each >>> class in the JAR. >>> >>> I wrote this code but I don't recall why those entries were >>> retained. I need to look back through svn to figure out what >>> problem it was solving and then see if I can find a better >>> solution. > >> Quick update. > >> There are two separate issues, both triggered by JAR scanning. > >> The JarResourceSet issue above accounts for ~50% of a 1GB heap. >> There is also a WebappClassLoader issue that accounts for ~30% of >> the same heap. > >> The WebappClassLoader issue is the easier to fix. I have fixed this >> in trunk and am just waiting for the tests to confirm all is well. >> I plan to back-port this to 8.0.x for the next release. > >> The JarResourceSet is going to be trickier. The code is the way it >> is partly for performance, partly to avoid file locking on Windows. >> It is going to take a little longer to put together a fix for this >> one. > > For Ty's purposes, simply avoid JAR scanning entirely should eliminate > the heap issues, right? Moving from Tomcat 6 means that JAR scanning > is not required for correct operation of their application.
Yes. http://wiki.apache.org/tomcat/HowTo/FasterStartUp has the details of the configuration required. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
