On Thu, Nov 7, 2019, 6:40 AM Mark Thomas <ma...@apache.org> 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 > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org
I pulled the latest code from GitHub, I see the commit related to this email thread in the log, I built from master with ant (9.0.28-dev) and I'm still experiencing the issue... I have a curl command executing every second (via watch -n1) going to a JSP while making an edit to it. I can reproduce the cached issue every 2-3 edits.
