[
https://issues.apache.org/jira/browse/HTTPCLIENT-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283702#comment-17283702
]
Oleg Kalnichevski commented on HTTPCLIENT-2136:
-----------------------------------------------
All this requires just a few tweaks at the construction time.
{code:java}
CloseableHttpClient httpclient = HttpClients.custom()
// Limit total time to live to 1 minute
.setConnectionTimeToLive(1, TimeUnit.MINUTES)
// do not keep connections alive longer than 1 second unless
// a finite keep-alive period has been communicated
// by the opposite endpoint
.setKeepAliveStrategy(new DefaultConnectionKeepAliveStrategy() {
@Override
public long getKeepAliveDuration(HttpResponse response, HttpContext
context) {
long keepAlive = super.getKeepAliveDuration(response, context);
return keepAlive >= 0 ? keepAlive : 1000;
}
})
// evict expired connections proactively
.evictExpiredConnections()
.build();
{code}
Oleg
> Idle HTTP connections remain open
> ----------------------------------
>
> Key: HTTPCLIENT-2136
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2136
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
> Affects Versions: 4.5.13
> Reporter: Linda Werner
> Priority: Minor
>
> We found out, that Apache HTTPClient sends HTTP header "Connection:
> keep-alive" by default.
> This behaviour can cause problems on some networks (e.g. Azure network).
> For our implementation we use Spring RestTemplate in combination with Apache
> HTTPClient (to support PATCH http requests). As soon as we used Apache
> HTTPClient we had trouble with some connections, but only on the Azure App
> Service (Azure network) - not locally.
> Our backend app opens connections to other services which are not closed, so
> the tcp connection remains open. The opposition sends tcp FIN after some
> minutes (5 minutes in our case), but the tcp FIN never reaches our app
> service. Something in the Azure network kills the idle tcp connection, but
> the application still holds the damaged tcp connections and tries to send
> data. With no socket read timeout implemented some unspecific time later the
> following exception occurs: "java.net.SocketException: Operation timed out
> (Read failed)". With configured socket read timeout the data read timeout
> exception occurs after the defined time, but this doesn't solve the main
> reason of the broken tcp connection.
> We found some workaround solutions like a connection pool which close idle
> connections after 3 minutes. But in our case we don't want the default
> behaviour to keep all connections open with keep-alive. Our final
> implementation is to set the HTTP header field "Connection: close".
> I think "keep-alive" is not a good default value for the HTTP header field
> "Connection".
> We heard that this issue happens on other networks (AWS), too. It seems to be
> a common practice to close idle connections in networks which use SNAT port
> allocation.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
