-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[HTTP/3] Re-add QuicStream.ShutdownWriteCompleted #56939
Comments
Tagging subscribers to this area: @dotnet/ncl Issue DetailsI think Kestrel needs In a graceful server shutdown:
The problem is there is a race between completing the final requests and closing the connection. We need to know that the data sent with the final requests was successfully received BEFORE we call QuicConnection.CloseAsync. If response data is still inflight to the client, and CloseAsync is called, the close notification could arrive at the client before the data. The close notification will abort all streams and the client gets the error "Connection aborted error (256)" instead of a successfully completed request. I have a test that reproduces this scenario. Most of the time the draining request completes successfully, but 10% of the time there is a "Connection aborted error (256)" error.
|
I'm not sure what you mean here by "the client also calls complete", can you clarify? Assuming that you are completing or aborting the read on the server side, then ShutdownCompleted is not waiting for the client to complete anything, because the read is already completed and/or aborted.
Can you post or link the code? |
PR: dotnet/aspnetcore#34968
|
Had a discussion with @geoffkizer about this and I'm going to change Kestrel to rely on the client to complete a graceful close. There is a timer on host shutdown that will forcefully terminate the server after 5 seconds. Closing for now. |
I think Kestrel needs
QuicStream.ShutdownWriteCompleted
to successfully handle a graceful server shutdown.In a graceful server shutdown:
The problem is there is a race between completing the final requests and closing the connection. We need to know that the data sent with the final requests was successfully received BEFORE we call QuicConnection.CloseAsync.
If response data is still inflight to the client, and CloseAsync is called, the close notification could arrive at the client before the data. The close notification will abort all streams and the client gets the error "Connection aborted error (256)" instead of a successfully completed request.
QuicStream.ShutdownWriteCompleted
would allow the server to wait until it knows the client has received data before callingQuicConnection.CloseAsync
.ShutdownCompleted
is not appropriate because we don't want to consider streams alive until the client also calls complete.Basically, please revert #55981
I have a test that reproduces this scenario. Most of the time the draining request completes successfully, but 10% of the time there is a "Connection aborted error (256)" error.
The text was updated successfully, but these errors were encountered: