On 17/02/2022 19:50, Christopher Schultz wrote:
<snip/>
This kind of thing could happen due to a number of different reasons,
such as a slow disk or network share, etc. and ought to be
protected-against.
I haven't looked at the code, but I would imagine it periodically reads
all relevant files looking for anything that's been updated, but
immediately acts the first time is finds someting worth triggering a
reload.
It does. The periodic check is triggered by the background process.
It might make more sense to modify that logic so that *all* files are
checked, but we cancel the reload if there are any files that are "too
new". This would allow us to avoid a reload if some kind of copy is in
progress. So we are looking for "anything newer than
last_reload_timestamp but not if we find anything older than NOW - 10
seconds".
Yes. We do something similar when checking for an update WAR file. Ten
seconds might be a little on the high side.
Would you be interested in looking at the existing algorithm to see if
it would be updated in this way?
WebappLoader.backgroundProcess() would be a good place to start.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
