Dear André, > 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) > > 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". > > 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 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/ kjkos...@kjkoster.org +31651838192 The secret of success lies in the stability of the goal. -- Benjamin Disraeli --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
