[
https://issues.apache.org/jira/browse/HTTPCLIENT-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17821991#comment-17821991
]
Rob commented on HTTPCLIENT-2323:
---------------------------------
[~olegk] [~michael-o]
Thank you both for your input. A common use case for an http client is to have
a central interface that is able to handle all of the complications for calling
http services throughout an application. To do this... you often want to have
different timeouts for the connection... or use different configurations for
connection pools.
>From what I can see... once you have created a ClosableHttpClient... which
>under normal circumstances you would want to reuse... you can no longer alter
>timeouts and connection pool settings (and perhaps other configuration).
This also appears to be the same code used in 5.x which you can confirm with
little time looking at the code.
I can agree that maybe many people don't need this level of request by request
configuration... but it is not a crazy thing to expect from an http client.
Especially when many different developers are going to use it across a codebase
and you want to have a centralized client.
My particular issue could also be exacerbated by spring classloading but I have
not dug particular deep into this as I have a workaround. But I dont see why
such a potentially heavy operation is required by HttpClients built using the
builder.
> 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
> Environment: Docker image using maven:3.9.1-eclipse-temurin-17-focal
> running in kubernetes
> 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
