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. My concern with 7.0.83 is error handling in async (bug 61886). Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
