tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Schulz-Hildebrandt, Ole" <Ole.Schulz-Hildebra...@ppimedia.de>
Subject performance (classloader?) problems with signed jars in WEB-INF/lib
Date Tue, 20 Jan 2015 11:01:59 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message