In https://bz.apache.org/bugzilla/show_bug.cgi?id=57251, Mark Thomas wrote:
> The fix for bug 57472 might shave a few seconds of the deployment time but > it doesn't appear to make a significant difference. > > The fundamental problem when running from a packed WAR is that to access any > resource in a JAR, Tomcat has to do the following: > - open the WAR > - get the entry for the JAR > - get the InputStream for the JAR entry > - Create a JarInputStream > - Read the JarInputStream until it finds the entry it wants > > This is always going to be slow. > > The reason that it is fast in Tomcat 7 and earlier took some digging. In > unpackWARs is false in Tomcat 7, it unpacks the JARs anyway into the work > directory and uses them from there. Performance is therefore comparable with > unpackWARs="true". Has anyone looked into using a NIO2 FileSystem for this? It may offer a way to avoid having to stream the entry in order to be able to locate a resource. ZipFile is fast, I believe, because it has random access to the archive and can seek directly to an entry's location based on the zip index; the jar: FileSystem seems to be able to do the same. However, neither can cope with nested entries: ZipFile because its constructor takes a File rather than a Path and uses native code, and ZipFS because it relies on URIs and can't cope with a jar: URI based on another jar: URI (ye olde problem with jar: URL syntax). What a FileSystem can do differently is return a FileChannel which supports seek operations over the archive's content. IOW, if ZipFS can work given a random access channel to bytes on disk, the same approach could be adopted with a random access channel to bytes on a virtual FileSystem. I imagine that would get pretty hairy for write operations but fortunately we would not need to deal with that. If no-one’s looked at it yet I'll take a shot. Cheers Jeremy FWIW, this could also be exposed to web applications e.g. FileSystem webappFS = servletContext.getFileSystem(); Path resource = webappFS.getPath(request.getPathInfo()); Files.copy(resource, response.getOutputStream());
signature.asc
Description: Message signed with OpenPGP using GPGMail
