StateIterator#isEmpty
> is not asynchronous? Moreover, it lacks docs.
>
>
> Best
> Yun Tang
>
> From: Jane Chan
> Sent: Tuesday, March 19, 2024 21:54
> To: dev@flink.apache.org
> Subject: Re: [DISCUSS] FLIP-424: Asynchronous Sta
Hi Zakelly,
I just have one minor question, why the interface of StateIterator#isEmpty is
not asynchronous? Moreover, it lacks docs.
Best
Yun Tang
From: Jane Chan
Sent: Tuesday, March 19, 2024 21:54
To: dev@flink.apache.org
Subject: Re: [DISCUSS] FLIP-424
Hi Zakelly,
Thanks for your clarification. I'm +1 for using `onNext`.
Best,
Jane
On Tue, Mar 19, 2024 at 6:38 PM Zakelly Lan wrote:
> Hi Jane,
>
> Thanks for your comments!
>
> I guess there is no problem with the word 'on' in this scenario, since it
> is an event-driven-like execution model.
Hi Jane,
Thanks for your comments!
I guess there is no problem with the word 'on' in this scenario, since it
is an event-driven-like execution model. I think the word 'hasNext' may be
misleading since there is a 'hasNext' in a typical iterator which returns a
boolean for the existence of a next e
Hi Zakelly,
Thanks for bringing this discussion.
I'm +1 for the overall API design, except for one minor comment about the
name of StateIterator#onHasNext since I feel it is a little bit
unintuitive. Meanwhile, I asked the opinion from GPT, here's what it said
The prefix "on" is commonly used in
Hi everyone,
Thanks for your valuable feedback!
The discussions were vibrant and have led to significant enhancements to
this FLIP. With this progress, I'm looking to initiate the voting in 72
hours.
Please let me know if you have any concerns, thanks!
Best,
Zakelly
On Tue, Mar 19, 2024 at 5:
Hi Yue,
Thanks for your comments!
1. Is it possible for all `FutureUtils` in Flink to reuse the same util
> class?
Actually, the `FutureUtils` here is a new util class that will share the
same package path with the `StateFuture`. Or I'd be fine renaming it
'StateFutureUtils'.
2. It seems that t
Hi Zakelly,
Thanks for your proposal. The FLIP looks good to me +1! I'd like to ask
some minor questions
I found that there is also a definition of class `FutureUtils` under `org.
apache. flink. util. concurrent` which seems to offer more interfaces. My
question is:
1. Is it possible for all `Fut
indeed! I missed that part. Thanks for the hint!
Best regards,
Jing
On Wed, Mar 13, 2024 at 6:02 AM Zakelly Lan wrote:
> Hi Jing,
>
> The deprecation and removal of original APIs is beyond the scope of
> current FLIP, but I do add/highlight such information under "Compatibility,
> Deprecation,
Okay, sorry, I'm not looking at the latest version of the FLIP. You've
answered my question in updated FLIP. :)
Best regards,
Weijie
weijie guo 于2024年3月13日周三 14:56写道：
> Hi Zakelly,
>
> Thanks for the proposal! I like this idea and I can see the performance
> improvements it brings.
>
> In the
Hi Zakelly,
Thanks for the proposal! I like this idea and I can see the performance
improvements it brings.
In the previous reply you mentioned “these APIs are in some newly
introduced classes, which are located in a different package name with the
original one”. I can see the benefits of this. T
Hi Jing,
The deprecation and removal of original APIs is beyond the scope of current
FLIP, but I do add/highlight such information under "Compatibility,
Deprecation, and Migration Plan" section.
Best,
Zakelly
On Wed, Mar 13, 2024 at 9:18 AM Yunfeng Zhou
wrote:
> Hi Zakelly,
>
> Thanks for you
Hi Zakelly,
Thanks for your responses. I agree with it that we can keep the design
as it is for now and see if others have any better ideas for these
questions.
Best,
Yunfeng
On Tue, Mar 12, 2024 at 5:23 PM Zakelly Lan wrote:
>
> Hi Xuannan,
>
> Thanks for your comments, I modified the FLIP acc
Hi Zakelly,
Thanks for your clarification! I would suggest explicitly adding
description(better highlight) into the FLIP that the original State API
will be deprecated. My gut feeling is that it is very important for anyone,
who will review the new design, to understand the long-term intention.
B
Hi Xuannan,
Thanks for your comments, I modified the FLIP accordingly.
Hi Yunfeng,
Thanks for sharing your opinions!
Could you provide some hint on use cases where users need to mix sync
> and async state operations in spite of the performance regression?
> This information might help address o
Hi Zakelly,
Thanks for the quick response!
> Actually splitting APIs into two sets ... warn them in runtime.
Could you provide some hint on use cases where users need to mix sync
and async state operations in spite of the performance regression?
This information might help address our concerns o
Hi Zakelly,
Thanks for the quick response.
> It will be used in callback chaining cases where some branch within one
> callback does nothing. I'm in favor of short phrases to express the
> functionalities. Thus I suggest `completedVoidFuture` or `voidFuture`, WDTY?
I'd prefer `completedVoidFutur
Hi Xuannan,
Thanks for your comments!
1. The name `emptyFuture` seems a little unintuitive, and it is hard
> to understand in what use case the `emptyFuture` should be used. If I
> understand correctly, it is similar to the
> FutureUtils#completedVoidFuture. How about naming it
> completedVoidSta
Hi Yunfeng,
Thanks for your comments!
+1 for JingGe's suggestion to introduce an AsyncState API, instead of
> having both get() and asyncGet() in the same State class. As a
> supplement to its benefits, this design could help avoid having users
> to use sync and async API in a mixed way (unless t
Hi Zakelly,
Thank you for the proposal! Please find my comments below.
1. The name `emptyFuture` seems a little unintuitive, and it is hard
to understand in what use case the `emptyFuture` should be used. If I
understand correctly, it is similar to the
FutureUtils#completedVoidFuture. How about n
Hi Zakelly,
Thanks for the proposal! The structure of the Async API generally
looks good to me. Some comments on the details of the design are as
follows.
+1 for JingGe's suggestion to introduce an AsyncState API, instead of
having both get() and asyncGet() in the same State class. As a
supplemen
Hi Jing,
Thanks for your comments!
Sorry for not making this clear. Actually these APIs are in some newly
introduced classes, which are located in a different package name with the
original ones. I suggest we name it "State API V2" and the package name
will be 'org.apache.flink.api.common.state.v
Hi Zakelly,
Thanks for your proposal. The FLIP looks in good shape. +1 for it! I'd like
to ask some questions to understand your thoughts more precisely.
1. StateFuture is a new interface. At first glance, it should
be @Experimental. But according to our API Arch rule[1], it should be at
least @P
Hi devs,
I'd like to start a discussion on a sub-FLIP of FLIP-423: Disaggregated
State Storage and Management[1], which is a joint work of Yuan Mei, Zakelly
Lan, Jinzhong Li, Hangxiang Yu, Yanfei Lei and Feng Wang:
- FLIP-424: Asynchronous State APIs [2]
This FLIP introduces new APIs for asynch
24 matches
Mail list logo
