-
Notifications
You must be signed in to change notification settings - Fork 41.1k
Improve graceful shutdown documentation to remove ambiguity #40108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Tomcat will reject new connections and reject a request on an existing idle connection, as covered by these two tests: Line 600 in 0c036df
Line 625 in 0c036df
Jetty is similar, although not exactly the same. Like Tomcat, it will reject new connections. Unlike Tomcat, it will accept requests on an existing connection but will include a Line 314 in 0c036df
Line 338 in 0c036df
Reactor Netty will reject new connections as covered by this test: Line 152 in 0c036df
We don't have a test for its behavior when a request is made on an existing connection. Based on this information, and to answer the questions above:
Tomcat, Jetty, and Reactor Netty will all refuse new connections once graceful shutdown has begun. Tomcat will refuse a request on an existing connection and should drop the connection. Jetty will respond to a request on an existing connection and instruct the client to close the connection. Reactor Netty's behavior is unknown at the moment as we don't have a test for it.
I believe they're closed at the soonest of:
I'm not sure what we should document here as it's getting down into low-level container-specific behaviour. I think we could certainly say that new connections will be refused. We could then perhaps also say that handling of new requests on existing connections during the graceful shutdown period is web server-specific. My feeling is that saying anything more would be going into too much detail. |
Thanks for the detailed info Andy! It is very helpful. Perhaps this info could be documented in the javadocs on the webserver-specific WebServerFactory implementations. That seems like a logical place to me, since the behavior differs somewhat between implementations. The tests would then be testing documented behavior. Then the reference guide could be kept somewhat generic, but also direct the user to the WebServerFactory implementations for exact details. This approach would make the information more easily discoverable by those who need it, but not clutter up the reference guide too much. What do you think? |
I'd like for the following quote in the Graceful Shutdown documentation to be clarified...
Specifically, does "stop accepting requests at the network layer" refer to new connection requests (meaning the client would see connection refused) or new requests on existing (persistent) connections or both? If it stops accepting requests on existing connections with no requests currently being processed, are the existing connections closed immediately or after the graceful shutdown timeout?
The text was updated successfully, but these errors were encountered: