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 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)
Date Thu, 22 Sep 2005 22:13:19 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=33453>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33453





------- Additional Comments From remm@apache.org  2005-09-23 00:13 -------
(In reply to comment #21)
> I would also prefer a solution where information about the JSP is saved and
> later compared. Would JspServletWrapper be the right place to save the original
> JSP modification time?

Nope, people can restart the container.

> MD5 would be nice, but then md5 checksum would need to be recalculated on every
> JSP check with unchanged file time, so unfortunately not a rare case. I guess
> that's too bad for performance.

Arg MD5.

> Maybe timestamp and size would be enough, because both can be retrieved easy and
> efficiently, and if timestamp did not change, but content did change, it is very
> likely, that the file was in progress of being written to, so at least size
> should have changed.

This is simple, and maybe acceptable, but would make the cost of checking for
recompilation (even) more expensive than it is right now.

> One last word: I had customers having problems with both scenarios: rolling back
> file changes, but also distributing content with wrong timestamps (future time)
> and in consequence continuous recompilation for several minutes. Not trying to
> assume a simple time model seems to make jasper more robust.

On access compilation and its friend the development mode - which you are using
or you would not have this "issue" - should not be used in production (the only
reason why it is not as bad as it used to be is that I tweaked it do do only one
check at most per page per time interval - obviously if there are 100 pages, my
trick will not work that well).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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


Mime
View raw message