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

Noe edited comment on HTTPCLIENT-1610 at 11/2/16 1:03 PM:
----------------------------------------------------------

After tracing through logs noticed I was getting this exception when more 
requests where being made then the size of connection pool. So if connection 
pool size is 2, the third thread making a request would get this error. After 
increasing the pool size the error went away. Not sure of the details as to why 
this exception was thrown and not something more meaningful, but as I was using 
org.springframework.web.client.RestTemplate I am glad to move on.


was (Author: [email protected]):
I am having the same issue and can not figure it out

> 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]

Reply via email to