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.
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)
(he is also the one who was reading the source code)
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 attack. 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.
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.
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.
*** This bug has been marked as a duplicate of bug 33453 ***