Hi, +1 to accept this regression
Best, Zakelly On Sat, May 2, 2026 at 12:57 AM Hao Li <[email protected]> wrote: > Hi Piotr, > > Thanks! If there's no other comments in 24 hours. We will not consider > this as a blocker for 2.3 release. > > Hao > > On Thu, Apr 30, 2026 at 6:32 AM Piotr Nowojski <[email protected]> > wrote: > > > > Hi Hao, > > > > Thanks for analysing this issue. Tbh, I don't see any easy solution to > this > > problem. The proposed by the AI solutions > > > > > # Switch the default taskmanager.network.compression.codec to ZSTD > for > > blocking shuffle (Flink already ships a ZstdBlockCompressor) — its native > > path is unaffected. > > > # Move to a different LZ4 binding whose JNI fast decompressor is not > > affected by CVE-2025-66566 (e.g., aircompressor's pure-Java LZ4, which is > > competitive with at.yawk.lz4'ssafe path). > > > > Doesn't really help to address the performance issue. ZSTD will be > slower. > > And at least according to this ai, aircompressor will be similar. > > > > Until someone digs deeper into this topic, I think we will have to accept > > this regression. > > > > Best, > > Piotrek > > > > > > > > śr., 29 kwi 2026 o 20:54 Hao Li <[email protected]> napisał(a): > > > > > Hi Dev, > > > > > > There is a Flink compress file benchmark regression discovered when we > > > prepare Flink 2.3 release [1]. It started sometime in Feb after Feb > > > 19th. After some investigation and validation, we believe the > > > regression was introduced by [2] which upgraded lz4-java to 1.10.3 to > > > include CVE fixes (detailed analysis in ticket comments). It was also > > > backported to Flink 2.2 and 2.1 release. > > > > > > I would like to start a discussion whether we want to have this 10% > > > regression as a blocker for Flink 2.3 release until we find an owner > > > and have it fixed. > > > > > > Thanks, > > > Hao > > > > > > > > > [1] https://issues.apache.org/jira/browse/FLINK-39502 > > > [2] https://github.com/apache/flink/pull/27535 > > > >
