[
https://issues.apache.org/jira/browse/HTTPCLIENT-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17822032#comment-17822032
]
Oleg Kalnichevski commented on HTTPCLIENT-2323:
-----------------------------------------------
> Do you think this should be called once per application run...
Yes, i do.
> or multiple times? I am saying you need to call it multiple times in order to
> alter the connection pool settings.
You are wrong.
> Are you saying you can call that once and never call it again while still
> altering the connection pool used?
Yes, I am.
> Besides this particular point... is it truly the ideal design for the apache
> http client to resort to the classloader to determine a default user agent?
> Can this not be calculated once? Or in less resource-intensive way? Are we
> losing something by rethinking this code?
Given this is supposed to used be very infrequently I see no point caching the
default user agent value. Again, there is nothing stopping you from caching and
re-suing it in your code.
Truly, I do not understand what else I need to say
{code:java}
final PoolingHttpClientConnectionManager cm =
PoolingHttpClientConnectionManagerBuilder.create()
.build();
try (CloseableHttpClient httpclient = HttpClients.custom()
.setConnectionManager(cm)
.build()) {
for (final URIScheme uriScheme : URIScheme.values()) {
final ClassicHttpRequest request = ClassicRequestBuilder.get()
.setHttpHost(new HttpHost(uriScheme.id, "httpbin.org"))
.setPath("/headers")
.build();
System.out.println("Executing request " + request);
// Apply config dynamically
cm.setConnectionConfigResolver(route -> {
// Use different settings for all secure (TLS) connections
if (route.isSecure()) {
return ConnectionConfig.custom()
.setConnectTimeout(Timeout.ofMinutes(2))
.setSocketTimeout(Timeout.ofMinutes(2))
.setValidateAfterInactivity(TimeValue.ofMinutes(1))
.setTimeToLive(TimeValue.ofHours(1))
.build();
} else {
return ConnectionConfig.custom()
.setConnectTimeout(Timeout.ofMinutes(1))
.setSocketTimeout(Timeout.ofMinutes(1))
.setValidateAfterInactivity(TimeValue.ofSeconds(15))
.setTimeToLive(TimeValue.ofMinutes(15))
.build();
}
});
cm.setTlsConfigResolver(host -> {
// Use different settings for specific hosts
if (host.getSchemeName().equalsIgnoreCase("httpbin.org")) {
return TlsConfig.custom()
.setSupportedProtocols(TLS.V_1_3)
.setHandshakeTimeout(Timeout.ofSeconds(10))
.build();
} else {
return TlsConfig.DEFAULT;
}
});
httpclient.execute(request, response -> {
System.out.println("----------------------------------------");
System.out.println(request + "->" + new StatusLine(response));
EntityUtils.consume(response.getEntity());
return null;
});
}
}
{code}
Oleg
> When using HttpClientBuilder without setting a user agent an expensive
> operation seems to be used
> -------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-2323
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2323
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
> Affects Versions: 4.5.12, 5.3.1
> Environment: Docker image using maven:3.9.1-eclipse-temurin-17-focal
> running in kubernetes. Spring boot 2.7.x.
> Reporter: Rob
> Priority: Minor
> Attachments: Screenshot 2024-02-28 at 12.51.41 PM.png
>
>
> We have an application that has a fairly high outbound http call rate using
> Apache Http Client. We have been profiling it recently using the async
> profiler and I noticed that almost 10% of our cpu time is spent in
> VersionInfo.getUserAgent.
> We use HttpClientBuilder for each call (this seems the correct way to be able
> to use different connection pools and settings).
> I am guessing because we do not explicitly set the user agent that the client
> will go determine the client version and java version and use this... the
> automatically generated user agent in our case looks like:
> {code:java}
> User-Agent: Apache-HttpClient/4.5.12 (Java/17.0.7){code}
> I have attached the profiler flame graph. I would imagine something like this
> could be checked once and used for any further calls. I have not tested it
> yet but I am hoping a workaround would be to make sure to set a user agent
> and then none of this classloader stuff would need to happen for each call.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
