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 kjkoster@gmail.com designates
 209.85.212.177 as permitted sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1278)
Subject: Re: connection reset errors
From: Kees Jan Koster <kjkoster@gmail.com>
In-Reply-To: <4FBB62E9.4090406@ice-sa.com>
Date: Tue, 22 May 2012 13:54:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A69D0F8A-0624-42F5-9D12-0C9CA18BBB24@gmail.com>
References: <66593FBF-28EE-4714-B635-665E8C8108DC@gmail.com>
 <4FBB62E9.4090406@ice-sa.com>
To: "Tomcat Users List" <users@tomcat.apache.org>

Dear Andr=E9,

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

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
> java.net.SocketException: Connection reset
> 	at java.net.SocketInputStream.read(SocketInputStream.java:168)
>=20
> 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.

Precisely.

> 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".
>=20
> thus..
>=20
> - 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).
>=20
> 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 on?

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

> 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

http://java-monitor.com/
kjkoster@kjkoster.org
+31651838192

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


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