Hi Dong,
> On Jan 4, 2024, at 10:18 PM, Dong Lin wrote:
>
> Hi Ken,
>
> Sorry for the late reply. I didn't notice this email from you until now.
>
> In this scenario you described above, I don't think operator2 will see the
> result modified by operato1. Note that object re-use applies only
Hi Lu,
You can find information about the FLIP process on our wiki[1]. Please
let me know if you have any questions.
Best regards,
Xuannan
[1]
https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals
On Tue, Jan 9, 2024 at 5:36 AM Lu Niu wrote:
>
> sounds good. Is the
sounds good. Is the requirement to send an email thread about the voting?
What else is needed? What's the passing criteria?
Best
Lu
On Sun, Jan 7, 2024 at 5:41 PM Xuannan Su wrote:
> Hi Liu,
>
> The voting thread has been open for a long time. We may want to start
> a new voting thread. WDYT?
Hi Liu,
The voting thread has been open for a long time. We may want to start
a new voting thread. WDYT?
Best,
Xuannan
On Sat, Jan 6, 2024 at 1:51 AM Lu Niu wrote:
>
> Thank you Dong and Xuannan!
>
> Yes. We can take on this task. Any help during bootstrapping would be greatly
> appreciated!
Thank you Dong and Xuannan!
Yes. We can take on this task. Any help during bootstrapping would be
greatly appreciated! I realize there is already a voting thread "[VOTE]
FLIP-329: Add operator attribute to specify support for object-reuse". What
else do we need?
Best
Lu
On Fri, Jan 5, 2024 at
Hi Lu,
I believe this feature is very useful. However, I currently lack the
capacity to work on it in the near future. I think it would be great
if you could take on the task. I am willing to offer assistance if
there are any questions about the FLIP, or to review the PR if needed.
Please let me
Hi Lu,
I am not actively working on Flink and this JIRA recently. If Xuannan does
not plan to work on this anytime soon, I personally think it will be great
if you can help work on this FLIP. Maybe we can start the voting thread if
there is no further comment on this FLIP.
Xuannan, what do you
Hi Ken,
Sorry for the late reply. I didn't notice this email from you until now.
In this scenario you described above, I don't think operator2 will see the
result modified by operato1. Note that object re-use applies only to the
transmission of data between operators in the same operator chain.
Hi,
Is this still under active development? I notice
https://issues.apache.org/jira/browse/FLINK-32476 is labeled as
deprioritized. If this is the case, would it be acceptable for us to take
on the task?
Best
Lu
On Thu, Oct 19, 2023 at 4:26 PM Ken Krugler
wrote:
> Hi Dong,
>
> Sorry for not
Hi Dong,
Sorry for not seeing this initially. I did have one question about the
description of the issue in the FLIP:
> However, in cases where the upstream and downstream operators do not store or
> access references to the input or output records, this deep-copy overhead
> becomes
Hi Xuannan,
I still think that we should get rid of the object re-use thing all
together, but I have no comments on this FLIP specifically.
Best regards,
Martijn
On Mon, Oct 16, 2023 at 1:03 PM Xuannan Su wrote:
>
> Hi Martijn,
>
> Do you have further comments regarding the FLIP? If not, I'd
Hi Martijn,
Do you have further comments regarding the FLIP? If not, I'd like to
move forward and start the voting in two days.
Best regards,
Xuannan
On Sat, Oct 7, 2023 at 3:02 PM Xuannan Su wrote:
>
> Hi Martijn,
>
> Sorry for the late reply. I don't think it is feasible to always
> enable
Hi Martijn,
Sorry for the late reply. I don't think it is feasible to always
enable object reuse. If I understand correctly, object reuse is
disabled by default to guarantee correctness because we cannot assume
that the custom operator/function is safe to enable object reuse.
The method proposed
Hi Xuannan,
I have one question more from a strategic point of view: given that
we're working on Flink 2.0, wouldn't we actually want to be in a
situation where object-reuse is always used and don't make it
configurable anymore? IIRC, the only reason why it's a configuration
is for backward
Hi all,
We would like to revive the discussion and provide a quick update on
the recent work of the FLIP. We have implemented a POC[1], run cases
in the flink-benchmarks[2] against the POC, and verified that many of
the operators in the benchmark will enable object-reuse without code
changes,
Hi Jing,
Thank you for the suggestion. Yes, we can extend it to support null if in
the future we find any use-case for this flexibility.
Best,
Dong
On Thu, Jul 6, 2023 at 7:55 PM Jing Ge wrote:
> Hi Dong,
>
> one scenario I could imagine is that users could enable global object
> reuse
Hi Dong,
one scenario I could imagine is that users could enable global object reuse
features but force deep copy for some user defined specific functions
because of any limitations. But that is only my gut feeling. And agree, we
could keep the solution simple for now as FLIP described and
Hi Jing,
Thank you for the detailed explanation. Please see my reply inline.
On Thu, Jul 6, 2023 at 3:17 AM Jing Ge wrote:
> Hi Xuannan, Hi Dong,
>
> Thanks for your clarification.
>
> @Xuannan
>
> A Jira ticket has been created for the doc update:
>
Hi Xuannan, Hi Dong,
Thanks for your clarification.
@Xuannan
A Jira ticket has been created for the doc update:
https://issues.apache.org/jira/browse/FLINK-32546
@Dong
I don't have a concrete example. I just thought about it from a conceptual
or pattern's perspective. Since we have 1.
Hi Jing,
Thanks for the comments! Please find below my comments, which are based on
the offline discussion with Xuannan.
On Wed, Jul 5, 2023 at 1:36 AM Jing Ge wrote:
> Hi Xuannan, Hi Dong
>
> Thanks for the Proposal! After reading the FLIP, I'd like to ask some
> questions:
>
> 1. Naming
Hi Jing Ge,
Thank you for your valuable comments!
1. I agree with your suggestion regarding following the JavaBean
convention. It would be beneficial to incorporate this convention into
our Code Style Guide [1]. By doing so, we can ensure consistency and
make it easier for developers to adhere
Hi Xuannan, Hi Dong
Thanks for the Proposal! After reading the FLIP, I'd like to ask some
questions:
1. Naming convention for boolean variables. It is recommended to follow
JavaBean [1], i.e. objectReuseCompliant as the variable name with
isObjectReuseCompliant() and setObjectReuseCompliant() as
Hi all,
Dong(cc'ed) and I are opening this thread to discuss our proposal to
add operator attribute to allow operator to specify support for
object-reuse [1].
Currently, the default configuration for pipeline.object-reuse is set
to false to avoid data corruption, which can result in suboptimal
23 matches
Mail list logo
