Bug 43741 - .tag files in a .tar recompiled for each .jsp -- extremely slow (with fix)
Summary: .tag files in a .tar recompiled for each .jsp -- extremely slow (with fix)
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Jasper (show other bugs)
Version: 6.0.9
Hardware: All All
: P2 major (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2007-10-30 21:10 UTC by Anthony Berglas
Modified: 2008-02-21 14:42 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Anthony Berglas 2007-10-30 21:10:48 UTC
Jasper is *extremely* slow at compiling .tag files packaged in a .jar -- tens 
of seconds per JSP. One cause is that .tag files are repeatedly recompiled for 
each .jsp even though they have not changed.

The following few lines fix this.  The added code is marked between // --------
 AJB markers.  
It effectively turns off the timestamp checking on .jar files.

This does NOT actually introduce a bug.  There is an existing bug in that .jsp 
files are not 
automatically recompiled if any .tags in .jars are changed.  So you need to 
purge work in either case.  
A proper fix would be to check dependencies properly, at least to the .jar 
file itself.  
But the current fix is *much* better that the existing behavior.

There are better solutions, but an 80% solution is better than no solution.

// Tomcat 6.0.10 Src deployed version.

public class JspCompilationContext {...

    public void compile() throws JasperException, FileNotFoundException {

        // ------------ begin AJB
        // Hack to stop .tag files that are packaged in .jars being recompiled 
for every single .jsp that uses them.
        // The hack means that .tag files will not be automatically recompiled 
if they change -- you need to delete work area.
        // But that was actually an existing bug -- .jsps are not dependent on 
the .tag .jars so the work area needed deleting anyway.
        // (Outstanding is to compile multiple .tags in one pass and so make 
the process Much faster.)
        boolean outDated;
        if (isPackagedTagFile) outDated = ! new File(getClassFileName()).exists
        else outDated = jspCompiler.isOutDated();
//        AjbLog.log("### Compiler.compile " + jspUri + " pkgTagFile " + 
isPackagedTagFile + " outDated " + outDated + " " + getClassFileName());
        if (outDated) {
//     if (isPackagedTagFile || jspCompiler.isOutDated()) { // original code.
//     ---------------- end AJB
            try {
                jspLoader = null;
            } catch (JasperException ex) {
                // Cache compilation exception
                throw ex;
            } catch (Exception ex) {
                JasperException je = new JasperException(
                // Cache compilation exception
                throw je;
Comment 1 Mark Thomas 2008-01-07 15:52:21 UTC
I'd much rather fix the cause than the symptom. The proper fix for this will be
to implement the enhancement described in bug 43742.

I'll check the code to see if the JSP -> JAR dependency has been fixed (and if
it hasn't - fix it) but if you have a bug number that would save me some time.
Comment 2 Mark Thomas 2008-01-29 15:17:14 UTC
I have looked at this some more.

I think your patch is pretty much spot on. Generally, if a JAR changes, the app
needs to be re-loaded (eg using reloadable or watched resources). That is true
for any other JAR and I don't see why it shouldn't be true for JARs containing
tag files.

Compiling tags in a single pass (bug 43742) would also help.

Bug 43878 will also contribute to poor performance, although in a different way.

Your patch has been applied to trunk and proposed for 6.0.x.
Comment 3 Mark Thomas 2008-02-01 14:33:24 UTC
My relaoding comment is wrong. The app needs to be redployed (ie the work dir
cleared as pointed out in the original report). I have reverted the patch and am
working on one that handles tags in JARs.
Comment 4 Mark Thomas 2008-02-04 15:01:56 UTC
I have a proper fix for this now:

It has been committed to trunk and proposed for 6.0.x
Comment 5 Mark Thomas 2008-02-21 14:42:19 UTC
This has been committed to 6.0.x and will be in 6.0.17 onwards.