Am 26.03.2015 um 10:54 schrieb Andrew Seales:
Hi,
We are having a problem on our production servers where downloads of
certain files are getting randomly truncated. This includes static
Javascript files, file downloads via servlets, etc, where the file is
more than about 100K. Most of the time the file downloads successfully,
but some randomly get truncated. The truncation doesn't happen in
exactly the same place every time.
I've been able to recreate the issue on our development servers using
Tomcat 8.0.20 with Java 1.8.20 and 1.8.40. I've tried Solaris 10, 11,
SPARC and x64 CPUs and the same issue occurs. I've tested on a fresh
install of Tomcat 8 and dropped in one of our larger Javascript files
into the webapps/ROOT directory and made no other changes. I'm using a
Perl script to continuously download the file and test an md5 hash
against a known good value to test if the download breaks. It also seems
to only occur when the network speed isn't very good. I use the
following command to limit the speed of my network interface:
sudo tc qdisc add dev eth0 root handle 1:0 netem rate 128kbit
I've also tested the same Tomcat on a Redhat 6 server but that appears
to work fine.
If I revert to Tomcat 7.0.59, then Solaris works fine. The problem
appears to only occur with Tomcat 8 on Solaris. I've tried v8.0.14 and
8.0.20 and they both have the problem.
The Perl script is available from
http://dlib-bauer.ucs.ed.ac.uk/testdata.pl
The Javascript file is available from
http://dlib-bauer.ucs.ed.ac.uk/ext-datadownload-20150323_1157.js
Is anyone else running Tomcat 8 on Solaris 10 or 11 with Java 8, or know
of any problems on the platform?
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.
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.
Is truncation always happening at the same byte? Any pattern?
Which connector are you using? NIO? APR?
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.
Unfortunately logging the client port often is not trivial to achieve.
On the Tomcat side (access log), currently there is only the server port
available, not the remote port, although this would be very simple to
add. On the short hand it would maybe work to switch to perl plus LWP
and try to get the local port from LWP.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
