You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Ondrej Burkert (JIRA)" <ji...@apache.org> on 2016/06/17 10:40:05 UTC
[jira] [Comment Edited] (HTTPCLIENT-1610) Stale connections in pool
cause NoHttpResponseException
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335847#comment-15335847 ]
Ondrej Burkert edited comment on HTTPCLIENT-1610 at 6/17/16 10:39 AM:
----------------------------------------------------------------------
I run into the same problem after upgrading Wiremock from 1.58 to 2.0.10-beta. We use it for tests to mock third party systems. It fails consistently and interestingly enough I hot-fixed it by adding a Thread.sleep of 2000ms between tests. Not proud of that but am doing a bigger chunk of changes so I will tackle this one later.
Httpclient version is 4.5.1
was (Author: ondrej.burkert):
I run into the same problem after upgrading Wiremock from 1.58 to 2.0.10-beta. We use it for tests to mock third party systems. It fails consistently and interestingly enough I hot-fixed it by adding a Thread.sleep of 2000ms between tests. Not proud of that but am doing a bigger chunk of changes so I will tackle this one later.
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org