[jira] [Comment Edited] (HTTPCLIENT-2142) Design expressive idle connection validation support

["Michael Osipov (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17303592#comment-17303592 ] 

Michael Osipov edited comment on HTTPCLIENT-2142 at 3/17/21, 6:01 PM:
----------------------------------------------------------------------

Question: Why is it not possible to use use background thread which does a "validate while idle" (whatever idle or validate means)?
Idea: mod_proxy_http uses HTTP 100-Continue for a ping. See [{{ProxyPass}}|https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass] directive. Would that be a way to solve the problem?


was (Author: michael-o):
Question: Why is it not possible to use use background thread which does a "validate while idle" (whatever idle means)?
Idea: mod_proxy_http uses HTTP 100-Continue for a ping. See [{{ProxyPass}}|https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass] directive. Would that be a way to solve the problem?

> Design expressive idle connection validation support
> ----------------------------------------------------
>
>                 Key: HTTPCLIENT-2142
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2142
>             Project: HttpComponents HttpClient
>          Issue Type: New Feature
>            Reporter: Carter Kozak
>            Assignee: Carter Kozak
>            Priority: Major
>
> This ticket is based on a discussion from the mailing list: http://mail-archives.apache.org/mod_mbox/hc-dev/202103.mbox/%3C60fa1a2bad046869a2da9269b7e90b9484a050ca.camel%40apache.org%3E
> h3. Background
> Currently several connection managers support a validation interval for idle connections which is used to check if they're still open before attempting to send a request. The java Socket API provides no way for a client to detect if the remote side has closed a connection without attempting a blocking read operation. In my experience the most common failure is that a remote server _cleanly_ closes idle connections sooner than the client expects (either due to a low idle connection timeout or a server shutdown) resulting in failed requests and retries.
> A stale check on a java socket takes at minimum 1 millisecond due to the millisecond socket timeout resolution, and the only way (that I'm aware of) to check if a connection has been closed is to do a blocking read. A SocketTimeoutException tells us the connection is intact, while other IOExceptions suggest the connection is unusable. In many environments a 1ms check is far more expensive than the median request to a remote server and causes additional context switching.
> When the validation interval is set to a higher value to avoid performance pitfalls, idle connections may build up in the connection pool. If the remote server unexpectedly restarts, the client may need to churn through hundreds of requests burning through retries before the higher validation interval is reached or remaining connections are closed due to reaching the keepalive timeout.
> h3. Potential Ideas
> h4. Route state awareness
> Track connection health state per route such that stale checks are required before using a connection that has been idle longer than any connection that has been determined to be stale. This requires functionality to detect {{ConnectionClosedException}} and {{NoHttpResponseException}} produced by attempted requests, and send it back to the connection pool. This allows retryable requests to be executed optimistically (in cases where it's safe to do so) and only pre-validate after a failure has occurred to limit the number of retries that may be consumed.
> h4. Request-aware stale checking predicate
> Provide a configurable mechanism to force stale checks based on the incoming request, for example I may always want to validate connections before making requests to non-idempotent endpoints or when by request body is not considered repeatable, but have more risk tolerance when I'm confident a retry is possible. Perhaps also force stale connection checks for all retries. 
> h4. Alternative forms of stale checks
> We may consider making the stale-check mechanism itself configurable, a blocking read to be used, or an http2 ping when available, or even a full {{OPTIONS}} or {{HEAD}} request.
> It's not entirely clear if any of this should be shared between the classic and async clients. I think the nio interfaces provide support for the common case (cleanly closed connections) which is a deficiency of the blocking socket API.
> What do you think? Additional ideas are appreciated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org