Am 27.03.2015 um 15:48 schrieb Andrew Seales:
Yes, we do, on Solaris 10. I don't know of any such problems, but I
can't introduce the slow network condition here to test.
Good to know. In case it wasn't clear, the network limiting is done on
the client side, not on the server.
Is the file really truncated, i.e. too short, or is it corrupt? Can
the truncation also be seen in the Tomcat access log? If so, could you
replace the curl/md5sum based test with another HTTP client like
LWP::Simple in perl or "ab" coming with Apache httpd. Just to rule out
the client side of the picture.
Yes the file is definitely truncated rather than corrupted. Users of our
services with normal browsers are noticing the problem, it's what
prompted me to use the Perl+Curl test script.
Is truncation always happening at the same byte? Any pattern?
Which connector are you using? NIO? APR?
I've tried both AJP13 and the standard HTTP1/1 connectors, both have the
same problem. When using AJP the Apache log shows the file size as being
truncated, I'll check the Tomcat log when using HTTP1/1 to see if it
agrees.
I personally would try the following to provide additional analysis
data: Find a setup, where you can log the client port. Use this setup
and snoop network traffic during the test on the client and server
side. Once the problem happens, use the local port number and
timestamp to extract the communication pattern on the server and
client side. That way you can see, which side closed/aborted the
connection - or whether it is something in between client and server.
Thanks, I'll give Wireshark or something like that a go to see if I can
see any TCP problems.
Not necessarily a problem from the TCP layer point f view. But once you
can find a request that's truncated in the TCP log, you can look out
- whether it was a normal connection shutdown or a reset
- whether there were unusual pauses between packets triggering timeouts
etc. That's why you would benefit from your test client being able to
log the client port when a failure arises so you can filter easily in
Wireshark. I'm thinking about adding client port as a loggable item to
the Tomcat AccessLog but that won't help you right now.
I vaguely remember problems with TCP checksum offloading, but they
should be fixed long ago. See e.g.
http://compgroups.net/comp.unix.solaris/disable-e1000-tcp-checksum-offloading-t5220/472801
I also once at a customer saw a problem not of truncation, but the last
packet of a response as delayed quite noticable. That was fixed by
applying the current Solaris patch cluster at that time.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
