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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
