[
https://issues.apache.org/jira/browse/HTTPCLIENT-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15627336#comment-15627336
]
Anaz commented on HTTPCLIENT-1610:
----------------------------------
I have an application written using httpclient 4.5.2 that interacts with a
webservice. I have issues related to stale connection.
The persistent/keep-alive connection is getting closed by httpclient as it
received "end of stream" and creates a new connection for the subsequent
request as you can see from below logs. The delay between the 2 requests is
only 1 sec
There is another application (don't know the internal implementation) which
interacts with same webservice but still able to send and receive multiple HTTP
requests/responses in the same connection.
I don't know if my analysis so far is correct, but what it looks like is that a
connection appear stale to httpclient due to end of stream, but it is not
actually stale to other clients.
I'm using httpclient 4.5.2, Java 1.8
Please advise if anyone come across this scenario
[DEBUG] PoolingHttpClientConnectionManager - Connection request: [route:
{}->http://xx.xxx.xx.xxx:xxxx][total kept alive: 1; route allocated: 1 of 1000;
total allocated: 1 of 1000]
[DEBUG] wire - http-outgoing-0 << "end of stream"
[DEBUG] DefaultManagedHttpClientConnection - http-outgoing-0: Close connection
[DEBUG] PoolingHttpClientConnectionManager - Connection leased: [id: 1][route:
{}->http://xx.xxx.xx.xxx:xxxx][total kept alive: 0; route allocated: 1 of 1000;
total allocated: 1 of 1000]
[DEBUG] MainClientExec - Opening connection {}->http://xx.xxx.xx.xxx:xxxx
[DEBUG] DefaultHttpClientConnectionOperator - Connecting to /xx.xxx.xx.xxx:xxxx
[DEBUG] DefaultHttpClientConnectionOperator - Connection established
xx.xxx.x.x:xx<->xx.xxx.xx.xxx:xxxx
[DEBUG] DefaultManagedHttpClientConnection - http-outgoing-1: set socket
timeout to 60000
> Stale connections in pool cause NoHttpResponseException
> -------------------------------------------------------
>
> Key: HTTPCLIENT-1610
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1610
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Affects Versions: 4.4 Final
> Reporter: Oliver Henlich
> Fix For: 4.4.1
>
>
> Hi,
> A few days ago we upgraded from httpclient 4.3.6 to 4.4.
> Our application sends out webservice requests to various other servers hosted
> at our customers sites.
> We noticed that a lot of these requests were failing with the following
> NoHttpResponseException exception. Unfortunately these exceptions seemed to
> be occurring intermittently.
> On further experimentation we were able to reproduce it more reliably by
> waiting 1 minute between sending requests to the same url. This leads us to
> believe that this is potential issue with the connection pooling/re-use when
> the remote servers close/kill the connection.
> We tried but failed to create a reproducible test case to attach to this
> request.
> Notes:
> 1. CPool which is used by the default PoolingHttpClientConnectionManager does
> not override/implement validate(). Is this correct?
> 2. We noticed that since 4.4 the StaleConnectionCheck has been disabled by
> default (ClientConfiguration.java) as part of
> https://issues.apache.org/jira/browse/HTTPCLIENT-1493.
> Questions:
> 1. Is something obvious we've missed in the configuration (shown below)? How
> do we avoid stale connections resulting in NoHttpResponseExceptions.
> 2. Would it make sense to switch to the BasicHttpClientConnectionManager to
> avoid these issues. Especially since our usage of httpclient does not seem to
> require connections to be re-used in this manner.
> Cheers
> Oliver
> Configuration:
> {code}
> public CloseableHttpClient buildRegularClient() {
> SSLContext sslContext = createSSLContext();
> RequestConfig globalConfig = RequestConfig.custom()
> .setCookieSpec(CookieSpecs.IGNORE_COOKIES) // By default we
> always want to ignore cookies
> .setSocketTimeout(getReadTimeout())
> .setConnectTimeout(getConnectTimeout())
> .build();
> HttpClientBuilder httpClientBuilder = HttpClients.custom()
> .setDefaultRequestConfig(globalConfig)
> .setMaxConnTotal(MAX_CONNECTIONS)
> .setMaxConnPerRoute(MAX_CONNECTIONS_PER_ROUTE);
> httpClientBuilder.addInterceptorFirst(new
> RemoveSoapHeadersInterceptor());
> httpClientBuilder.setSslcontext(sslContext);
> httpClientBuilder.setHostnameVerifier(getHostnameVerifier());
> return httpClientBuilder.build();
> }
> {code}
> Exception:
> {noformat}
> Caused by: org.apache.http.NoHttpResponseException: server.name.com:8080
> failed to respond
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:260)
> at
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:161)
> at
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:153)
> at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:271)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123)
> at
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:254)
> at
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
> at
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
> at
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
