Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4FBB62E9.4090406@ice-sa.com>
Date: Tue, 22 May 2012 11:56:57 +0200
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: connection reset errors
References: <66593FBF-28EE-4714-B635-665E8C8108DC@gmail.com>
In-Reply-To: <66593FBF-28EE-4714-B635-665E8C8108DC@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Kees Jan Koster wrote:
> Dear Tomcat community,
> 
> I am trying to resolve the problem where some client code in Java frequently gets the following error in the logs:
> 
> java.net.SocketException: Connection reset
> 	at java.net.SocketInputStream.read(SocketInputStream.java:168)
> 	at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> 	at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
> 	at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
> 	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687)
> 	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
> 	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:652)
> 	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1000)
> 	...
> 
> The client code performs a simple HTTP POST request to a Tomcat server (FreeBSD 9.0-STABLE, Java 1.6.0_03, Tomcat 6.0.26). Below is the HTTP connector from server.xml:
> 
>     <Connector port="8080" protocol="HTTP/1.1" 
>                connectionTimeout="10000" enableLookups="false" compression="on"
>                maxThreads="256" bufferSize="9000" />
> 
> Tracing the servlet in Tomcat shows that the servlet's doPost() method returns normally and does not show any exceptions (I catch and log Throwable and nothing related is logged). Tracing on an application level shows the posted data to be in the database, as would be for a normal POST. The data is correct.
> 
> Of note is that the response time of the post is the same as for a successful post. Under normal circumstances Tomcat processes a post in about 25ms, measured in the client. When I get this exception, the response time is also about that time. I think therefore that I am not timing out anywhere (or the response time would be a lot longer).
> 
> First question: It says "Connection reset" and not "Connection reset by peer". What is the difference between the two? I am told that one means a local reset and the other means a remote reset. Where can I find more about this difference?
> 
> Second question: how do I analyze such resets? How do I find out who reset the connection and why? How can I replay this in such a way that I can see that?
> --

Hi.

Assuming that your client is really connecting to that HTTP connector on port 8080 
mentioned above..

1) You are getting a
java.net.SocketException: Connection reset
	at java.net.SocketInputStream.read(SocketInputStream.java:168)

so this appears to happen when/while your java client is reading the response from the 
server, and it appears to be that the client is expecting to be able to read more data, 
but finds itself unable to, because the socket has been closed "under his nose".

You say that it happens "frequently", so it's not always.

2) the server itself seems unaware that there is a problem.  So it has already written the 
whole response back to the client, decided it was done with this request, and gone happily 
to handle other things.

That can happen, even if the client has not yet received all data, because between the 
server and the client there is a lot of piping, and the data may buffered at various 
levels or still "in transit".

thus..

- either the client is misinterpreting the amount of data that it should be reading from 
the server's response (trying to read more than there actually is)
(on the other hand, I think that the kind of exception you would get in that case would be 
different, more like "trying to read beyond EOF" or so).
- or something in-between the server and the client closes the connection before all data 
has been returned to the client (and/or is loosing data).

It would be helpful to know if this happens when the response is particularly large, or 
small, or if it is unrelated to the response size.

If the server is configured with an AccessLogValve, you should be able to see how big the 
response was, in bytes.  If you have control over the client code, you should be able to 
add something that logs how many bytes it has read before the exception occurs.
Dumping the response HTTP headers to the client logfile would also help finding out what 
happens. (If the client is an applet running inside of a browser, then a browser add-on 
would show this easily (like "Live HTTP Headers" for Firefox, or Fiddler2 for IE)).

Doing a "traceroute" from the client to the server,  may also give an idea of what there 
is actually between the server and the client.
And if this all still does not provide any clues, then you're down to a network packet 
trace, using Wireshark or similar.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org