[
https://issues.apache.org/jira/browse/THRIFT-5239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lewis Jackson updated THRIFT-5239:
----------------------------------
Description:
This issue is very similar to the Java one documented here:
https://issues.apache.org/jira/browse/THRIFT-970
.NET Core supports using an
_[IHttpClientFactory|https://docs.microsoft.com/en-us/aspnet/core/fundamentals/http-requests?view=aspnetcore-3.1]_
to request instances of HttpClient. This factory will pool clients to avoid
exhausting sockets in the OS. Microsoft currently do not recommend creating a
new _HttpClient_ per request, consumers currently have to find a way to pool
Thrift clients in order to conform to this practice.
The line which instantiates a new _HttpClient_ can be found
[here|https://github.com/apache/thrift/blob/283410126ccb3ac4990045e07cccb5df11ee2a16/lib/netstd/Thrift/Transport/Client/THttpTransport.cs#L141].
This proposal would require a new constructor which allowed an instance of
_HttpClient_ to be passed in. The consumer could use this constructor like this:
{code:c#}
var httpClientFactory = serviceProvider.GetService<IHttpClientFactory>();
var httpClient = httpClientFactory.CreateClient("thrift");
var transport = new THttpTransport(httpClient);
{code}
After registering their own named _IHttpClientFactory_ in the
_ServiceCollection_:
{code:c#}
var certificates = GetCertificates();
services.AddHttpClient("thrift", c =>
{
c.BaseAddress = new Uri("https://foo.bar/Service.thrift";);
c.DefaultRequestHeaders.Accept.Add(new
MediaTypeWithQualityHeaderValue("application/x-thrift"));
c.DefaultRequestHeaders.AcceptEncoding.Add(new
StringWithQualityHeaderValue("deflate"));
c.DefaultRequestHeaders.AcceptEncoding.Add(new
StringWithQualityHeaderValue("gzip"));
c.DefaultRequestHeaders.Add("CUSTOM-HEADER", "HEADER-VALUE");
})
.ConfigurePrimaryHttpMessageHandler(() =>
{
var handler = new HttpClientHandler()
{
AutomaticDecompression = System.Net.DecompressionMethods.Deflate |
System.Net.DecompressionMethods.GZip
};
handler.ClientCertificates.AddRange(certificates);
return handler;
});
{code}
Rather than relying on users to properly configure request headers and
decompression methods themselves, an extension method to _ServiceCollection_
could be defined:
{code:c#}
services.AddThriftHttpClient("thrift", uri, customRequestHeaders, userAgent,
certificates);
{code}
This would more closely match the current constructor of _THttpTransport_.
We've forked the _THttpTransport_ file to support this behaviour for internal
purposes, so I could put up a sample PR if requested.
was:
This issue is very similar to the Java one documented here:
https://issues.apache.org/jira/browse/THRIFT-970
.NET Core supports using an
_[IHttpClientFactory|https://docs.microsoft.com/en-us/aspnet/core/fundamentals/http-requests?view=aspnetcore-3.1]_
to request instances of HttpClient. This factory will pool clients to avoid
exhausting sockets in the OS. Microsoft currently do not recommend creating a
new _HttpClient_ per request, consumers currently have to find a way to pool
Thrift clients in order to conform to this practice.
The line which instantiates a new _HttpClient_ can be found
[here|https://github.com/apache/thrift/blob/283410126ccb3ac4990045e07cccb5df11ee2a16/lib/netstd/Thrift/Transport/Client/THttpTransport.cs#L141].
This proposal would require a new constructor which allowed an instance of
_HttpClient_ to be passed in. The consumer could use this constructor like this:
{code:c#}
var httpClientFactory = serviceProvider.GetService<IHttpClientFactory>();
var httpClient = httpClientFactory.CreateClient("thrift");
var transport = new THttpTransport(httpClient);
{code}
After registering their own named _IHttpClientFactory_ in the
_ServiceCollection_:
{code:c#}
var certificates = GetCertificates();
services.AddHttpClient("thrift", c =>
{
c.BaseAddress = new Uri("https://foo.bar/Service.thrift";);
c.DefaultRequestHeaders.Accept.Add(new
MediaTypeWithQualityHeaderValue("application/x-thrift"));
c.DefaultRequestHeaders.AcceptEncoding.Add(new
StringWithQualityHeaderValue("deflate"));
c.DefaultRequestHeaders.AcceptEncoding.Add(new
StringWithQualityHeaderValue("gzip"));
c.DefaultRequestHeaders.Add("CUSTOM-HEADER", "HEADER-VALUE");
})
.ConfigurePrimaryHttpMessageHandler(() =>
{
var handler = new HttpClientHandler()
{
AutomaticDecompression = System.Net.DecompressionMethods.Deflate |
System.Net.DecompressionMethods.GZip
};
handler.ClientCertificates.AddRange(certificates);
return handler;
});
{code}
Rather than relying on users to properly configure request headers and
decompression methods themselves, an extension method to _ServiceCollection_
could be defined:
{code:c#}
services.AddThriftHttpClient("thrift", uri, customRequestHeaders, userAgent,
certificates);
{code}
This would more closely match the current constructor of _THttpTransport_.
We've forked the _THttpTransport _ file to support this behaviour for internal
purposes, so I could put up a sample PR if requested.
> THttpTransport should support passing in an HttpClient
> ------------------------------------------------------
>
> Key: THRIFT-5239
> URL: https://issues.apache.org/jira/browse/THRIFT-5239
> Project: Thrift
> Issue Type: Bug
> Components: netstd - Library
> Reporter: Lewis Jackson
> Priority: Major
>
> This issue is very similar to the Java one documented here:
> https://issues.apache.org/jira/browse/THRIFT-970
> .NET Core supports using an
> _[IHttpClientFactory|https://docs.microsoft.com/en-us/aspnet/core/fundamentals/http-requests?view=aspnetcore-3.1]_
> to request instances of HttpClient. This factory will pool clients to avoid
> exhausting sockets in the OS. Microsoft currently do not recommend creating a
> new _HttpClient_ per request, consumers currently have to find a way to pool
> Thrift clients in order to conform to this practice.
> The line which instantiates a new _HttpClient_ can be found
> [here|https://github.com/apache/thrift/blob/283410126ccb3ac4990045e07cccb5df11ee2a16/lib/netstd/Thrift/Transport/Client/THttpTransport.cs#L141].
> This proposal would require a new constructor which allowed an instance of
> _HttpClient_ to be passed in. The consumer could use this constructor like
> this:
> {code:c#}
> var httpClientFactory = serviceProvider.GetService<IHttpClientFactory>();
> var httpClient = httpClientFactory.CreateClient("thrift");
> var transport = new THttpTransport(httpClient);
> {code}
> After registering their own named _IHttpClientFactory_ in the
> _ServiceCollection_:
> {code:c#}
> var certificates = GetCertificates();
> services.AddHttpClient("thrift", c =>
> {
> c.BaseAddress = new Uri("https://foo.bar/Service.thrift";);
> c.DefaultRequestHeaders.Accept.Add(new
> MediaTypeWithQualityHeaderValue("application/x-thrift"));
> c.DefaultRequestHeaders.AcceptEncoding.Add(new
> StringWithQualityHeaderValue("deflate"));
> c.DefaultRequestHeaders.AcceptEncoding.Add(new
> StringWithQualityHeaderValue("gzip"));
> c.DefaultRequestHeaders.Add("CUSTOM-HEADER", "HEADER-VALUE");
> })
> .ConfigurePrimaryHttpMessageHandler(() =>
> {
> var handler = new HttpClientHandler()
> {
> AutomaticDecompression = System.Net.DecompressionMethods.Deflate |
> System.Net.DecompressionMethods.GZip
> };
> handler.ClientCertificates.AddRange(certificates);
> return handler;
> });
> {code}
> Rather than relying on users to properly configure request headers and
> decompression methods themselves, an extension method to _ServiceCollection_
> could be defined:
> {code:c#}
> services.AddThriftHttpClient("thrift", uri, customRequestHeaders, userAgent,
> certificates);
> {code}
> This would more closely match the current constructor of _THttpTransport_.
> We've forked the _THttpTransport_ file to support this behaviour for internal
> purposes, so I could put up a sample PR if requested.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
