tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 8290] New: - Problem in the code generated by jasper 2
Date Fri, 19 Apr 2002 02:31:13 GMT
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=8290>.
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=8290

Problem in the code generated by jasper 2

           Summary: Problem in the code generated by jasper 2
           Product: Tomcat 4
           Version: Nightly Build
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Jasper 2
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: benoitde@sympatico.ca


There is a big performance penalty incured by the way the code is generated 
with taglibs in both Jasper and Jasper 2.  Both version use a lot of nested 
try/finally block, and these constructs triggers a bug in the JVM.  This 
bug is documented there:

http://developer.java.sun.com/developer/bugParade/bugs/4414162.html

It was closed as "not fixed" for the JDK 1.3, but it is still present at 
least in the 1.4 Linux's implementation, and probably others too:
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

We did some light load test and if a page has 100 tags, a 256M JVM can not 
sustain the load.  The GC would periodically freeze the JVM from 10s. to 
45s. on a PIII 800 with 512M.  The load is a 5 thread JMeter test of 
accessing the "large" JSP (100 tags), with a small JSP (only links), and a 
500ms timer sleep.  No other access are done on the PC, JMeter is run from 
a remote PC.

In our tests, we have shown that by far the worst performance penalty are 
due to this bug.  If we only put a global "try/finally" in the java code 
generated from the JSP and recompile by hand the java code, then the 
performance are very much comparable to other servlet servers.

Thanks.

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


Mime
View raw message