DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=40572>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40572 Summary: Performance problem with org.apache.catalina.loader and JAXP, JSP Product: Tomcat 4 Version: 4.1.30 Platform: All OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The toString() methods on org.apache.catalina.loader package classes WebappLoader, WebappClassLoader, StandardClassLoader and Extension all produce extensive strings. In addition, some of these classes invoke each other and produce additional StringBuffer copies. I recommend inhibiting this debug construction unless a flag is set. The reasoning follows: In doing performance tests with JSP and XML, I have found that Sun's implementation of JAXP uses a factory locator pattern that eventually makes multiple calls classLoader.toString(), as a result of doing a string concatenation in a call to a debug function, and this calculation is expensive and is done repeatedly. The JAXP code in Sun's Java implementation of JAXP discards this string unless -Djaxp.debug is set, although it calculates the value anyway. (In a separate action, I have filed a bug with Sun over the JAXP implementation and asked them to follow good practice and not invoke classLoader.toString() unless the debug flag is set.) Typically, the classLoader.toString() method is invoked once per factory creation and again once each time the factory is used. While the JAXP interface recommends that factories be located once per application, seldom does anyone do this, with the result that this expense is paid twice each time an XML operation (parsing, XSLT transofmration, etc.) is used. The result is that calls to factories in javax.xml.parsers, javax.xml.transform, javax.xml.xpath, and java.xml.validation are slower and allocate more memory than expected. As an example, see org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument and note that it does DocumentBuilderFactory().newInstance().newDocumentBuilder().parse, and that results in two calls to classloader.toString for each JSP page parsed. While this may not be the proper technique suggested by Sun, it is indeed what developers do, even inside Tomcat. Even if Sun fixes the JAXP implementation not to invoke classLoader.toString needlessly, it may also be valuable to provide control in Catalina over the extent (and expense) of debugging information provided by these classloaders, because it is not clear to many developers that the simple calculation ("classloader is " + cl) is expensive. To see how often this is called, use a Java debugger and place a breakpoint in org.apache.catalina.loader.WebappClassLoader.toString(), and examine the number of calls, the context, and the size of the calculated value. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
