https://issues.apache.org/bugzilla/show_bug.cgi?id=57472
Bug ID: 57472
Summary: performance (classloader?) problems with signed jars
in WEB-INF/lib
Product: Tomcat 8
Version: 8.0.17
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: ole.schulz-hildebra...@ppimedia.de
cf.
http://mail-archives.apache.org/mod_mbox/tomcat-users/201501.mbox/%3CADA7A9443C47CC4E9C065E9C84C6891D6B3994A3B7%40ex01.ppinet.de%3E
After moving one of our web applications from Tomcat 7 to Tomcat 8 (8.0.17,
Java 1.8.0_25, CentOS 6) 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 many 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.
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.
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 ;-))?
If neccessary I can provide the mentioned 8mb self-signed jar of the
jython-library and/or create a simple sample web application that demonstrates
the issue.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
