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

Oleg Kalnichevski commented on HTTPCLIENT-1493:
-----------------------------------------------

I see. However, please note the compatibility code (check every time) will 
still be present at the client level and does not need to be implemented in the 
connection pool. 

Does this kind of check make sense in general? I kind of doubt.

Oleg

> Conditional stale connection checking
> -------------------------------------
>
>                 Key: HTTPCLIENT-1493
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1493
>             Project: HttpComponents HttpClient
>          Issue Type: New Feature
>            Reporter: Sebb
>             Fix For: 4.4 Final
>
>
> Stale connection checking is expensive. At present if it is enabled, it is 
> performed for every connection. This is quite expensive and generates 
> additional requests.
> One reason for a server to drop a connection is when the connection has been 
> idle for a while. Some servers send Keep-Alive headers to inform the client 
> of this; if they don't, then the client will see an unexpected disconnection. 
> Stale connection checking avoids this problem, but at the cost of additional 
> requests. When a connection is not busy, this is acceptable, but for a busy 
> connection the checks are mostly unnecessary.
> Another reason for dropping a connection is after it has been reused many 
> times. The server should send a connection close as part of the final 
> response, but if it does not, a stale check would help.
> For these reasons, it would be useful to be able to implement conditional 
> stale connection checking, based on connection idle time and/or connection 
> reuse count. These conditions should be optionally selectable.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to