Hi Mark, ahh missed that - I just tried, you are right, it seems to give exactly what we want... closing connections on next incoming request when possible and otherwise waiting for the shutdown to complete. Thanks a lot and have a nice weekend.
- M Den fre. 18. nov. 2022 kl. 18.49 skrev Mark Thomas <ma...@apache.org>: > On 18/11/2022 17:40, M. Thiim wrote: > > Hi Mark, sorry I'm not sure what you mean by "read the rest of the > > thread"... My "I just tried this..." was in response to your suggestion > of > > using the bindOnInit and gracefulStopAwaitMillis parameters. Thx! > > The behaviour you describe is consistent with bindOnInit="true". It > needs to be false for this to work. > > Mark > > > > > > > > > > Den fre. 18. nov. 2022 kl. 18.35 skrev Mark Thomas <ma...@apache.org>: > > > >> Please read the rest of the thread. > >> > >> On 18/11/2022 17:24, M. Thiim wrote: > >>> Hi Mark, > >>> > >>> thanks, I just tried this. It does cause the server to insert a 20 > second > >>> delay on shutdown and I get this message in the log: > >>> > >>> 18-Nov-2022 18:16:29.777 INFO [main] > >>> org.apache.coyote.AbstractProtocol.awaitConnectionsClose Waiting > [20,000] > >>> milliseconds for existing connections to ["http-nio-8080"] to complete > >> and > >>> close. > >>> > >>> The server keeps responding to further requests on the > >>> established connections, but it also sends back headers as if in > >>> non-shutdown mode: > >>> > >>> Keep-Alive: timeout=20 > >>> Connection: keep-alive > >>> > >>> Thereby informing the client of the full 20 sec. keepalive timeout, > >> making > >>> it think it can keep using the connection - so the client ends up > getting > >>> the same error just with a 20 second delay... In fact, the server even > >>> accepts completely new connections during the graceful shutdown period > >>> period. > >>> > >>> Br, M. Thiim > >>> > >>> Den fre. 18. nov. 2022 kl. 14.34 skrev Mark Thomas <ma...@apache.org>: > >>> > >>>> On 17/11/2022 19:39, M. Thiim wrote: > >>>>> Hi, > >>>>> > >>>>> We have observed that Tomcat doesn't gracefully close > >>>>> keep-alive connections. Tomcat waits for already started requests to > >>>>> complete, but once those are done, Tomcat will close all connections > >>>>> immediately, irrespective of any configured keepAliveTimeout. This > >> causes > >>>>> problems for some HTTP clients, especially in Kubernetes-like > >>>> environments > >>>>> when scaling down pods. Here, it can only work gracefully if the HTTP > >>>>> client who falls victim to an unexpectedly closed connection retries > >> on a > >>>>> fresh connection, and it is not all clients that do this. > >>>>> > >>>>> I would think that an entirely graceful shutdown sequence, in the > >>>> presence > >>>>> of keep-alive connections, would work like the following: > >>>>> > >>>>> 1) Server receives shutdown request > >>>>> 2) Server immediately stops accepting new connections (already > happens) > >>>>> 3) Server completes all requests already in (already happens) > >>>>> 4) New behavior: If new requests come in on already established > >>>> keep-alive > >>>>> connections those are processed, but a "Connection: close" is > returned > >> so > >>>>> the client knows this connection can no longer be used. So at most > one > >>>> more > >>>>> request can be processed on each of those existing connections. > >>>>> 5) New behavior: When all keep-alive connections are gone, shutdown > >>>>> proceeds. If there are still connections left after the > >> keepAliveTimeout > >>>>> has passed, this means no requests can have been received on those > >> during > >>>>> the shutdown period (otherwise they would have been closed in #4). > And > >>>>> since Tomcat returned the keep-alive timeout value to the client when > >> the > >>>>> connection was setup, the client should know that the connection is > no > >>>>> longer usable. Therefore it is from this point safe for Tomcat to > close > >>>>> those remaining connections. > >>>>> 6) Rest of server shutdown continues > >>>> > >>>> Seems a reasonable addition. > >>>> > >>>> It looks like extending the behaviour when gracefulStopAwaitMillis is > >>>> set on the Service would work. > >>>> > >>>> gracefulStopAwaitMillis would need to be greater than or equal to the > >>>> keep-alive timeout but we can document that as part of the patch. > >>>> > >>>> Mark > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >>>> For additional commands, e-mail: dev-h...@tomcat.apache.org > >>>> > >>>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: dev-h...@tomcat.apache.org > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
