-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Allow HttpClient instances to be refreshed periodically #4673
Conversation
In dotnet/runtime#22366 we found that if HttpClient is using the curl handler it will lead to TCP connections bleeding. Our DefaultConnectionLimit is very restrictive if this is true. Our check however is too lenient and will default to true always on .NET core since netcoreapp still ships with CurlHandler as recent as `3.1.x`
This commit updates the implementation of determining if a conservative default connection limit should be set by also checking if CurlHandler exists when UseSocketsHttpHandler exists and is disabled.
I finally found where to remove |
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 left some small comments 👍
src/Elasticsearch.Net/Connection/HandlerTracking/RequestDataHttpClientFactory.cs
Outdated
Show resolved
Hide resolved
src/Elasticsearch.Net/Connection/HandlerTracking/RequestDataHttpClientFactory.cs
Outdated
Show resolved
Hide resolved
src/Elasticsearch.Net/Connection/HandlerTracking/RequestDataHttpClientFactory.cs
Show resolved
Hide resolved
src/Elasticsearch.Net/Connection/HandlerTracking/RequestDataHttpClientFactory.cs
Show resolved
Hide resolved
src/Elasticsearch.Net/Connection/HandlerTracking/LifetimeTrackingHttpMessageHandler.cs
Show resolved
Hide resolved
src/Elasticsearch.Net/Connection/HandlerTracking/ExpiredHandlerTrackingEntry.cs
Show resolved
Hide resolved
src/Elasticsearch.Net/Connection/HandlerTracking/ActiveHandlerTrackingEntry.cs
Show resolved
Hide resolved
Co-Authored-By: Russ Cam <russ.cam@elastic.co>
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-6.x 6.x
# Navigate to the new working tree
cd .worktrees/backport-6.x
# Create a new branch
git switch --create backport-4673-to-6.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick 4c340e87d4fb633593783a812ac867ac56313375
# Push it to GitHub
git push --set-upstream origin backport-4673-to-6.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-6.x Then, create a pull request where the |
This comment has been minimized.
This comment has been minimized.
Co-Authored-By: Russ Cam <russ.cam@elastic.co> (cherry picked from commit 4c340e8)
6.x does not follow the new layout so a cherry-pick is to involved. Manually reimplemented the same logic that introduces `RequestDataHttpClientFactory` to periodically recycle HttpClient instances.
Relates: #4673 This commit adds the Clients property back to HttpConnection ,for binary compatibility, with an ObsoleteAttribute applied to indicate that the property is no longer used.
Relates: #4673 This commit adds the Clients property back to HttpConnection ,for binary compatibility, with an ObsoleteAttribute applied to indicate that the property is no longer used.
Relates: #4673 This commit adds the Clients property back to HttpConnection ,for binary compatibility, with an ObsoleteAttribute applied to indicate that the property is no longer used.
Relates: #4673 This commit adds the Clients property back to HttpConnection ,for binary compatibility, with an ObsoleteAttribute applied to indicate that the property is no longer used. Co-authored-by: Russ Cam <russ.cam@elastic.co>
…roduced in #4673 (#4848) Specifically: https://github.com/elastic/elasticsearch-net/pull/4673/files#diff-6c7514b4a5a813d5985444b99a4f7a4fL167 Co-authored-by: Martijn Laarman <Mpdreamz@gmail.com>
…roduced in #4673 (#4847) Specifically: https://github.com/elastic/elasticsearch-net/pull/4673/files#diff-6c7514b4a5a813d5985444b99a4f7a4fL167 Co-authored-by: Martijn Laarman <Mpdreamz@gmail.com>
This PR fixes a longstanding wish to be able to recycle
HttpClient
instances periodically. We reuse HttpClient/HttpMessageHandler's to prevent TCP leakage but infamously this does not take DNS changes into account.IHttpClientFactory
from Microsoft.Extensions.Http solves this but the nuget package depends on too many things we don't want to depend on OOTB like Dependency Injection. This copies parts of this code (now MIT licensed as of February) so we can reuse the same strategy in the client.Starting with
netstandard2.1
SocketsHttpHander
also supportsPooledConnectionLifetime
this however has a bug in corrolation withMaxConnectionsPerServer
. This is fixed innetcoreapp3.0
and up.The goal is to ship this new
RequestDataHttpClientFactory
introduced here in all TFM's.In a follow up commit we'll introduce
netcoreapp3.0
andnetcoreapp3.1
TFM's that will only useRequestDataHttpClientFactory
to createHttpClient
instances but won't use its recycling capabilities since that's now handled byPooledConectionLifetime
.