-
Notifications
You must be signed in to change notification settings - Fork 921
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
Provide a way to terminate unfinished requests after graceful shutdown #5941
base: main
Are you sure you want to change the base?
Conversation
Motivation: Unfinished requests even after graceful shutdown period are forcivily closed with `ClosedSessionException`. As `ClosedSessionException` indicates that the connection was unexpectedly disconnected, `ClosedSessionException` is not suitable for graceful shutdown. In this PR, I propose to add `ShuttingDownException` to terminate unfinished requests when a server stops. Modifications: - Introduce `GracefulShutdown` to customize graceful shutdown behavior. - Users can specify a error function to create an exception to unfinished terminate requests. - Fixed `HttpServerHandler` to send error responses using the error function of `GracefulShutdown` - Fixed `Server` to send error respones first and then close the connnections. - Deprecation) `ServerConfig.gracefulShutdownQuietPeriod()` and `ServerConfig.gracefulShutdownTimeout()` have been deprecated in favor of `ServerConfig.gracefulShutdown()`. Result: You can now use `GracefulShutdown` to terminate unfinished requests when a server stops. ```java GracefulShutdown gracefulShutdown = GracefulShutdown .builder() .quietPeriod(Duration.ofSeconds(10)) .timeout(Duration.ofSeconds(15)) .shutdownErrorFunction((ctx, req) -> { return new ServerStopException(); }) .build(); Server .builder() .gracefulShutdown(gracefulShutdown); ```
/** | ||
* Returns the quiet period to wait for active requests to go end before shutting down. | ||
* {@link Duration#ZERO} means the server will stop right away without waiting. | ||
*/ | ||
Duration quietPeriod(); | ||
|
||
/** | ||
* Returns the amount of time to wait before shutting down the server regardless of active requests. | ||
* This should be set to a time greater than {@code quietPeriod} to ensure the server shuts down even | ||
* if there is a stuck request. | ||
*/ | ||
Duration timeout(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we make this even more flexible rather than just letting a user configure the quiet period and timeout? For example:
interface GracefulShutdown {
...
// Armeria core passes its GracefulShutdownHandler to this method.
void startGracefulShutdown(GracefulShutdownHandler handler);
}
// A GracefulShutdown implementation calls back Armeria core via this handler.
interface GracefulShutdownHandler {
void gracefulShutdownStarted(...);
void quietPeriodComplete(...);
void gracefulShutdownComplete(...);
@Nullable
Throwable toException(ctx, req);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall, left a minor question on thread safety when closing connections
for (Channel ch : children) { | ||
final HttpServerHandler serverHandler = ch.pipeline().get(HttpServerHandler.class); | ||
if (serverHandler != null) { | ||
closeFutures.add(serverHandler.shutdown(ch)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is called from the startStopExecutor
, which breaks the assumption that HttpServerHandler#cleanup
is called from the event loop assigned to the channel.
Is this intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch, it was my mistake.
if (bossGroups.isEmpty()) { | ||
finishDoStop(future); | ||
return; | ||
shutdownServerHandlers().handle((unused3, unused4) -> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understood now, that requests are closed with an exception once before closing the socket directly.
As a result, users will see more 503
responses instead of connection resets
.map(DecodedHttpRequest::whenResponseSent) | ||
.toArray(CompletableFuture[]::new); | ||
CompletableFuture.allOf(futures).handle((unused0, unused1) -> { | ||
completionFuture.complete(null); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: checked that the order of completing the future vs. close the encoder doesn't really matter as 1) pipeline requests are aborted above 2) the timing of closing the keepAliveHandler
doesn't really matter
Changed the target milestone to 1.32.0. I need some time to figure out how to implement the API that Trustin suggested. |
Motivation:
Unfinished requests even after graceful shutdown period are forcibly closed with
ClosedSessionException
. AsClosedSessionException
indicates that the connection was unexpectedly disconnected,ClosedSessionException
is not suitable for graceful shutdown.In this PR, I propose to add
ShuttingDownException
to terminate unfinished requests when a server stops.Modifications:
GracefulShutdown
to customize graceful shutdown behavior.HttpServerHandler
to send error responses using the error function ofGracefulShutdown
Server
to send error respones first and then close the connnections.ServerConfig.gracefulShutdownQuietPeriod()
andServerConfig.gracefulShutdownTimeout()
have been deprecated in favor ofServerConfig.gracefulShutdown()
.Result:
You can now use
GracefulShutdown
to terminate unfinished requests when a server stops.