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 ;-))? Best regards Ole +++ ?ber 5.000 Ausgaben t?glich +++ Mehr als 100 Medienh?user weltweit produzieren t?glich Zeitungen und digitale Angebote mit ppi Media L?sungen +++ Over 5,000 editions daily +++ More than 100 media companies worldwide produce newspapers and digital products with ppi Media's solutions. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
