DO NOT REPLY [Bug 25528] New: - WebappClassloader does not register with RMI codebase cache

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25528>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25528

WebappClassloader does not register with RMI codebase cache

           Summary: WebappClassloader does not register with RMI codebase
                    cache
           Product: Tomcat 4
           Version: 4.1.24
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: anne@veling.nl


Using RMI with Tomcat 4+ (all 4 versions of Tomcat, 5 too) causes problems. It 
works, but performance is very bad. We have reproduced this problem and 
pinpointed it down to the WebappClassLoader in Tomcat 4. If a serialized class 
is sent back from an RMI server, the RMI classes from Sun call 
getClassAnnotation() of the classloader. If the java code is included in a JAR 
file in the WEB-INF/lib too, this classloader is the 
org.apache.catalina.loader.WebappClassloader class.

In our test cases, over 50% of the time was spent in method getURLs() of this 
loader in the following stack trace:

sun.rmi.server.MarshalOutputStream.annotateClass()
  java.rmi.server.RMIClassLoader.getClassAnnotation()
    sun.rmi.server.LoaderHandler.getClassAnnotation()
      org.apache.catalina.loader.WebappClassLoader.getURLs()
        org.apache.catalina.loader.WebappClassLoader.getURL()

The getURL() was called for EVERY time a class is deserialized, for ALL JAR 
files in the web-app (in our case 27). This is caused by the fact that in

sun.rmi.server.LoaderHandler.getClassAnnotation() a check is made if the 
ClassLoader of the class received in known in the "codebase" cache.

This can easily be fixed by adding a call to
sun.rmi.server.LoaderHandler.registerCodebaseLoader(this);

in both constructors of the WebappClassLoader. We have created an overridden 
classloader that does this and registered it in server.xml with

<Loader loaderClass="org.apache.catalina.loader.CustomClassLoader"/>

(that's a custom class inherited from WebappClassloader that simply calls the 
registration in 2 constructors)

This caused performance increase of some pages with factor of 30 or more! The 
problem gets bigger if more RMI calls are made and more JAR files are added to 
the web-app.

It seems to me that this RMI registration is simply forgotten and should be 
added to the Tomcat 4 (and 5) code.

I think this is also the resolution of Bugzilla #7359.

Probably a better way of calling this method too. You should be careful what 
happens if a non-Sun java is used. Furthermore; what happens with the Thread-
specific class loaders?

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org