Bug 23406

Summary:	Jasper should use file size as well as date for recompile check
Product:	Tomcat 4	Reporter:	Martin van Dijken <mvdijken>
Component:	Servlet & JSP API	Assignee:	Tomcat Developers Mailing List <dev>
Status:	RESOLVED WONTFIX
Severity:	enhancement
Priority:	P3
Version:	4.1.24
Target Milestone:	---
Hardware:	Other
OS:	Linux

Description Martin van Dijken 2003-09-25 08:37:10 UTC

I have a very strange problem and it is almost unreproducable. If someone would
like to help me isolate the issue I'd be much abliged. I'm willing to do the
research work on it, but need a few hints where to look. The following happens: 

We have an index.jsp which jsp:includes a menu.jsp. The menu.jsp is a relatively
large plain text file. The menu.jsp is generated every night at midnight to
reflect the changes of the day. Some days when we come in, the menu only shows
partially. Other days the whole menu is shown.

When checking the generated java and class files everything seems to be in
order. The index.jsp has a JspRuntimeLibrary.include where the jsp:include was
and the menu.jsp, menu_jsp.java and menu_jsp.class(decompiled to check) all
resemble the new state. The index.jsp shows itself entirely, however only a part
of the included html is shown. If the menu.jsp is recreated manually everything
works again.

A sidenote to this bug is that it only seems to occur with larger includes (this
example is 1300 lines). Other sites we've created use the same method of
including and menu generation with smaller menus and they have no problem.

Comment 1 Tim Funk 2003-09-25 11:07:52 UTC

[PURE SPECULATION]

You are seeing a race condition. While the file (menu.jsp) is being generated to
its destination - a request is made for it. During this sime time, a request is
made for the file. The file is read incompletely by the JSP compiler, and the
write happens quick enough that all of this occurs in the same second so the JSP
engine does not detect a file change. 

I have seen this on tomcat404. You have 3 workarounds:
1) If its a plain text file, just call it menu.txt. This also saves some
overhead of a JSP.
2) Generate the file to a temporary area on the same disk. Then use a file copy
from/to local disk.
3) Tweak the jsp to force a compile error of itself if it is not complete. A
simple brace <% { %> at the top of the file then closing brace at the bottom
should work.

It would be nice for Jasper to store the file size and date to perform its
checks for situations such as this.

Comment 2 Mark Thomas 2005-07-26 23:08:42 UTC

With no further comment on this bug I am going to assume that Tim's speculation
was correct. There are a number of very simple work-arounds so I am going to set
this as an enhancement request and change the summary accordingly.

Comment 3 Mark Thomas 2010-09-03 04:47:02 UTC

*** This bug has been confirmed by popular vote. ***

Comment 4 Mark Thomas 2011-02-22 15:41:04 UTC

I've been reviewing this one again. The bit that confuses me is that the menu_jsp.class file contains the latest version but clearly the version loaded by the class loader is an older version. The timestamp checks that take place are in milliseconds and a quick text shows that there is reasonably fine granularity with these.

It does look like a race condition but one that I can't figure out given the current code. There have been changes to Jasper post 4.1.x (increased synchronisation, switch to the Eclipse compiler, improved dependency checking) and I don't recall any similar issues in 5.5.x onwards.

Given the above, it isn't very satisfactory but I am going to resolve this as WONTFIX an the assumption that this was a 4.1.x bug that was fixed in 5.5.x onwards by the various changes.