https://issues.apache.org/bugzilla/show_bug.cgi?id=56713
--- Comment #2 from Mark Thomas <ma...@apache.org> --- Remy highlighted the potential problems of pausing requests during reload (large numbers of threads blocking waiting for the reload) and I agree that this could be a problem. However, the only user complaints we have had about this feature is that it wasn't working or that it could work better. No-one has complained about large numbers of threads blocking. Givent that no-one has complained about large numbers of blocked threads on reloads, I am wondering if there is really a problem here that needs fixing. Regarding the questions on proposed solution: How is this going to work if it is the ROOT context that is being reloaded? (1) a) and d) have obvious issues. I'd suggest configuration on the host with the ability to override it on the context if desired (2) There might not be a ROOT application (there should be but there might not). How is the Context going to be re-registered once it has started? I don't think any user is not going to want the context to be available eventually. (3) Presumably the Context eventually starts and then is shutdown. I was about to say that there are lots of complexities here - just like automatic deployment that led to producing this page: http://tomcat.apache.org/tomcat-8.0-doc/config/automatic-deployment.html Reading that it occurred to me that really what we are talking about here is the difference between reloading and redeploying. Would it not be simpler to leave this in the hands of the system administrator? They can choose whether to redploy or reload (if reload is an option for the change they want to make). One thing we could do is add some logging to notify the system admin that threads have been blocked and that they can use redeploy to avoid this. I was thinking along the lines of one log message the first time a thread was blocked and then further messages every TBD (15?, background thread?) seconds giving the current number of waiting threads until the context is reloaded. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
