tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 52448] New: Cache jar indexes in WebappClassLoader to speed up resources lookup
Date Wed, 11 Jan 2012 01:39:51 GMT

             Bug #: 52448
           Summary: Cache jar indexes in WebappClassLoader to speed up
                    resources lookup
           Product: Tomcat 7
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Catalina
    Classification: Unclassified

Created attachment 28135

Here is an old draft patch for WebappClassLoader that may worth looking at
considering recent class loader discussion.

It addresses the problem with WebappClassLoader#findResourceInternal() that is
caused by these two factors:

1. The findResourceInternal method has a loop over JAR files of the web
application. To find a resource it asks each JAR file whether the resource is
present in it.

The lookup in each of JAR files should be fast, because a zip file has an index
(at the end of the file). The problem is that loading and parsing the index
into a hash table needs some time.

2. There is method WebappClassLoader#closeJARs() that closes the JARs and thus
unloads those indexes. The method is called:
- once webapp starts, in StandardContext#startInternal()
            ((WebappLoader) getLoader()).closeJARs(true);
- once in a while in background thread, WebappLoader#backgroundProcess()

The second call (force:=false) does JARs unloading once there was no activity
for 90000 msecs = 1,5 minutes (hardcoded value).

The problem is that when a web application has a lot of JARs in WEB-INF/lib,
and you have just started it. When you access its first JSP page the
WebappClassLoader has find some class or resource.

To do that it has to open all JARs and scan them for a resource (a class), even
if the resources is in only one JAR file, or not in them at all - if it comes
from the parent classloader. This opening takes time and is noticeable.

The idea in the patch is to do JAR scanning while the application starts up and
all the JARs are open (before the closeJARs(true) call) and cache the names
found in the JAR files.

The #findResourceInternal() call uses the cache to open a single JAR that
actually contains the resource.

The patch is against r922264 of tc6.0.x. It contains some remnants of
LockAwareURLClassLoader - see
Those have to be ignored. The essence is the jarEntryNames field and
openJAR(int index) method that populates it.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message