Bug 53138 - Not able to download a file size of 740KB using NIO connector in tomcat version 7.0.27. But with the same configuration I was able to download that in tomcat 7.0.26.
Summary: Not able to download a file size of 740KB using NIO connector in tomcat versi...
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 8
Classification: Unclassified
Component: Connectors (show other bugs)
Version: 8.0.18
Hardware: PC All
: P2 blocker (vote)
Target Milestone: ----
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
: 53331 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-04-24 11:53 UTC by prakash
Modified: 2017-04-17 18:21 UTC (History)
2 users (show)



Attachments
Sample app to reproduce this issue (51.66 KB, application/octet-stream)
2012-04-24 12:01 UTC, prakash
Details

Note You need to log in before you can comment on or make changes to this bug.
Description prakash 2012-04-24 11:53:11 UTC
We have an application that uses a java script file of size around 700Kb that will be downloaded as part of the client. The connector used was NIO . All these days we did not see any issue till Tomcat 7.0.26.
 
When we upgraded it to the latest Tomcat version 7.0.27 we started getting this problem. The file is never getting downloaded the connection will be broken in middle. 

And we used fiddler to see what is happening and it gives us a message as below

“Content-Length mismatch: Response Header indicated 757,692 bytes, but server sent 262,142 bytes.”

If I use the default connector there is no issues. it works fine. 

To reproduce this we have created a sample application. Please follow the steps below.

Clean up all the browser cash: 
1.	Deploy  TestNIOConnector app in tomcat.
2.	In server.xml change to connect to NIO as shown below.
<Connector port="9880" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="150" connectionTimeout="70000"
  acceptCount="100" compression="on" acceptorThreadCount="2" redirectPort="8443" />
3.	Start the service and try to access this file using the following URL in IE.
http://localhost:9880/TestNIOConnector/apidocs.js
Comment 1 prakash 2012-04-24 12:01:29 UTC
Created attachment 28666 [details]
Sample app to reproduce this issue

This app is to reproduce the issue.
Comment 2 Robert Kish 2012-05-02 15:52:02 UTC
I am having the same problem with my application. We have noticed only some files are not downloading, not all of them - there's no apparent pattern to the file size. We had one file that's 115397 download, but another that's 111158 fail.

What made it interesting was that the file did not download in IE 8, but the file did download in FF 12. This leads me to believe it's something browser specific about downloading the file. My searches led me to an item for 7.0.27, https://issues.apache.org/bugzilla/show_bug.cgi?id=52858
that looked interesting. Perhaps the issue relates to that change.
Comment 3 Filip Hanik 2012-05-02 16:46:42 UTC
Just ran the sample app on a 7.0.27 download

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/"757692-1335976856000"
Last-Modified: Wed, 02 May 2012 16:40:56 GMT
Content-Type: application/javascript
Content-Length: 757692
Date: Wed, 02 May 2012 16:43:11 GMT

and then I get all the bytes. 

<Connector port="9880" 
           protocol="org.apache.coyote.http11.Http11NioProtocol" 
           maxThreads="150" 
           connectionTimeout="70000"
           acceptCount="100" 
           compression="on" 
           acceptorThreadCount="2" 
           redirectPort="8443"/> 

I was unable to reproduce it. The last bytes I get downloaded are:

Y.on('hashchange', function (e) {
    pjax.updateTabState('hashchange');
}, win);

});

and that corresponds with the file contents
Comment 4 Filip Hanik 2012-05-02 16:49:07 UTC
Tested in 
Firefox 11 and Internet Explorer 9
Comment 5 Robert Kish 2012-05-02 20:02:56 UTC
(In reply to comment #4)
> Tested in 
> Firefox 11 and Internet Explorer 9


Tomcat installation:

<Connector port="8081" protocol="org.apache.coyote.http11.Http11NioProtocol" SSLEnabled="true"
               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS" keystoreFile="xxx/.keystore" keystorePass="xxx" keyPass="xxx"/>


Running on HPUX 11.11:

64 bit JVM

java version "1.6.0.14"
Java(TM) SE Runtime Environment (build 1.6.0.14-jinteg_07_mar_2012_00_45-b00)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-jre1.6.0.14-rc1b2 PA2.0W (aCC_AP), mixed mode)

