As suggested by Rainer, I would try with the blocking connector and compare.
Otherwise, it could be that your file is using very long lines (only 5
lines for more than 800k of data). Maybe a tomcat-dev could have a
look on this.
$ wc ext-datadownload-20150323_1157.js
5 7634 838044 ext-datadownload-20150323_1157.js
2015-03-26 12:12 GMT+01:00 Rainer Jung <rainer.j...@kippdata.de>:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
