[ 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: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org