[
https://issues.apache.org/jira/browse/HTTPCLIENT-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanghwa Min updated HTTPCLIENT-2388:
------------------------------------
Description:
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, maxIdleTime
parameters to something like `maxIdleTime.divide(2)` could be considered.
{code:java}
final IdleConnectionEvictor connectionEvictor = new
IdleConnectionEvictor((ConnPoolControl<?>) connManagerCopy,
maxIdleTime.divide(2), maxIdleTime.divide(2)); {code}
Thank you for considering.
Sanghwa
was:
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, maxIdleTime
parameters to something like `maxIdleTime.divide(2)` could be considered.
```
final IdleConnectionEvictor connectionEvictor = new
IdleConnectionEvictor((ConnPoolControl<?>) connManagerCopy,
maxIdleTime.divide(2), maxIdleTime.divide(2));
```
Thank you for considering.
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 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, maxIdleTime
> parameters to something like `maxIdleTime.divide(2)` could be considered.
> {code:java}
> final IdleConnectionEvictor connectionEvictor = new
> IdleConnectionEvictor((ConnPoolControl<?>) connManagerCopy,
> maxIdleTime.divide(2), maxIdleTime.divide(2)); {code}
>
> 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]
