Looks like the stale connection check is enabled by default anyway, so I must
have been using it all along.
> It may well be that HttpURLConnection silently retries failed requests
Is this a common thing to do, like for browsers? Granted, she is in our app
more than most others, but I don't think she experiences issues with other
applications.
She is not getting a Connection Refused or some other unable to read exception,
but a Connection Reset. The stale connection check passed, so HttpClient
thinks this is a good connection, right? Or are there limits to how reliable a
stale connection check can be?
public boolean isStale() {
if (!isOpen()) {
return true;
}
if (isEof()) {
return true;
}
try {
this.inbuffer.isDataAvailable(1);
return isEof();
} catch (SocketTimeoutException ex) {
return false;
} catch (IOException ex) {
return true;
}
}
-----Original Message-----
From: Oleg Kalnichevski [mailto:[email protected]]
Sent: Friday, January 18, 2013 11:24 AM
To: HttpClient User Discussion
Subject: Re: Connection Reset errors
On Fri, 2013-01-18 at 10:17 -0500, Mark Claassen wrote:
> Before I switched to using HttpClient years ago, I used HttpsURLConnection.
> Not sure how things were going to turn out with HttpClient, I kept that code
> in place and made it so I could use either API. I had her switch back to
> using the java.net stuff the other day and the problem appeared to go away.
> I have configured her system to use the java.net connector again today.
> Before I make any conclusions I need some more data from her on each
> connector. However, the previous data seems to indicate that it is only an
> issue when using HttpClient (originally 4.1.3, now 4.2.3).
>
It may well be that HttpURLConnection silently retries failed requests without
your knowing about it. It certainly did that when I last touched it (which
admittedly was a looooooong time ago), and that was precisely the reason I had
to stop using it and to look for a better alternative.
> Some other things of note:
> - She is using JRE 6 Update 13. (There is a long story behind this.)
> - The application is launched via Webstart
> - The SocketFactory is created with: fact = new
> SSLSocketFactory(HttpsURLConnection.getDefaultSSLSocketFactory(),verif
> ier);
>
I do not thing any of these should matter.
Oleg
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:[email protected]]
> Sent: Friday, January 18, 2013 6:17 AM
> To: HttpClient User Discussion
> Subject: Re: Connection Reset errors
>
> 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
> > > _D HE _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_E
> > > DE _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]
>
>
> ---------------------------------------------------------------------
> 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]
