tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kees Jan Koster <>
Subject Re: connection reset errors
Date Tue, 22 May 2012 11:54:17 GMT
Dear André,

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

Yes, it has a forwarded port 80 (using FreeBSD ipfw) that also points to 8080, and there is
an Apache with mod_proxy_http that hooks into 8081. My tests are on the vanilla port, though.

> 1) You are getting a
> Connection reset
> 	at
> 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".

The reading is one area I need to look into: did the client get all data, partial data or
none at all. I need to experiment with that.

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

Indeed, not always. About 1 in 10 posts die like this on bad days. Sometimes hours with no
issues. No pattern I can discern.

> 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.

The response is a few bytes. I think it is about 10-20 bytes. Less than a packet, I expect.

> 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.

What makes the request size interesting? What previous experience are you basing this question

> 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)).

I can check that I see the same problems from a browser using firebug, that is a good idea.

> 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.

mtr reports no packet loss between the two machines I used for testing.

> And if this all still does not provide any clues, then you're down to a network packet
trace, using Wireshark or similar.

Packet traces I was hoping to avoid. :(
Kees Jan

The secret of success lies in the stability of the goal. -- Benjamin Disraeli

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message