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 > >
