On 20/01/2015 11:01, Schulz-Hildebrandt, Ole wrote: > Hi, > > After moving one of our web applications from Tomcat 7 to Tomcat 8 > (latest 8.0.17) the time for deploying and initializing the webapp > increased by a factor of 30 (6s vs. 180s). Analyzing the problem we > found out that it had to do with a signed jar in the WEB-INF/lib of > the webapp. It is a 8mb self-signed jar of the jython-library from > which some classes are used in the initializing process of our > webapp. When using a non-signed version of the jar the time for > deploying and initializing is the same in Tomcat 8 as in Tomcat 7. > Has anyone experienced similar problems with signed jars in Tomcat > 8? > > Profiling and debugging the webapp it turned out that loading a class > (and its depending classes) from the signed jar took extremely long > with Tomcat 8 in comparison to Tomcat 7. Indeed classloading from the > signed jar seems to be responsible for most of the additional time > for initializing the webapp in Tomcat 8. Because the performance > problems do not occur with a non-signed version of the jar this > additional time is probably spent in verifying the signatures of the > jar. Because there seems to be no way to disable the verification of > jars in general in Tomcat I took a look at the sources of the new > WebappClassLoader of Tomcat 8. > > The following is just a hypothesis of a "Tomcat source newbie": Could > it be that (at least some parts of) the verification process for the > whole signed jar is done again and again each time a class from a > signed jar is loaded? Looking at > org.apache.catalina.webresources.JarResource:47 > (http://svn.apache.org/repos/asf/tomcat/tc8.0.x/trunk/java/org/apache/catalina/webresources/JarResource.java) > a new instance of java.util.jar.JarFile is created each time a single > class-file is read from the jar. Thus the following call of > jarFile.getInputStream(jarEntry) in JarResource:50 causes a call of > JarFile.initializeVerifier() (cf. JarFile:442ff in > http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/util/jar/JarFile.java). > JarFile.initializeVerifier() seems to do some precalculations > (hashing?) for all files listed in the manifest of the signed jar > (cf. JarFile:365ff). Thus each time a single class is loaded from a > signed jar precalculations for all class files in the signed jar seem > to be done. Could this be the reason for our performance problems > (especially in connection with a 8mb signed jar ;-))?
That sounds possible. (I haven't looked at the code to check the theory though.) Please open a Bugzilla issue for this so it doesn't get lost. I assume your web application is loading a lot of classes from that signed JAR when it starts? Cheers, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
