On Fri, 2013-01-18 at 13:47 -0500, Mark Claassen wrote: > Oh, I forgot to add that all my requests are POST requests. >
Hi Mark I wish I could help you but I just do not know how. All I can tell you is that connection resets can happen for all sorts of reasons. There is no one common cause. Writing out request message _may_ appear successful simply because the whole message was small enough to fit into the socket buffer. It does not necessarily mean it got transferred to the opposite endpoint. The problem with POST messages is that usually they are not idempotent. This is precisely the reason why HttpClient does not retry entity closing methods automatically. HttpURLConnection used to be careless enough to silently retry POST requests several times prior to throwing an I/O exception. I hope it is no longer the case. If it is, then HttpURLConnection is broken beyond redemption. Oleg > -----Original Message----- > From: Mark Claassen [mailto:[email protected]] > Sent: Friday, January 18, 2013 1:02 PM > To: 'HttpClient User Discussion' > Subject: RE: Connection Reset errors > > While she is testing the java.net stuff, I decided to look into the > possibility of retrying the request. Looking at this more closely, I see > that the error is on the reading of the data, and the write seems to succeed. > This gives me something to check on, since I should be able to see whether > or not the servlet actually got her request or not. > > However, is this a common manifestation of the Connection Reset error? The > write succeeds (or fails silently) and then it is on the read the problem can > be detected? Or does this mean that the socket was fine during the write > operation, but then was somehow severed before the read? > > Mark > > -----Original Message----- > From: Mark Claassen [mailto:[email protected]] > Sent: Friday, January 18, 2013 12:06 PM > To: 'HttpClient User Discussion' > Subject: RE: Connection Reset errors > > 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] > > > --------------------------------------------------------------------- > 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]
