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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
