Sanghwa Min created HTTPCLIENT-2388:
---------------------------------------
Summary: Idle connection management features
Key: HTTPCLIENT-2388
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2388
Project: HttpComponents HttpClient
Issue Type: Wish
Reporter: Sanghwa Min
Hello,
I'm leaving some thoughts as I have a couple of ideas for improving Apache
HttpClient that came to mind while coordinating its settings with our server's
idle timeout.
*1. Proactively Avoiding Stale Connections with a discardAfterInactivity
Setting*
The validateAfterInactivity setting is very useful for preventing stale
connections. However, it does not offer a complete guarantee of avoiding a
NoHttpResponseException due to a potential race condition.
A connection can pass its validation check (which involves a brief socket read)
but be terminated by a server or a network appliance in the small window of
time before the actual HTTP request is sent. This issue can occur even when a
user is aware of the server's idle timeout and configures the client settings
accordingly, which makes it a fundamental challenge to solve with validation
alone.
Considering the inherent challenges with validation discussed in
HTTPCLIENT-2142, perhaps a more direct approach could be offered for common use
cases. For instance, when a user knows the server's idle timeout, what if we
provided a setting like `discardAfterInactivity`? This would allow them to
simply discard connections that have been idle beyond a specified threshold
without attempting to validate them.
*2. the Predictability of evictIdleConnections*
The convenience method HttpClientBuilder.evictIdleConnections(maxIdleTime) can
produce a somewhat unexpected result regarding its eviction schedule.
Internally, it instantiates an IdleConnectionEvictor by setting its sleepTime
(the check interval) to be the same value as maxIdleTime. This leads to a
situation where a connection can remain idle for nearly 2 * maxIdleTime
(sleepTime + maxIdleTime) before being closed. This behavior may not align with
what a user might expect from a parameter named maxIdleTime.
I might be missing something, but to make this behavior more predictable and
align better with user expectations, would it be possible to use a shorter
check interval by default? For instance, setting the sleepTime parameter to
something like `maxIdleTime.divide(2)` could be considered.
Thank you for considering.
Sanghwa
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
