You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2018/02/05 10:53:52 UTC
Re: IOException on s390x
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: IOException on s390x
Posted by Vivian Kong <vi...@ca.ibm.com>.
Thanks Mark! I've checkout your fix and that resolves the failure I saw.
Regards,
Vivian Kong
Linux on z Systems Open Source Ecosystem
IBM Canada Toronto Lab
From: Mark Thomas <ma...@apache.org>
To: Tomcat Users List <us...@tomcat.apache.org>
Date: 2018/02/05 06:00 AM
Subject: Re: IOException on s390x
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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_tomcat85_blob_TOMCAT-5F8-5F5-5F16_test_org_apache_coyote_http2_TestHttp2Limits.java-23L243&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=t7gXFFEkLvveGPwCXa29Q41okXMOY7sJK43BPFcHaRY&m=gd8ZIpZxloHSwrt3u5mVHDfAZQuswkWY37W0HfywDcg&s=VKUC2X8KnBbMB5xCt0KTexb8zKDMuXdgOlI_4xvQtZQ&e=
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_tomcat85_blob_TOMCAT-5F8-5F5-5F24_test_org_apache_coyote_http2_TestHttp2Limits.java-23L252&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=t7gXFFEkLvveGPwCXa29Q41okXMOY7sJK43BPFcHaRY&m=gd8ZIpZxloHSwrt3u5mVHDfAZQuswkWY37W0HfywDcg&s=jazHdVeb2NJtIJHvEf5LmKs3vO-ypmF2YJ5DhBOl0js&e=
>
>
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org