Hello,
Thank you for the provided information. My implementation contains logic that 
cleans expired connections every 10 seconds. To verify the correct timeout 
value, I checked the default logic in the HttpClientBuilder, which cleans both 
expired and idle connections. As far as I can see, this is implemented in the 
IdleConnectionEvictor thread (see links below):
https://github.com/apache/httpcomponents-client/blob/master/httpclient5/src/main/java/org/apache/hc/client5/http/impl/IdleConnectionEvictor.java#L56
 
https://github.com/apache/httpcomponents-client/blob/master/httpclient5/src/main/java/org/apache/hc/client5/http/impl/classic/HttpClientBuilder.java#L1118
You mentioned in your response that the timeout for expited connections 
cleaning should not be less than one minute. However, in the 
IdleConnectionEvictor, the default timeout is 5 seconds if no value is 
specified. Additionally, if evictIdleConnections is not configured, the timeout 
defaults seems to be 1 second.
Could you please provide more details on what the timeout value should be?
Best regards, Angel

________________________________
From: Oleg Kalnichevski <[email protected]>
Sent: Saturday, January 10, 2026 1:18 PM
To: HttpClient User Discussion <[email protected]>
Subject: Re: Request for enhancement of Apache HTTP Client debug logs

On Thu, 2026-01-08 at 15:48 +0000, Vardin. Angel wrote:
> Hello,
>
> I enabled the HttpComponents Client 5.5 logs to show DEBUG and TRACE
> output for the package "org.apache.hc.client5.http.impl.io" in order
> to get detailed HTTP/1.1 I/O information.
>
> During testing, I noticed that when the log severity is set to DEBUG,
> many log entries appear that would ideally belong at the TRACE level.
> For example, the logs were flooded with the following entry, which
> provides very limited information:
>
> https://github.com/apache/httpcomponents-client/blob/master/httpclient5/src/main/java/org/apache/hc/client5/http/impl/io/PoolingHttpClientConnectionManager.java#L606
>
> I also reviewed the codebase and could not find many TRACE-level log
> statements.
>
> Is there any plan to improve the logging granularity in the future?
>

No, there are no such plans. The verbosity and granularity of logging
is subjective and we cannot please everyone.

TRACE priority is not being used mostly because it is not consistently
supported by all logging frameworks and back-ends.

Regarding the example referenced above, this is actually a pretty bad
case because if your code calls #closeExpired method more often than
once a minute, something is very wrong.

Oleg

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to