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?

Thanks for your help.

Regards,

Vivian Kong
Linux on z Systems Open Source Ecosystem
IBM Canada Toronto Lab

Reply via email to