On Mar 8, 2015, at 9:53 AM, Mark Thomas <ma...@apache.org> wrote: > > 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.
It does in this quick and dirty version as I wanted to get a sense of what was possible i.e. does the API support the access patterns needed. The rest of the email is exploring ways to avoid that. > >> 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. Remember, it would be opening files on the virtual filesystem not the underlying OS so we can control the locking behaviour. IIRC, part of the problem is that ZipFile uses mmap to access the file which requires a lock on Windows; we may not want to do that (or it could an OS-specific behavioral options). --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
