Bug 15417 - Add port for forced compilation of JSP pages
Summary: Add port for forced compilation of JSP pages
Status: RESOLVED DUPLICATE of bug 33453
Alias: None
Product: Tomcat 4
Classification: Unclassified
Component: Unknown (show other bugs)
Version: Unknown
Hardware: Other other
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2002-12-16 20:49 UTC by Gus Heck
Modified: 2010-12-17 09:14 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Gus Heck 2002-12-16 20:49:58 UTC
I havn't actually had a problem with it yet, but it seems like anyone who
figures out that a site is using a heavyweight jsp page, could mount a
substantial CPU utilization DOS by sending lots of jsp_precompile requests.

It seems that there should be a way to turn it of on production servers.
Discussion on IRC seems to indicate that there is currently no way to turn it
off. (One of the individuals claimed that he was reading the source and couldn't
find any facility for disabling it).

An alternate/additional idea to jsp_precompile is to replace this feature with
one that allows the server configuration to specify a port number to open in
parallel to the main port, but force a recompile for every access on that port.
(and then send back the newly compiled page to the developer, unlike
jsp_precompile) This could easily be controled at the firewall level by blocking
access to that port, and disabled (never enbabled?) for a production server.

The need for such a feature comes up when (for example) one goes from working on
a HEAD revision to working on a branch where the file mod times can get older.
You don't want to see the version left over from the newer HEAD when you attempt
to view your work in the branch. In this case you actually want to recompile
when the file got older, making an always recompile interface useful.
Comment 1 Gus Heck 2002-12-16 21:54:15 UTC
Jason Brittain helped me find this missing feature (jason_brittain@yahoo.com)
and wishes some credit in the matter. Credit is definately due, as he explained
jsp_precompile to me :) (I had been entirely confused by it's name, jsp_compile
would have made a lot more sense to me)
Comment 2 Gus Heck 2002-12-16 21:56:22 UTC
(he is also the one who was reading the source code)
Comment 3 Kin-Man Chung 2002-12-16 22:33:44 UTC
A request to a page with jsp_precompile option is just like the request without
the option, except that the request is not delivered, i.e.
http://foo.bar.jsp?pre_compile is not more expensive that http://foo.bar.jsp. 
The compilation is done only once, and if the JSP page has been compiled, the
compilation won't happen.  Therefore I fail to see how this can be used as a DOS

A production application should precompile all JSP pages, and that will reduce 
jsp_precompile to a nop.

A more useful server option is probably one that tells it that the JSP pages in
an application have been precompiled, and that it should not have to check for
the time stamps for the pages and their servlet files.  This might improve the
performance of the pages somewhat.
Comment 4 Gus Heck 2002-12-17 07:09:48 UTC
Ok but my requested enhancement still stands even if there is no DOS attack.

I did further direct testing of various timestamps/request combinations, and I 
had begun to suspect that it was in fact as you described.

However as noted here, and in the end comment of bug 14165 version control 
systems can provide "updated" versions of files with older time stamps. It 
seems unreasonable that developers should have to maually (or with a script) 
touch JSP pages just to view a coherent set of pages when moving between 
branches, or from Trunk to Branch. 

I am reopening with a new summary title because I am requesting a feature that 
allows forced recompilation of pages for every load, preferably simply by 
accessing them on a second port. 

This is my rational for this suggestion stated another way:

As a developer I am quite willing to wait compilation time to see a page I am 
testing correctly. Waiting for compilation is something we all acknowledge as 
being part of the business. My suggetion provides a developer oriented 
interface. A developer generally doesn't care how fast the page loads (within 
reason). If it isn't loading the code he just wrote, or just checked out of 
the repository, it is worse than useless, it is confusing.

One of the worst maifestations of this is that a Developer checks out the 
branch B, edits foo.jsp and fixes a typo in bar.jsp. Then the next week the 
developer needs to make changes to Branch A, which contains an older older 
version of bar.jsp than B. The developer is editing barhelp.html in branch A 
and wants to make links and add text relating to bar.jsp.

The problem is that since tomcat has cached bar.jsp when the developer was 
working on B (last week) when he looks at bar.jsp in his browser he gets the 
Branch B version of it even though he hasn't worked on branch B for a week. So 
basing his changes on what he sees in his browser, the developer edits 
barhelp.html, commits his changes, and as far as he can see all the links work 
and all the wigits he mentions are there. Of course when it gets moved to a 
new (read production) server, the cached pages have all been carefully cleared 
as part of a release procedure or are empty because it is a fresh install, 
suddenly barhelp.html turns out to have broken links to sections of bar.jsp 
that don't exist in the A version and talk about wigits that only exist in the 
B version.

An extreme example, perhaps, but the point is it is really quite confusing to 
delete your entire directory, checkout a whole different branch, (perhaps even 
restart tomcat for good measure), and find yourself looking at a mix of pages 
from two different branches.

The newest version of each file among all branches you have ever worked on is 
what you see when you browse around a devlopment server, unless you regularly 
delete the contents of the work directory or give up on having sensible 
modification dates and write a file touching script.
Comment 5 Gus Heck 2002-12-17 16:55:21 UTC
I have also discovered that because version systems retain the mod date of the
file, one can update from an older branch to a newer branch and still have this
problem because the files in the newer branch are older than the day you were
working on the older branch, and therefore older than the classfiles. 

Can you honestly tell me this isn't confusing :) Sure be nice if I could spend
my brain cycles writing code rather than keeping track of what tomcat is doing
to my branches.
Comment 6 Mark Thomas 2010-12-17 09:14:37 UTC

*** This bug has been marked as a duplicate of bug 33453 ***