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(),verifier); > 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_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] > > > --------------------------------------------------------------------- > 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]
