https://bz.apache.org/bugzilla/show_bug.cgi?id=62603
--- Comment #1 from Mark Thomas <ma...@apache.org> --- Thanks for the clear description of a tricky issue. I've been looking at potential solutions. Having run through various scenarios my conclusion is that there is always a risk of problems if the reload flags are inconsistent across the web application. To avoid the potential problems, reloading needs to be prevented while the reload flags are being updated. I see two approaches to this: 1. In JspSrvletWrapper.getServlet() assume reload == false while the loop in JspRuntimeContext.checkCompile() is processing. 2. In JspSrvletWrapper.getServlet(), if reload == true && the loop in checkCompile() is processing pause the current request until checkCompile() completes. My main concern with approach 1 is that it is possible, with (un)lucky timing that, after a resource is modified requests for that resource arrive during a checkCompile() processing window meaning the updated version of the resource is not seen even if it was modified multiple checkInterval periods ago. I don't think this is intuitive and coudl lead to unexpected behaviour. With approach 2 the main concern is the length of the pause between the request being requested and processing starting. This is primarily driven by the time it takes to complete the checkCompile() loop. I am currently leaning towards approach 2 with some additional logging that will tell admins how long the chekcCompile() loop took to complete and how long individual requests were waiting. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
