On 17/02/2022 19:50, Christopher Schultz wrote:


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.


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to