-------

On Windows XP,

Using IE 8, I get 114,688 bytes of the file. It takes a long time to download the file after the first chunk of data. I'm guessing it just gives up and stops.

Using FF 12, I get about the same size of data initially - the file's progress is paused - I get the "Connecting" status - but after a while, the document completes and I get the whole size.
Comment 6 Filip Hanik 2012-05-02 20:27:32 UTC
Thanks Robert, are you able to reproduce this on a non HPUX system with a more recent runtime? ie, can you reproduce the attached test case on your local laptop or workstation?
Comment 7 Robert Kish 2012-05-02 20:30:30 UTC
(In reply to comment #6)
> Thanks Robert, are you able to reproduce this on a non HPUX system with a
> more recent runtime? ie, can you reproduce the attached test case on your
> local laptop or workstation?

Yes. I just finished testing this on my PC:
Windows XP SP 3

32 bit JVM

java version "1.7.0_03"
Java(TM) SE Runtime Environment (build 1.7.0_03-b05)
Java HotSpot(TM) Client VM (build 22.1-b02, mixed mode, sharing)

It worked on Tomcat 7.0.26. I installed 7.0.27, and it didn't work. I went back to 7.0.26, and it works again.
Comment 8 Filip Hanik 2012-05-02 21:06:47 UTC
Thanks Robert, I can reproduce it with IE 9 if I hit the "Save" option when I hit refresh in the browser. I will check on this and see how it works out
Comment 9 Filip Hanik 2012-05-02 21:46:42 UTC
In the meantime a workaround for this is to set useSendfile="false"

<Connector port="8081" protocol="org.apache.coyote.http11.Http11NioProtocol" SSLEnabled="true"
               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS" keystoreFile="xxx/.keystore" keystorePass="xxx" keyPass="xxx" useSendfile="false"/>
Comment 11 Filip Hanik 2012-05-08 14:28:54 UTC
(In reply to comment #10)
> Current suspect is:
> http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/tomcat/
> util/net/NioEndpoint.java?r1=1300872&r2=1300950&diff_format=h

Confirmed that the above check in broke sendFile for NIO. Current workaround is useSendfile="false" on the NIO connector
Comment 12 Filip Hanik 2012-05-18 19:30:33 UTC
Fixed in trunk in r1340215
Fixed in 7.0.x in r1340218
Will be available in 7.0.28
Comment 13 Filip Hanik 2012-05-30 17:43:11 UTC
*** Bug 53331 has been marked as a duplicate of this bug. ***
Comment 14 Giuseppe Schiavo 2017-04-11 19:16:41 UTC
This same issue is still happening on Tomcat 8. Setting the flag useSendData to false is a workaround my team has applied for now, but the bug is till there in Tomcat 8 and we would like to avoid using useSendData=false because increased CPU consumption.  
This issue is happening using with apache-tomcat-8.0.18 in Windows 7 environment
Comment 15 Mark Thomas 2017-04-11 21:29:18 UTC
This specific issue was fixed for 8.0.x almost 5 years ago.

If you are seeing an issue with similar symptoms, please test with the latest 8.0.x release (8.0.43 as I type this) and if you still see the issue please create a new bug report. You'll need to provide the simplest set of steps to reproduce the issue on a clean install of the latest 8.0.x release.
Comment 16 Christopher Schultz 2017-04-12 21:37:10 UTC
Revert bug description. It's still insanely long, but there is no need to thrash web indexers on this old issue.
Comment 17 Giuseppe Schiavo 2017-04-17 18:21:32 UTC
It is an old issue but it still happening it seems. We get this error in Chrome Electron 51, but not with other browsers. My guess is that the error is being ignored by other browsers. We haven't validated yet with 8.0.43, but we see it with 8.0.18. I will open a new bug after I validate with 8.0.43 in case it still happens with this version.