> Mark, > > On 11/7/19 06:40, Mark Thomas wrote: >> 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 > > Would you mind checking similar logic for triggering the reloading of > a whole context?
No at all. > I'm not sure it's happened to me in quite a while (I'm currently on > 8.5.x), but in the past I know for a fact that I've been caught in a > loop where my context will reload many many times after what feels > like one single change (e.g. one set of class file updates, a new .jar > file, etc.). Usually, if I leave things alone for a while (maybe 2 > minutes?) Tomcat will settle down and stop repeatedly reloading the > context, but I usually just kill it and restart the container because > all that reloading causes the service to perform really poorly. After > a restart, all is well. Doesn't look to be related. See HostConfig.checkResources(). The checks are all directly to the file system. Also. reloading the web application will clear the resources cache. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
