On Thu, 2013-01-17 at 16:41 -0500, Mark Claassen wrote:
> Thanks for the explanation.
> > pro-actively evicting expired connections and connections that have been
> > idle
> Seems like just doing the stale check would more reliable, and speed does not
> seem to be a factory (especially with 4.2.3)
>
> I got in configured and distributed to this user and she is still having the
> same problem. Any other ideas? I double checked my code, and it looks like
> everything is correct. (She is not using a proxy.)
>
This can also be genuine network stability issues. Essentially,
connection resets are inevitable and robust HTTP services have to be
prepared to deal with them (most likely by re-trying idempotent methods
automatically and reporting the problem back to the caller otherwise).
Oleg
>
> Method that makes the request (from multiple threads)
> {
> response = httpClient.execute(request);
> }
> Bulk of configuration method (MAX is 10, CONNECTION_ESTABLISH_TIMEOUT =
> 10)
> {
> HttpParams params = new BasicHttpParams();
> params.setIntParameter(AllClientPNames.SO_TIMEOUT,
> (int) new TimeSpan(45, TimeUnit.SECONDS).convertTo(TimeUnit.MILLISECONDS));
>
> params.setIntParameter(AllClientPNames.CONNECTION_TIMEOUT,
> CONNECTION_ESTABLISH_TIMEOUT * 1000);
>
> params.setIntParameter(AllClientPNames.SOCKET_BUFFER_SIZE,
> DEFAULT_HTTP_SOCKET_BUFFER_SIZE);
>
> params.setBooleanParameter(AllClientPNames.STALE_CONNECTION_CHECK,
> Boolean.TRUE);
> configureProxy(params,protocol);
>
> connectionManager = new
> PoolingClientConnectionManager(schemeRegistry);
> connectionManager.setDefaultMaxPerRoute(MAX);
> connectionManager.setMaxTotal(MAX);
>
> httpClient = new DefaultHttpClient(connectionManager,
> params);
> }
> private void configureProxy(HttpParams params, String scheme) {
> Proxy proxy = getProxy();
> if (proxy.type() != Proxy.Type.DIRECT) {
> InetSocketAddress address = (InetSocketAddress)
> proxy.address();
> //SSL or not, we set the proxy up as HTTP
> HttpHost httpProxy = new
> HttpHost(address.getHostName(), address.getPort(), SCHEME_HTTP);
> params.setParameter(AllClientPNames.DEFAULT_PROXY,
> httpProxy);
> LogManager.log("Setting proxy in HostConfig to " +
> address, Level.INFO);
> if (!scheme.equals(SCHEME_HTTP)) {
> //If the scheme is HTTPS, we need to register
> an HTTP scheme for the proxy.
> schemeRegistry.register(new
> Scheme(SCHEME_HTTP,address.getPort(),PlainSocketFactory.getSocketFactory()));
> }
> }
>
> }
>
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:[email protected]]
> Sent: Thursday, January 17, 2013 7:21 AM
> To: HttpClient User Discussion
> Subject: Re: Connection Reset errors
>
> On Wed, 2013-01-16 at 15:22 -0500, Mark Claassen wrote:
>
> Basically 'connection reset' errors are a direct result of a general
> limitation of the blocking I/O model: when not blocked in an I/O operation
> there is no way for the socket to get notified of the opposite endpoint
> terminating the connection. While kept alive in the pool blocking HTTP
> connections can get stale. However, the only way to find it out is to try to
> attempt an I/O operation on such connection.
>
> > I noticed that there is a stale connection check:
> > params.setBooleanParameter(AllClientPNames.STALE_CONNECTION_CHECK,
> > Boolean.TRUE);
> >
> > Is this something that I should be using? I am connecting to the same
> > source over and over again.
> >
> > Mark
> >
>
> Yes, this is what you should be using. Another alternative would be
> pro-actively evicting expired connections and connections that have been idle
> longer than a given period of time.
>
> Oleg
>
>
> > -----Original Message-----
> > From: Mark Claassen [mailto:[email protected]]
> > Sent: Wednesday, January 16, 2013 3:07 PM
> > To: 'HttpClient User Discussion'
> > Subject: Connection Reset errors
> >
> > I have a user getting a lot of Connection Reset errors. I did not
> > think this had do to with HttpClient, so much as other factors on her
> > machine and the server. However, I did a bit of searching and see that
> > people have commented on this error with HttpClient before. I just
> > upgraded to HttpClient 4.2.3 to see if that would help at all, and it
> > didn't.
> >
> > This user is fine for a while, and then will get the Connection Reset
> > error. She then just retries the request, and it works. Any tips on how
> > to resolve this would be greatly appreciated.
> >
> > Thanks,
> > Mark
> >
> > We are using Tomcat 7.0.27, and the Connector is configured like this:
> > <Connector
> > port="5502"
> >
> > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > server="Unknown"
> > connectionLinger="0"
> > socket.soTimeout="300000"
> > SSLEnabled="true"
> > maxThreads="150"
> > scheme="https"
> > secure="true"
> > clientAuth="false"
> > keystoreFile="-----"
> > keystoreType="PKCS12"
> > keystorePass="-----"
> > sslProtocol="TLS"
> >
> > ciphers="SSL_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE
> > _RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES
> > _128_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_C
> > BC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"/>
> >
> >
> > ---- (1) ---- Throwable - Class (class java.net.SocketException)
> > Message (Connection reset)
> > at java.net.SocketInputStream.read(Unknown Source)
> > at com.sun.net.ssl.internal.ssl.InputRecord.readFully(Unknown Source)
> > at com.sun.net.ssl.internal.ssl.InputRecord.read(Unknown Source)
> > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
> > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(Unknown
> > Source)
> > at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source)
> > at
> > org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:166)
> > at
> > org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:90)
> > at
> > org.apache.http.impl.io.AbstractSessionInputBuffer.read(AbstractSessionInputBuffer.java:212)
> > at
> > org.apache.http.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:177)
> > at
> > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.ja
> > va:138)
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
