You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by "Wittmann Armin (BI)" <ar...@id.ethz.ch> on 2006/12/04 08:50:45 UTC
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(HttpParser.java:77)
at
org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)
at
org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.jav
a:1115)
at
org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBa
se.java:1832)
at
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase
.java:1590)
at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java
:995)
at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMe
thodDirector.java:397)
at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMetho
dDirector.java:170)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:3
96)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:3
24)
at
ch.ethz.id.bi.fw.common.util.http.CommonsHttpClient.sendHttpRequest(Comm
onsHttpClient.java:148)
... 20 more
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
RE: SocketTimeoutException: Read timed out
Posted by "Wittmann Armin (BI)" <ar...@id.ethz.ch>.
In the morning it happens with higher probability :-)
But during the day I have about 5 such errors, also unter
light load.
I don't believe that this can be the problem.
Thanks
> -----Original Message-----
> From: Julius Davies [mailto:juliusdavies@gmail.com]
> Sent: Monday, December 04, 2006 3:06 PM
> To: HttpClient User Discussion
> Subject: Re: SocketTimeoutException: Read timed out
>
> When you say it usually happens in the morning, after the first usage,
> that makes me suspect some kind of firewall rule (or VPN tunnel?) that
> closed down from inactivity, and then tries to quickly re-establish
> itself when the first TCP/IP packet comes through.
>
> Maybe you could implement some kind of repeating HEAD request (every
> 10 minutes?) just to keep all the wires warm?
>
> Steve Terrell's comments are also good. Probably better than
> mine. :-o
>
>
> yours,
>
> Julius
>
>
> On 12/4/06, Wittmann Armin (BI) <ar...@id.ethz.ch> wrote:
> >
> >
> > 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:
> httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> httpclient-user-help@jakarta.apache.org
> >
> >
>
>
> --
> yours,
>
> Julius Davies
> 416-652-0183
> http://juliusdavies.ca/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpclient-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: SocketTimeoutException: Read timed out
Posted by Julius Davies <ju...@gmail.com>.
When you say it usually happens in the morning, after the first usage,
that makes me suspect some kind of firewall rule (or VPN tunnel?) that
closed down from inactivity, and then tries to quickly re-establish
itself when the first TCP/IP packet comes through.
Maybe you could implement some kind of repeating HEAD request (every
10 minutes?) just to keep all the wires warm?
Steve Terrell's comments are also good. Probably better than mine. :-o
yours,
Julius
On 12/4/06, Wittmann Armin (BI) <ar...@id.ethz.ch> wrote:
>
>
> 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(HttpParser.java:77)
> at
> org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)
> at
> org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.jav
> a:1115)
> at
> org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBa
> se.java:1832)
> at
> org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase
> .java:1590)
> at
> org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java
> :995)
> at
> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMe
> thodDirector.java:397)
> at
> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMetho
> dDirector.java:170)
> at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:3
> 96)
> at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:3
> 24)
> at
> ch.ethz.id.bi.fw.common.util.http.CommonsHttpClient.sendHttpRequest(Comm
> onsHttpClient.java:148)
> ... 20 more
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
--
yours,
Julius Davies
416-652-0183
http://juliusdavies.ca/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: SocketTimeoutException: Read timed out
Posted by Roland Weber <ht...@dubioso.net>.
Hello Armin,
> Releasing the connection is necessary/possible after
> httpMethod.execute()
> or is it only possible after one/all of the following functions
> method.getStatusLine()
> method.getResponseHeaders()
> method.getStatusText()
> method.getResponseBodyAsString()
> ?
You _can_ release the connection any time after execute().
BUT you can't call methods like getResponseBodyAsString()
afterwards. The general rule is: Make sure the connection
is *always* released *after* you've finished processing
the response. The last sections of the tutorial address
connection release, too:
http://jakarta.apache.org/commons/httpclient/tutorial.html
hope that helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
RE: SocketTimeoutException: Read timed out
Posted by "Wittmann Armin (BI)" <ar...@id.ethz.ch>.
Hello Roland
thank you very much.
Releasing the connection is necessary/possible after
httpMethod.execute()
or is it only possible after one/all of the following functions
method.getStatusLine()
method.getResponseHeaders()
method.getStatusText()
method.getResponseBodyAsString()
?
Armin
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
RE: SocketTimeoutException: Read timed out
Posted by Roland Weber <RO...@de.ibm.com>.
Hello Armin,
> 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)?
With SimpleHttpConnectionManager, the pool size is always
one connection. But even the SimpleHttpConnectionManager
will try to keep that connection alive. And it generates
warnings if the connection is not correctly released.
Each connection manager comes with it's own pool implementation.
max_host_connections and max_total_connections are parameters
for the MultiThreadedHttpConnectionManager. If you want to have
more control over the pool, you have to implement your own
connection manager.
hope that helps,
Roland
RE: SocketTimeoutException: Read timed out
Posted by "Wittmann Armin (BI)" <ar...@id.ethz.ch>.
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:Steve.Terrell@guideworkstv.com]
> 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:armin.wittmann@id.ethz.ch]
> 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: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpclient-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> httpclient-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
RE: SocketTimeoutException: Read timed out
Posted by Steve Terrell <St...@guideworkstv.com>.
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:armin.wittmann@id.ethz.ch]
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(HttpParser.java:77)
at
org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)
at
org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.jav
a:1115)
at
org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBa
se.java:1832)
at
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase
.java:1590)
at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java
:995)
at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMe
thodDirector.java:397)
at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMetho
dDirector.java:170)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:3
96)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:3
24)
at
ch.ethz.id.bi.fw.common.util.http.CommonsHttpClient.sendHttpRequest(Comm
onsHttpClient.java:148)
... 20 more
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org