-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Fix polling on https connections in HttpConnectionPool #49474
Conversation
Tagging subscribers to this area: @dotnet/ncl Issue DetailsFixes #49431 Avoid performing read-aheads on such connections, which can result in long-pinned buffers and unnecessary exceptions when the connections are torn down. cc: @geoffkizer, @scalablecory
|
48c65ec
to
e345db3
Compare
Avoid performing read-aheads on such connections, which can result in long-pinned buffers and unnecessary faulted tasks when the connections are torn down.
e345db3
to
1e478eb
Compare
Actually, before you merge this: TLS can send alerts out of band from stream data right @wfurt? Presumably this "check that we haven't received anything" would fail with this change. |
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.
LGTM. I'm wondering if long-term we can use the 0-read @geoffkizer recently fixed. It is somewhat sad that using Stream has negative impact.
If the alert is coming from remote side, then yes. It can come at any time. That can be close notification or the peer did not like something we sent. Typically that also terminates the connection shortly after. We can also generate alert on our side as result of error condition. My assumption this generally moves back to state we already had before NetworkStream.Socket was available, right @stephentoub ? |
This moves us back to the state we were in for .NET 3.1: all http and https connections, except for those via proxy tunnels, poll the underlying socket for connections in the pool. With this change, we'll now also do it if a NetworkStream is returned from ConnectCallback (which obviously wasn't available in 3.1). |
Even if such an alert happens, it seems like the worst case here is a race condition where we try to use a connection that's about to be closed and then we end up needing to retry... but such a race condition already exists, which is why we already have said retry code. Yes? |
If the only thing an alert can be used for is an error condition then lets merge away 👍. Do we know that TLS 1.3 is the same @wfurt? |
src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpConnectionPool.cs
Outdated
Show resolved
Hide resolved
…andler/HttpConnectionPool.cs Co-authored-by: Cory Nelson <phrosty@gmail.com>
yes in regard to alerts. The biggest changes were in TLS handshake. |
/backport to release/5.0 |
Started backporting to release/5.0: https://github.com/dotnet/runtime/actions/runs/644747685 |
@stephentoub backporting to release/5.0 failed, the patch most likely resulted in conflicts: $ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix polling on https connections in HttpConnectionPool
error: sha1 information is lacking or useless (src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpConnection.cs).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 Fix polling on https connections in HttpConnectionPool
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! |
Fixes #49431
Avoid performing read-aheads on such connections, which can result in long-pinned buffers and unnecessary exceptions when the connections are torn down.
cc: @geoffkizer, @scalablecory