You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by Hao Li <li...@gmail.com> on 2026/05/01 16:56:48 UTC
Re: [DISCUSS] Compress file benchmark regression resolution for Flink 2.3 release
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 <pn...@apache.org> 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 <li...@gmail.com> 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
> >
Re: [DISCUSS] Compress file benchmark regression resolution for Flink 2.3 release
Posted by Yuepeng Pan <hi...@gmail.com>.
Thanks to Hao Li for the hard work, and to Piotr Nowojski and Zakelly Lan
for evaluation and help.
As mentioned above, we will proceed with accepting this performance
regression.
Best regards,
Yuepeng Pan
Zakelly Lan <za...@gmail.com> 于2026年5月2日周六 12:40写道：
> Hi,
>
> +1 to accept this regression
>
>
> Best,
> Zakelly
>
> On Sat, May 2, 2026 at 12:57 AM Hao Li <li...@gmail.com> 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 <pn...@apache.org>
> > 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 <li...@gmail.com> 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
> > > >
> >
>
Re: [DISCUSS] Compress file benchmark regression resolution for Flink 2.3 release
Posted by Zakelly Lan <za...@gmail.com>.
Hi,
+1 to accept this regression
Best,
Zakelly
On Sat, May 2, 2026 at 12:57 AM Hao Li <li...@gmail.com> 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 <pn...@apache.org>
> 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 <li...@gmail.com> 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
> > >
>