On 04/02/2015 12:55, Konstantin Kolinko wrote: > 2015-02-04 14:45 GMT+03:00 <ma...@apache.org>: >> Author: markt >> Date: Wed Feb 4 11:45:39 2015 >> New Revision: 1657125 >> >> URL: http://svn.apache.org/r1657125 >> Log: >> Fix failing NIO2 unit test. >> Response body may not be chunked so doing a line-by-line read will fail >> unless the client is explicitly told to use the content length. >> >> Modified: >> tomcat/trunk/test/org/apache/coyote/http11/TestInternalOutputBuffer.java >> >> Modified: >> tomcat/trunk/test/org/apache/coyote/http11/TestInternalOutputBuffer.java >> URL: >> http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/coyote/http11/TestInternalOutputBuffer.java?rev=1657125&r1=1657124&r2=1657125&view=diff >> ============================================================================== >> --- tomcat/trunk/test/org/apache/coyote/http11/TestInternalOutputBuffer.java >> (original) >> +++ tomcat/trunk/test/org/apache/coyote/http11/TestInternalOutputBuffer.java >> Wed Feb 4 11:45:39 2015 >> @@ -41,6 +41,10 @@ public class TestInternalOutputBuffer ex >> ExpectationClient client = new ExpectationClient(); >> >> client.setPort(tomcat.getConnector().getLocalPort()); >> + // Expected content doesn't end with a CR-LF so if it isn't chunked >> make >> + // sure the content length is used as reading it line-by-line will >> fail >> + // since there is no "line". >> + client.setUseContentLength(true); >> >> client.connect(); > > > The change is OK but the explanation & comment is odd to me. > > I think the reason for this change is that now we are not waiting for > end-of-stream on a connection that is in keep-alive state (wasting our > time waiting for a timeout), but use the response content length to > stop reading earlier.
Yes, but... The dropping of the connection was triggering an error that meant that the reading of the line was failing. Not sure why this was an NIO2 only issue. Since this looked like an issue with the test I didn't dig further. <snip/> > Recent Buildbot build are hanging and are killed after a timeout, > before they start running this test. (No recent test results for this > test exist at buildbot) Thus I do not see what the error is. Older > runs are OK, I think that is related to my recent "avoid multiple write registration" changes. The issue occurs on Linux but not Windows or OSX. Debugging a failing unit test remotely is a pain so I am just finishing off setting up a Linux dev environment in a VM so I can debug this directly in Eclipse. I hope to have a fix later today although with this type of I/O issue it can take a while to track down exactly what is going wrong. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
