On 05/11/2019 02:51, Tim K wrote: <snip/>
> The cached JSP actually survives a tomcat restart because the work > directory still contains the cached JSP content even though the timestamp > of the class/java files appear to match that of the latest JSP file's > content. Ah. That is useful new information. It rules out the non-volatile field issue I found yesterday as the root cause (the issue has been fixed anyway for the next round of releases). I'll take another look at the source. This looks like some sort of concurrency issue. In your test environment, how likely is it that: - there are concurrent (or at least very close together) changes to a JSP - that there are concurrent requests for a modified JSP? Also, what process are you using to update the JSP content? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
