-
Notifications
You must be signed in to change notification settings - Fork 10.3k
HTTP/3: Response drain timeout #35322
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
Conversation
b69ff34
to
6aba457
Compare
src/Servers/Kestrel/Core/src/Internal/Infrastructure/ITimeoutControl.cs
Outdated
Show resolved
Hide resolved
@@ -415,6 +426,11 @@ private void ShutdownWrite(Exception? shutdownReason) | |||
|
|||
public override async ValueTask DisposeAsync() | |||
{ | |||
if (_stream == null) | |||
{ | |||
return; |
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 scares me considering DisposeAsync() pools. Does this mean something could still have a reference to the QuicStreamContext and dispose it after pooling? Maybe we should move the pooling logic outside of DisposeAsync since this is exposed to connection middleware and DisposeAsync() can be called multiple times.
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 added that when I was considering a design that wasn't as safe. I quickly decided that it wasn't a good idea. This was leftover from the first attempt. Do you want it removed?
When a QUIC stream is disposed of the callback removes it from the connection before it is pooled. And only gracefully completed requests are pooled. No active request will be using a pooled stream.
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.
What happens if connection middleware disposes the ConnectionContext before exiting?
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.
If the app (which is Kestrel HTTP/3 implementation in this case) hasn't completed the pipes then it isn't pooled.
aspnetcore/src/Servers/Kestrel/Transport.Quic/src/Internal/QuicStreamContext.cs
Lines 418 to 422 in a079651
CanReuse = _stream.CanRead && _stream.CanWrite | |
&& _transportPipeReader.IsCompletedSuccessfully | |
&& _transportPipeWriter.IsCompletedSuccessfully | |
&& !_clientAbort | |
&& !_serverAborted; |
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.
But third-party middleware could complete the Pipes, right? Sorry to randomize this PR. I do not think the pooling logic needs to be reworked before merging this. And I'll admit this likely isn't the most likely scenario. It's just seeing this got me thinking about pooling too early, and if it did become a problem, it might be very hard to diagnose.
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.
Yes.
There has to be some public API and condition at which point the context is pooled. Whatever we use, there is the ability for someone to use the public API to trigger pooling early.
6aba457
to
d760ea4
Compare
7d92975
to
915a99b
Compare
381711f
to
d7d880b
Compare
d7d880b
to
7557071
Compare
/backport to release/6.0-rc1 |
Started backporting to release/6.0-rc1: https://github.com/dotnet/aspnetcore/actions/runs/1146342601 |
@JamesNK backporting to release/6.0-rc1 failed, the patch most likely resulted in conflicts: $ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: HTTP/3 response drain timeout
Using index info to reconstruct a base tree...
M src/Servers/Kestrel/Transport.Quic/src/Internal/QuicStreamContext.cs
M src/Servers/Kestrel/Transport.Quic/test/QuicStreamContextTests.cs
Falling back to patching base and 3-way merge...
Auto-merging src/Servers/Kestrel/Transport.Quic/test/QuicStreamContextTests.cs
CONFLICT (content): Merge conflict in src/Servers/Kestrel/Transport.Quic/test/QuicStreamContextTests.cs
Auto-merging src/Servers/Kestrel/Transport.Quic/src/Internal/QuicStreamContext.cs
CONFLICT (content): Merge conflict in src/Servers/Kestrel/Transport.Quic/src/Internal/QuicStreamContext.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 HTTP/3 response drain timeout
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128 Please backport manually! |
- backport of #35322 to release/6.0-rc1
* Update dependencies from https://github.com/dotnet/efcore build 20210821.6 (#35617) Microsoft.EntityFrameworkCore.Tools , dotnet-ef , Microsoft.EntityFrameworkCore , Microsoft.EntityFrameworkCore.SqlServer , Microsoft.EntityFrameworkCore.InMemory , Microsoft.EntityFrameworkCore.Relational , Microsoft.EntityFrameworkCore.Sqlite , Microsoft.EntityFrameworkCore.Design From Version 6.0.0-rc.1.21420.45 -> To Version 6.0.0-rc.1.21421.6 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> * Update docker container to mcr (#35630) Co-authored-by: Brennan <[email protected]> * [release/6.0-rc1] Update dependencies from dotnet/runtime dotnet/efcore (#35634) [release/6.0-rc1] Update dependencies from dotnet/runtime dotnet/efcore * [release/6.0-rc1] HTTP/3: Response drain timeout (#35492) - backport of #35322 to release/6.0-rc1 * [release/6.0-rc1] Reliability improvement for input date E2E tests (#35616) * Reliability improvement for input date E2E tests * Avoid "collection was modified" error in CircuitGracefulTerminationTests * Avoid timing issues in CanFocusDuringOnAfterRenderAsyncWithFocusInEvent * Update src/Components/test/E2ETest/Tests/FormsTest.cs Co-authored-by: Tanay Parikh <[email protected]> * Remove notes from earlier Co-authored-by: Steve Sanderson <[email protected]> Co-authored-by: Tanay Parikh <[email protected]> * Minimal APIs naming cleanup * Add Support for `DateOnly` & `TimeOnly` for `SupplyParameterFromQuery` Fixes: #35525 API Proposal: #35567 * Add FailureReasons (#35425) * Add support for Results extension point Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Brennan <[email protected]> Co-authored-by: James Newton-King <[email protected]> Co-authored-by: Steve Sanderson <[email protected]> Co-authored-by: Tanay Parikh <[email protected]> Co-authored-by: Stephen Halter <[email protected]> Co-authored-by: Tanay Parikh <[email protected]> Co-authored-by: Hao Kung <[email protected]> Co-authored-by: Safia Abdalla <[email protected]> Co-authored-by: Doug Bunting <[email protected]>
Fixes #29702