[
https://issues.apache.org/jira/browse/HTTPCLIENT-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18016772#comment-18016772
]
ASF subversion and git services commented on HTTPCLIENT-2388:
-------------------------------------------------------------
Commit ddd2d58f38dbf6d198554a9c6a280eeb11b02f17 in httpcomponents-client's
branch refs/heads/master from Sanghwa Min
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=ddd2d58f3 ]
HTTPCLIENT-2388: fix builder default evictor sleepTime min 1 second
> 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
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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]
