[
https://issues.apache.org/jira/browse/HTTPCLIENT-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18016197#comment-18016197
]
Sanghwa Min commented on HTTPCLIENT-2388:
-----------------------------------------
Hi [Oleg|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=olegk],
Thanks for the clear feedback.
My suggestion was on the predictable race condition from a known server idle
timeout.
I appreciate the clarification on `closeIdle`. My initial thought was to handle
this avoidance automatically within the connection request flow itself, rather
than requiring a manager thread or a manual call. I understand your concern
about supporting two different mechanisms, especially since the end result is
largely the same.
On the builder default, I'll open a pull request for builder defaults.
Thank you,
Sanghwa
> 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
> Priority: Minor
>
> 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*
> 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. Or maybe a Filter or Predicate before
> suing the connection?
> *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, maxIdleTime
> parameters to something like `maxIdleTime.divide(2)` could be considered.
> {code:java}
> // HttpClientBuilder.build()
> final IdleConnectionEvictor connectionEvictor = new
> IdleConnectionEvictor((ConnPoolControl<?>) connManagerCopy,
> maxIdleTime.divide(2), maxIdleTime.divide(2)); {code}
> If a user set maxIdleTime to be 20s, some connections might get evicted after
> 10s, but I expect using this default feature makes max idle time to be 20s.
> 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]
