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 >
