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 [EMAIL PROTECTED] 2006-09-07 05:54 ------- (In reply to comment #55) > I believe Jasper really should remove cached JSP's from the work directory > when > an app is undeployed (or redeployed). I think this is common, important, and > quite different than the rather obscure case of rolling back an older version > from version control. This would also avoid a performance hit in checking out > of > date on JSP's and wouldn't surprise people (I wouldn't expect JSP's to be > cached > after redeploying an app, indeed I think it's surprising behavior!) This is a very good point that I would agree with. It is not upto any external tools to effectively manage the "work/" directory for Tomcat. This directory should be self-managing and be implemented on the side of caution, the caching of JSP pages is a benifit not a right. I think the following new rule would work: * The work/ directory is only cleaned of unused contexts when a web-app is undeployed (while the container is running, aka hot-undeploy) or found to no longer exist after all configuration parsing has been done at container startup. Although it is somewhat difficult to manage web-app upgrades taking place when the container is shutdown. Which I'd say was a pretty common event. One way around that situation would be to detect a web-app update has taken place. The simplest for TC (and the sys-admin) way I can think of, is for TC to remember the exact timestamp on the WEB-INF/web.xml file which the pre-compiled pages relate to. Make it create an empty file and touch up the timestamp to match the real web.xml as work/web.xml.timestamp. The sys-admin must then only touch the WEB-INF/web.xml (when he upgrades his web-app while the container is stopped). When TC boots up again it detects the timestamp is not equal and presumes the web-app was changed also, this causes a flush of the work/ for that context. The idea being this approach would be a whole lot simpler than re-validating the entire work/ cache from the source JSPs during all webapp deployments. It would be nice to have re-validation maybe that could be implemented using magic .java file comments in the japser output "// Jasper-JSP-Prerequisite: foobar/test.jsp 72383828372000" where both the top level source and all included fragments are listed with their Epoch millis for timestamp. Then the process would be to recurse the work/org/apache/ tree, reading all the .java and performing a simple stat() on the source files. This could be done in the background with live requests taking priority to be checked on first access after deployment. When work/* file that have been sucessfully revalidated (or deleted/recreated) have their timestamp updated, so that it is possible for any thread to know if a re-validation is required on a page, since the timestamp will be older than the deployment time of the web-app context. This would have no longterm JVM impact that loading classes might have, we can put what we like in the .java file and access it easily. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
