Summary: | Limit time that incoming request waits while webapp is reloading | ||
---|---|---|---|
Product: | Tomcat 8 | Reporter: | Konstantin Kolinko <knst.kolinko> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | NEW --- | ||
Severity: | enhancement | ||
Priority: | P2 | ||
Version: | 8.0.9 | ||
Target Milestone: | ---- | ||
Hardware: | PC | ||
OS: | All | ||
Attachments: | 2014-07-15_tc8_56713_v1.patch |
Description
Konstantin Kolinko
2014-07-12 15:52:04 UTC
(In reply to Konstantin Kolinko from comment #0) > a) MapperListener shall notify Mapper that the context has been paused. The > Mapper shall remember the "paused" state. That part of API was implemented r1610220, as it was needed to fix bug 56710. 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. Created attachment 31814 [details]
2014-07-15_tc8_56713_v1.patch
An idea of a patch to illustrate the proposal.
The wait time is hard-coded to be 2 minutes.
This one is for the current trunk (at 1610400)
Reload is a development oriented feature, and the wait feature in that case is a convinience (basically, you can hit the browser's reload button without having to check the reload is finished). I doubt this feature is in meaninglful use in any other situation. |