Mailing-List: contact httpclient-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-user@jakarta.apache.org>
Received-SPF: pass (herse.apache.org: domain of sebbaz@gmail.com designates
 66.249.92.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=AG0/g1hAZnm+k+vtfZDgVCGUmqOWUx7gQvVxkUOZxjSkvoLnTh3i5eV6eAnw9Ac5fEjA6F7fIZYIvkr2uj4ldKGt1dlRvu1stE7NJbGeZsHYXa49hx/8nxaZ92+PusZYBeIk7WgVM3VKMb/h+dxVLBD+1SyVwxyXPOGIRpu+JBo=
Message-ID: <25aac9fc0703141143pff15c36te9566095e71d7711@mail.gmail.com>
Date: Wed, 14 Mar 2007 18:43:01 +0000
From: sebb <sebbaz@gmail.com>
To: "HttpClient User Discussion" <httpclient-user@jakarta.apache.org>
Subject: Re: SocketException: Connection reset / Invalid argument
In-Reply-To: <1173893154.4785.15.camel@okhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <25aac9fc0703140947h1b8c4b18hedb3cc26a65ebe64@mail.gmail.com>
	 <1173893154.4785.15.camel@okhost>

On 14/03/07, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Wed, 2007-03-14 at 16:47 +0000, sebb wrote:
> > I've been running some stress tests on JMeter using HTTPClient and
> > Java HTTP. [Mainly the idea is to try and find synch etc problems in
> > JMeter.]
> >
> > Every so often, the HTTPClient test reports SocketExceptions - mostly
> > Connection reset, but sometimes Invalid argument (about 15% of the
> > errors).
> >
> > The percentage of Socket errors is quite low - 0.5% or less - however
> > I don't see any errors at all with the Java implementation.
> >
> > This is running on a 4 CPU Alpha, Java 1.4.2, Apache httpd 150
> > clients, JMeter 140 threads, single GET per thread, looped 1000 times.
> >
> > The same errors happen, but less frequently, with fewer JMeter threads.
> >
> > It's not a show-stopper, but I would be interested to know if there is
> > a known cause for this difference in behaviour?
> >
> > Sample stack traces (" at " has been removed):
> >
> > java.net.SocketException: Connection reset
> > java.net.SocketInputStream.read(SocketInputStream.java:168)
> > java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
> > java.io.BufferedInputStream.read(BufferedInputStream.java:201)
> > org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
> > org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
> > org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
> > org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1969)
> > org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1727)
> > org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1090)
> > org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
> > org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
> > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
> > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
> >
> > and
> >
> > java.net.SocketException: invalid argument
> > java.net.SocketInputStream.socketRead0(Native Method)
> > java.net.SocketInputStream.read(SocketInputStream.java:147)
> > java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
> > java.io.BufferedInputStream.read(BufferedInputStream.java:201)
> > org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
> > org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
> > org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
> > org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1969)
> > org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1727)
> > org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1090)
> > org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
> > org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
> > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
> > org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
> >
> > S///
> >
>
> Sebastian,
>
> In both cases an exception was thrown while HttpClient was waiting for a
> response status line, which seems to indicate a server side problem in
> my opinion.

There are a few errors logged by Apache, but not nearly as many as I
would expect, though I guess I'd need to see when they occurred in
relation to the client failures.

> 'Connection reset' usually means the connection was unexpectedly closed
> by the peer. In your case the server appears to have dropped connection
> on the unsuspecting HttpClient before sending back a response most
> likely due to the high load.
>
> You are not seeing this kind of exceptions with Java HTTP connection
> because the damn thing simply silently retries failed requests as it
> sees fit (at least that was the case when I last worked with Java HTTP
> connection, which admittedly was a long time ago)

Does HTTPClient not retry?

There seems to be some retry code, but I did not follow it through to
see if it applied in this case.

If so, maybe I could try increasing the retry count.

S

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org