On 31/01/18 19:26, Vivian Kong wrote: > > > Hi, > > I'm running the tests that comes with v8.5.24 on Linux on s390x and hit the > following failure: > > Testcase: testHeaderLimits10x512k took 10.659 sec > Caused an ERROR > End of input stream > java.io.IOException: End of input stream > at org.apache.coyote.http2.Http2TestBase$TestInput.fill > (Http2TestBase.java:879) > at org.apache.coyote.http2.Http2TestBase$TestInput.fill > (Http2TestBase.java:858) > at org.apache.coyote.http2.Http2Parser.readFrame > (Http2Parser.java:76) > at org.apache.coyote.http2.Http2Parser.readFrame > (Http2Parser.java:69) > at org.apache.coyote.http2.TestHttp2Limits.doTestHeaderLimits > (TestHttp2Limits.java:258) > at org.apache.coyote.http2.TestHttp2Limits.doTestHeaderLimits > (TestHttp2Limits.java:171) > at org.apache.coyote.http2.TestHttp2Limits.doTestHeaderLimits > (TestHttp2Limits.java:165) > at org.apache.coyote.http2.TestHttp2Limits.doTestHeaderLimits > (TestHttp2Limits.java:159) > at org.apache.coyote.http2.TestHttp2Limits.testHeaderLimits10x512k > (TestHttp2Limits.java:153) > > > > This test case was passing in v8.5.16. I notice there were changes in > doTestHeaderLimits() between these 2 versions: > > 8.5.16: > https://github.com/apache/tomcat85/blob/TOMCAT_8_5_16/test/org/apache/coyote/http2/TestHttp2Limits.java#L243 > case 2: { > // Behaviour depends on timing. If reset is processed fast > enough, > // frames will be swallowed before the connection reset limit > is > // reached > if (e == null) { > parser.readFrame(true); > Assert.assertEquals("3-RST-[11]\n", output.getTrace()); > Assert.assertNull(e); > } > // Else is non-null as expected for a connection reset > break; > } > > 8.5.24: > https://github.com/apache/tomcat85/blob/TOMCAT_8_5_24/test/org/apache/coyote/http2/TestHttp2Limits.java#L252 > > > case CONNECTION_RESET: { > // Connection reset. Connection ID will vary so use a pattern > // On some platform / Connector combinations (e.g. Windows / > APR), > // the TCP connection close will be processed before the client > gets > // a chance to read the connection close frame > try { > parser.readFrame(true); > Assert.assertThat(output.getTrace(), > RegexMatcher.matchesRegex( > "0-Goaway-\\[1\\]-\\[11\\]-\\[Connection \\[\\d++ > \\], Stream \\[3\\], .*")); > } catch (SocketException se) { > // Expected on Windows > } > break; > } > > For my test run, 'e' is not null - does that mean there are no frames to > process and that's why the IOException is hit? If I put back the guard > around 'e' then the test case also pass for 8.5.24. Should the guard be > add back in?
Probably not. There are platforms where even if e is non-null, a frame can be read. In that case we want to make sure it is the right frame. I think updating the comment and changing the catch to catch IOException is the way to go here. I've applied a fix to trunk and 8.5.x. Are you able to test it? Thanks, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
