DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=43846>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43846 Summary: Race condition with NIO connector parsing chunked response Product: Tomcat 6 Version: 6.0.14 Platform: All OS/Version: All Status: NEW Severity: regression Priority: P2 Component: Connectors AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The problem seems to relate to parsing the body content when the **Transfer- Encoding: chunked** header is present. It appears that the chunk length gets corrupted under load and the client is unable to parse the chunk out of the response body. When the NIO connector parameter **socket.appWriteBufSize** is set to a value larger than the total response body, the error condition does not occur. One might succesfully argue that this is proper performance tuning. The Tomcat documents point out that to scale a large number of long held connections, the buffer sizes may need to be less than the response body (the memory footprint would be quite large otherwise). Could there be a race condition involving the response buffering code? I have confirmed this behavior on both JDKs 1.5 and 1.6 on both Windows 2003 and Linux. Apache Bench does not appear to fully parse the response so it will not be helpful in reproducing the issue. The Grinder framework does. I am including the Grinder scripts so that the issue may be reproduced. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
