On 07/03/2015 18:13, Jeremy Boynes wrote: > I interpret that to mean that there is pretty constant time taken to > inflate 15MB of data - the 300ms to scan the archive and the ~350ms > to scan each of the jars within (each one that was used at least). > The speed up here comes because we only scan each archive once, the > downside is the extra memory used to store the inflated data.
Do you mean the entire entire deflated WAR is in memory? If we wanted to go that way it is fairly easy to do with the existing WebResource implementation. > In general, I don’t think there’s a need for the FileSystem to retain > inflated data after the channel is closed. Agreed. When to cache or not should be left to WebResources. > However, I think the WAR ClassLoader would benefit from keeping the > JAR files on the classpath open to avoid re-inflating them. That isn't an option unless you can solve the locked file problem on Windows. It always has to be possible to delete the WAR on the file system to trigger an undeployment. > The > pattern though would be bursty e.g. lots of class loads during > startup followed by quiescence. I can think of two ways to handle > that: 1) FileSystem has maintains a cache of inflated entries much > like a disk filesystem has buffers The FileSystem would be > responsible for evictions, perhaps on a LRU or timed basis. See comments above on caching. 2) Having > the classloader keep the JARs opened/mounted after loading a resource > until such time as it thinks quiescence is reached. It would then > unmount JARs to free the memory. See comments above on locked files. There are good reasons why the Tomcat 7 and earlier solution was to extract the JARs to the work directory. That might still be the neatest solution with that dir then mounted to WEB-INF/lib as a pre-resource. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
