Am 11.12.2017 um 14:02 schrieb Konstantin Kolinko:
2017-12-11 15:37 GMT+03:00 Rainer Jung <rainer.j...@kippdata.de>:
Hi Konstantin,
Am 11.12.2017 um 12:30 schrieb Konstantin Kolinko:
...
The following test fails with 8u152, regardless of connector:
org.apache.coyote.http11.filters.TestFlushableGZIPOutputStream
[[[
Testcase: testBug52121 took 0,025 sec
Caused an ERROR
invalid code lengths set
java.util.zip.ZipException: invalid code lengths set
at
java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:117)
at java.io.FilterInputStream.read(FilterInputStream.java:107)
at org.apache.catalina.util.IOTools.flow(IOTools.java:74)
at org.apache.catalina.util.IOTools.flow(IOTools.java:85)
at
org.apache.coyote.http11.filters.TestFlushableGZIPOutputStream.testBug52121(TestFlushableGZIPOutputStream.java:74)
]]]
This is the known regression of Java 8u151/152. It is not a bug in Tomcat.
I can reproduce, but shouldn't that have been fixed in r1816712 and
r1816713? Or is our test class just not using the workaround, so the test is
broken?
Nothing is broken here.
I am just noting for an archive that JRE bug is visible here.
(It is a pity that nobody tested an early build of 8u151 with 7.0.x.
They could have seen the bug.)
The test tests FlushableGZIPOutputStream directly. That class is not
used when running on Java 7+.
I manually tested that Tomcat runs correctly with compression enabled.
Thanks for confirming.
My concern with 7.0.83 is error handling in async (bug 61886).
Understood.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
