On 06/11/2019 20:04, Mark Thomas wrote: > I've found the root cause. > > When checking the timestamps of JSPs, the JSP engine (because it has to > access all resources via the Servlet API) requests a URL for the JSP, > opens a connection to the URL and then checks the last modified time. > This goes directly to the on-disk file. > > When reading the content, the request goes via the static resource cache > because we can intercept the call to ServletContext.getResourceAsStream() > > The problem is the following sequence: > - request for JSP > - no change in JSP timestamp found > - cache re-validated (for 5s by default) > - JSP is modified (within 5s) > - request for JSP (within 5s) > - change in JSP timestamp found > - JSP content read (sees cached version rather than new version) > > So we end up with the old version of the JSP content with the updated > last modification time. > > I'm currently looking at options to return a URL for the resource where > we can intercept the call to URLConnection.getLastModified().
Fixed in: - master for 9.0.28 onwards - 8.5.x for 8.5.48 onwards Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
