Hi Steve thank your for your hint. do I understand correctly. Even using only the SimpleHttpConnectionManager there is a underlying pool mechanism that is administring a number of real http connection? Where or through what settings is it possible to control the behaviour of this pool (besides max_host_connections and max_total_connections)?
Armin > -----Original Message----- > From: Steve Terrell [mailto:[EMAIL PROTECTED] > Sent: Monday, December 04, 2006 3:00 PM > To: HttpClient User Discussion > Subject: RE: SocketTimeoutException: Read timed out > > Armin, > You should always release the connection. This puts the connection > back into the connection pool. It does not actually close the > connection. > For the read exception, there was a recent thread about > clearing out > idle connections. That's what you need to do to avoid socket > exceptions > under low load levels. > > --Steve > > -----Original Message----- > From: Wittmann Armin (BI) [mailto:[EMAIL PROTECTED] > Sent: Monday, December 04, 2006 2:51 AM > To: HttpClient User Discussion > Subject: SocketTimeoutException: Read timed out > > > > Hi > > I am using commons-httpclient in a 24x7 environment that > does send simple http-POST-requests with about 7 NameValuePairs. > Unfortunately I get sometimes the following error > java.net.SocketTimeoutException: Read timed out > (see stack trace below) > Worse is that this error cannot be reproduced in development > stage. It does occur mostly after a longer time of inactivity > or under high test load (=some 5 requests per second). > The average load in production is very low (e.g. 1 request per > 10 seconds). > > Fortunately the server recovers from this phase of malfunction > after some seconds and goes on working well. > Does anybody have the same effects or is it possible that I > am not programming API-conform. > > Here is the extract of my code inside the class CommonsHttpClient: > (variables with prefix '_' are field variables in this class > initialized > in its > constructor [that reads out some properties from file]) > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > public String sendHttpRequest(int pGetOrPost, NameValuePair > pKeyValuePairs) throws LBSystemException { > > HttpConnectionManager connectionManager = new > SimpleHttpConnectionManager(); > connectionManager.setParams(_connectionManagerParams); > HttpClient client = new HttpClient(_clientParams, connectionManager); > client.setHostConfiguration(_hostConfiguration); > > HttpMethod method = null; > if (pGetOrPost == 0) { > method = new PostMethod(); > ((PostMethod) method).setRequestBody(pairs); > } else if (pGetOrPost == 1) { > method = new GetMethod(); > method.setQueryString(pairs); > } > > method.setPath(_contextPath); > method.setParams(_methodParams); > > int statusCode = -1; > boolean failed = false; > try { > statusCode = client.executeMethod(method); > } catch (Exception e) { > failed = true; > throw new MyException(p + "perform http.request failed.", e); > } finally { > try { > if (failed) { > method.abort(); > > try { > method.releaseConnection(); > } catch (Exception e) { > _log.warning(p + "releasing connection after > evaluating http.request failed (failed=" + failed + "):", e); > } > } > } catch (Exception e) { > _log.warning(p + "aborting http.POST after failure raised an > exception:", e); > } > client.setHttpConnectionManager(null); > client = null; > } > } > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > Notice: I do release the connection only in case of an exception! > > We checked with TCPDUMP on the receiving server. It does not not > receive anything in such a error case. This observation is not very > precise since we tried to estimate when it will occur (mostly in the > morning with the first usage). > > And now the stacktrace: > Caused by: java.net.SocketTimeoutException: Read timed out > at java.net.SocketInputStream.socketRead0(Native Method) > 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 java.io.BufferedInputStream.fill(Unknown Source) > at java.io.BufferedInputStream.read(Unknown Source) > at > org.apache.commons.httpclient.HttpParser.readRawLine(HttpParse > r.java:77) > at > org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105) > at > org.apache.commons.httpclient.HttpConnection.readLine(HttpConn > ection.jav > a:1115) > at > org.apache.commons.httpclient.HttpMethodBase.readStatusLine(Ht > tpMethodBa > se.java:1832) > at > org.apache.commons.httpclient.HttpMethodBase.readResponse(Http > MethodBase > .java:1590) > at > org.apache.commons.httpclient.HttpMethodBase.execute(HttpMetho > dBase.java > :995) > at > org.apache.commons.httpclient.HttpMethodDirector.executeWithRe > try(HttpMe > thodDirector.java:397) > at > org.apache.commons.httpclient.HttpMethodDirector.executeMethod > (HttpMetho > dDirector.java:170) > at > org.apache.commons.httpclient.HttpClient.executeMethod(HttpCli > ent.java:3 > 96) > at > org.apache.commons.httpclient.HttpClient.executeMethod(HttpCli > ent.java:3 > 24) > at > ch.ethz.id.bi.fw.common.util.http.CommonsHttpClient.sendHttpRe > quest(Comm > onsHttpClient.java:148) > ... 20 more > > --------------------------------------------------------------------- > 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]
