You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2018/08/08 14:46:28 UTC
[Bug 62603] Changes in tag files are not reflected in the rendered
view or they end up with a java.lang.NoClassDefFoundError
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org