|Summary:||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.|
|Product:||Tomcat 8||Reporter:||prakash <cprakas>|
|Component:||Connectors||Assignee:||Tomcat Developers Mailing List <dev>|
|Attachments:||Sample app to reproduce this issue|
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
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 "220.127.116.11" Java(TM) SE Runtime Environment (build 18.104.22.168-jinteg_07_mar_2012_00_45-b00) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-jre22.214.171.124-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 10 Filip Hanik 2012-05-02 21:49:29 UTC
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
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.