Thanks a lot ! @Chesnay Schepler@Tzu-Li Chen : )
Yours
Yun Gao
--
发件人：Chesnay Schepler
发送时间：2018年10月1日(星期一) 17:10
收件人：dev ; Tzu-Li Chen ; yungao.gy
; trohrmann ; Stephan Ewen
主 题：Re: Request for contributor permission
@Yun
icator.
Besides, another similar thought is that we may also add new
InputBufferUsage and OutputBufferUsage metrics to show (number of queued
buffers / number of all buffers) instead.
Best,
Yun Gao
[1] https://issues.apache.org/jira/browse/FLINK-10981
[2] https://issues.apac
obey
the blacklist, then we may need to deal with the inappropriate resource.
Looking forward to the future advance of this feature! Thanks again for
the exciting proposal.
Best,
Yun Gao
--
From:zhijiang
Send Time:2018 Nov
the
design doc!
Yours sincerely
Yun Gao
--
发件人：Weihua Jiang
发送时间：2018年11月20日(星期二) 20:53
收件人：dev
主 题：[DISCUSS] Embracing Table API in Flink ML
ML Pipeline is the idea brought by Scikit-learn
<https://arxiv.org/abs/1309.0238>
Congratulations!
Best,
Yun
--
From:Robert Metzger
Send Time:2019 Jun. 24 (Mon.) 23:16
To:dev
Subject:[ANNOUNCE] Jincheng Sun is now part of the Flink PMC
Hi all,
On behalf of the Flink PMC, I'm happy to announce that Jincheng
Congratulations Andrey!
Best,
Yun
--
From:Congxian Qiu
Send Time:2019 Aug. 15 (Thu.) 10:28
To:dev@flink.apache.org
Subject:Re: [ANNOUNCE] Andrey Zagrebin becomes a Flink committer
Congratulations Andery!
Best,
Congxian
Kurt
Hi,
Very thanks for the great points!
For the prioritizing inputs, from another point of view, I think it might
not cause other bad effects, since we do not need to totally block the channels
that have seen barriers after the operator has taking snapshot. After the
snapshotting, if the
Hi,
Very thanks for sharing the thoughts on the unaligned checkpoint !
Another question regarding I 2.C (Performance) by Paris is that do we
always snapshot and broadcast the marks once the task receives the first mark
from JM o? If so, then we will always need to snapshot all the
Hi everyone,
In some scenarios we met a requirement that some operators want to send
records to theirs downstream operators with an multicast communication pattern.
In detail, for some records, the operators want to send them according to the
partitioner (for example, Rebalance), and for
to decouple the broadcasting
events requirements and more generalized multicasting mechanism. :)
Best,
Yun
--
From:SHI Xiaogang
Send Time:2019 Aug. 27 (Tue.) 09:16
To:dev ; Yun Gao
Cc:Piotr Nowojski
Subject:Re: [DISCUSS] Enhance
d also prefer
to see a motivation design doc, how that feature would be used for example for
cross or theta joins in the Table API, since very similar questions would apply
to that as well.
Piotrek
> On 27 Aug 2019, at 08:10, SHI Xiaogang wrote:
>
> Hi Yun Gao,
>
>
che.org/jira/browse/FLINK-6936
On Aug 24, 2019, at 5:54 AM, Zhu Zhu wrote:
Hi Piotr,
Thanks for the explanation.
Agreed that the broadcastEmit(record) is a better choice for
broadcasting
for the iterations.
As broadcasting for the iterations is the first motivation, let's
support
it first.
Thanks,
Z
is hard to maintain and extend.
Thanks,
Zhu Zhu
Yun Gao 于2019年8月22日周四 下午8:42写道：
Hi everyone,
In some scenarios we met a requirement that some operators want to
send records to theirs downstream operators with an multicast communication
pattern. In detail, for some records, the operators
at 10:20, Yun Gao wrote:
>
>Hi Piotr,
>
> Thanks a lot for the suggestions!
>
> The core motivation of this discussion is to implement a new
> iteration library on the DataStream, and it requires to insert special
> records in the
--
From:Piotr Nowojski
Send Time:2019 Aug. 23 (Fri.) 22:29
To:Zhu Zhu
Cc:dev ; Yun Gao
Subject:Re: [DISCUSS] Enhance Support for Multicast Communication Pattern
Hi,
If the primary motivation is broadcasting (for the iterations) and we have no
immediate need for multicast (cross join
Congratulations Zili!
Best,
Yun
--
From:Yangze Guo
Send Time:2019 Sep. 12 (Thu.) 09:38
To:dev
Subject:Re: [ANNOUNCE] Zili Chen becomes a Flink committer
Congratulations!
Best,
Yangze Guo
On Thu, Sep 12, 2019 at
Congratulations, Kostas!
Best,
Yun
--
From:Becket Qin
Send Time:2019 Sep. 9 (Mon.) 10:47
To:dev
Subject:Re: [ANNOUNCE] Kostas Kloudas joins the Flink PMC
Congrats, Kostas!
On Sun, Sep 8, 2019 at 11:48 PM
Congratulations Hequn!
Best,
Yun
--
From:Congxian Qiu
Send Time:2019 Aug. 8 (Thu.) 21:34
To:Yu Li
Cc:Haibo Sun ; dev ; Rong Rong
; user
Subject:Re: Re: [ANNOUNCE] Hequn becomes a Flink committer
Congratulations Hequn!
Best,
Congratulations Zhijiang!
Best,
Yun
--
From:Paul Lam
Send Time:2019 Jul. 23 (Tue.) 09:38
To:dev
Subject:Re: [ANNOUNCE] Zhijiang Wang has been added as a committer to the Flink
project
Congrats Zhijiang!
Best,
Paul Lam
> 在
Congratulations Kurt!
best,
Yun
--
From:Jeff Zhang
Send Time:2019 Jul. 23 (Tue.) 18:14
To:dev
Subject:Re: [ANNOUNCE] Kete Young is now part of the Flink PMC
Congratulations Kurt
Biao Liu 于2019年7月23日周二 下午6:07写道：
> Congrats
Congratulations!
Best,
Yun
--
From:Kostas Kloudas
Send Time:2019 Jul. 18 (Thu.) 17:30
To:dev
Subject:Re: [ANNOUNCE] Jiangjie (Becket) Qin has been added as a committer to
the Flink project
Congratulations Becket!
Kostas
On
+1 (non-binding)
Very thanks for bringing this to the community!
--
From:jincheng sun
Send Time:2019 Oct. 31 (Thu.) 10:22
To:dev
Cc:Vasiliki Kalavri
Subject:Re: [VOTE] Accept Stateful Functions into Apache Flink
big +1
Congratulations Jark！
Best,
Yun
--
From:wenlong.lwl
Send Time:2019 Nov. 8 (Fri.) 18:31
To:dev
Subject:Re: [ANNOUNCE] Jark Wu is now part of the Flink PMC
Congratulations Jark, well deserved!
Best,
Wenlong Lyu
On Fri, 8 Nov
Congratulations Zhuzhu!
Best,
Yun
--
From:Guowei Ma
Send Time:2019 Dec. 16 (Mon.) 11:16
To:dev
Subject:Re: [ANNOUNCE] Zhu Zhu becomes a Flink committer
Congrats Zhuzhu!
Best,
Guowei
Zhenghua Gao 于2019年12月16日周一
Congratulations Becket!
Best,
Yun
--
From:Jingsong Li
Send Time:2019 Oct. 29 (Tue.) 10:23
To:dev
Subject:Re: [ANNOUNCE] Becket Qin joins the Flink PMC
Congratulations Becket!
Best,
Jingsong Lee
On Tue, Oct 29, 2019 at 10:18 AM
Hi Chesnay,
+1 (non-binding).
Very thanks for driving this.
Best,
Yun
--
From:Chesnay Schepler
Send Time:2019 Oct. 16 (Wed.) 21:01
To:dev@flink.apache.org
Subject:[VOTE] FLINK-67: Cluster
Hi Arvid,
Very thanks for bring up the discussion! From our side unable to
finish the checkpoint is commonly met for online jobs, therefore +1 from my
side to implement this.
A tiny issue of the FLIP is that the Discussion Thread URL attached
seems to be not right.
Congratulations Yu!
Best,
Yun
--
From:felixzheng zheng
Send Time:2020 Jan. 31 (Fri.) 10:19
To:dev
Subject:Re: [ANNOUNCE] Yu Li became a Flink committer
Congrats!
Benchao Li 于2020年1月31日周五 上午10:02写道：
>
Congratulations Jingsong!
Best,
Yun
--
From:Jingsong Li
Send Time:2020 Feb. 21 (Fri.) 21:42
To:Hequn Cheng
Cc:Yang Wang ; Zhijiang ;
Zhenghua Gao ; godfrey he ; dev
; user
Subject:Re: [ANNOUNCE] Jingsong Lee becomes a
+1 (non-binding)
This should make tuning back pressure easier, which is one of the most
common problems met for users.
Best,
Yun
--
From:Benchao Li
Send Time:2020 Feb. 24 (Mon.) 08:32
To:dev
Cc:Zhijiang
+1 (non-binding).
Very thanks for introducing this topic back, and it should be able to bring
improvements in the discussed scenarios.
Best,
Yun
--
From:Arvid Heise
Send Time:2020 Jan. 10 (Fri.) 16:48
To:dev ; Zhijiang
Hi Dominik,
If I understand the scenario correctly, I think one possible solution
is to implement one specified TwoInputStreamOperator directly, and also
implements the InputSelectable interface. Then this operator could control the
priority its two inputs by return proper
+1 (non-binding)
I think the PoC result has shown the effect on reducing checkpoint time
when back-pressure occurs, and I totally agree with that the feature could be
implemented in steps.
--
From:Roman Khachatryan
Send
Congratulations Hequn!
Best,
Yun
--
From:Hequn Cheng
Send Time:2020 Apr. 18 (Sat.) 12:48
To:dev
Subject:Re: [ANNOUNCE] New Apache Flink PMC Member - Hequn Chen
Many thanks for your support. Thank you!
Hi,
Very thanks for Jinsong to bring up this discussion! It should largely
improve the usability after enhancing the FileSystem connector in Table.
I have the same question with Piotr. From my side, I think it should be
better to be able to reuse existing
Hi Dhurandar:
Currently StreamingFileSink should be able to change the prefix and suffix
of the filename[1], it could be changed to something like -0-0.
Could this solve your problem ?
Best,
Yun
[1]
Congratulations Niels!
Best,
Yun
--
Sender:Congxian Qiu
Date:2020/09/15 13:33:31
Recipient:dev@flink.apache.org
Theme:Re: [ANNOUNCE] New Apache Flink Committer - Niels Basjes
Congratulations
Best,
Congxian
Yang Wang
Congratulations Arvid !
Best,
Yun
--Original Mail --
Sender:Yangze Guo
Send Date:Tue Sep 15 13:39:56 2020
Recipients:dev
Subject:Re: [ANNOUNCE] New Apache Flink Committer - Arvid Heise
Congrats! Arvid.
Best,
Yangze Guo
On Tue, Sep 15, 2020 at 1:31 PM
Very thanks for bring this up!
+1 (non-binding)
Best,
Yun
--
Sender:Seth Wiesman
Date:2020/09/14 21:56:55
Recipient:dev
Theme:Re: [VOTE] FLIP-140: Introduce bounded style execution for keyed streams
+1 (binding)
Seth
On Thu,
Congratulations Yun Tang!
Best,
Yun Gao
--
Sender:Zhu Zhu
Date:2020/09/15 18:49:24
Recipient:dev
Cc:; Yun Tang
Theme:Re: [ANNOUNCE] New Apache Flink Committer - Yun Tang
Congratulations!
Thanks,
Zhu
Yu Li 于2020年9月15日周二 下午6:19写
Congratulations Igal!
Best,
Yun
--
Sender:Stephan Ewen
Date:2020/09/15 22:48:30
Recipient:dev
Theme:Re: [ANNOUNCE] New Apache Flink Committer - Igal Shilman
Welcome, Igal!
On Tue, Sep 15, 2020 at 3:18 PM Seth Wiesman wrote:
+1 (non-binding)
Very thanks for bring this up! And the FLIP is indeed necessary for stream &
batch unification.
--
Sender:Dawid Wysakowicz
Date:2020/09/16 15:01:08
Recipient:; Aljoscha Krettek
Theme:Re: [VOTE] FLIP-134: Batch
Very thanks for bring this up! +1 for deprecating the DataSet API and
providing a unified streaming/batch programming model to users.
Best,
Yun
--
Sender:Aljoscha Krettek
Date:2020/09/02 19:22:51
Recipient:Flink Dev
Hi, devs & users
Very sorry for the spoiled formats, I resent the discussion as follows.
As discussed in FLIP-131[1], Flink will make DataStream the unified API for
processing bounded and unbounded data in both streaming and blocking modes.
However, one long-standing problem for the streaming
Hi, devs & users
As discussed in FLIP-131 [1], Flink will make DataStream the unified API for
processing bounded and unbounded data in both streaming and blocking modes.
However, one long-standing problem for the streaming mode is that currently
Flink does not support checkpoints after some
nd Time:2020 Oct. 13 (Tue.) 17:25
To:Yun Gao
Cc:Arvid Heise ; Flink Dev ;
User-Flink
Subject:Re: [DISCUSS] FLIP-147: Support Checkpoints After Tasks Finished
Thanks for starting this discussion Yun Gao,
I have three comments/questions:
1) When restarting all tasks independent of the status at ch
first time that we
recover an incomplete DAG. Afaik the subtasks are deployed before the state is
recovered, so at some point, the subtasks either need to be removed again or
maybe we could even avoid them being created in the first place.
[1] https://issues.apache.org/jira/browse/FLINK-
ore the problem on how to store and restore output buffers of a completed
task (also important for the next point).
5) I think we are on the same page and I completely agree that for the
MVP/first version, it's completely fine to start and immediately stop. A tad
better would be even to
Congratulations Zhu!
Best,
Yun--
Sender:Arvid Heise
Date:2020/10/05 15:53:01
Recipient:dev
Cc:
Theme:Re: [ANNOUNCE] New PMC member: Zhu Zhu
Congratulations Zhu Zhu!
On Mon, Oct 5, 2020 at 9:28 AM Till Rohrmann wrote:
> Congrats
Hi,
Very thanks for bringing up this discussion!
One more question is that does the BATCH and STREAMING mode also decides
the shuffle types and operators? I'm asking so because that even for blocking
mode, it should also benefit from keeping some edges to be pipeline if the
resources
+1 for removing the methods that are deprecated for a while & have alternative
methods.
One specific thing is that if we remove the DataStream#split, do we consider
enabling side-output in more operators in the future ? Currently it should be
only available in ProcessFunctions, but not
Congratulations Dian !
Best
Yun
--
Sender:Marta Paes Moreira
Date:2020/08/27 17:42:34
Recipient:Yuan Mei
Cc:Xingbo Huang; jincheng sun;
dev; Dian Fu;
user; user-zh
Theme:Re: [ANNOUNCE] New PMC member: Dian Fu
Congrats, Dian!
Hi Prasanna,
1) Semantically both a) and b) would be Ok. If the Custom sink could be
chained with the map operator (I assume the map operator is the "Processing" in
the graph), there should be also no much difference physically, if they could
not chain, then writting a custom sink would
Great! Very thanks @ZhuZhu for driving this and thanks for all contributed to
the release!
Best,
Yun
--Original Mail --
Sender:Jingsong Li
Send Date:Thu Sep 17 13:31:41 2020
Recipients:user-zh
CC:dev , user , Apache Announce
List
Subject:Re: [ANNOUNCE]
Congratulations Godfrey!
Best,
Yun
--Original Mail --
Sender:Dawid Wysakowicz
Send Date:Thu Sep 17 14:45:55 2020
Recipients:Flink Dev , 贺小令
Subject:Re: [ANNOUNCE] New Apache Flink Committer - Godfrey He
Congratulations!
On 16/09/2020 06:19, Jark Wu wrote:
>
Congratulations Yu!
Best,
Yun
--
Sender:Zhijiang
Date:2020/06/17 11:18:35
Recipient:Dian Fu; dev
Cc:Haibo Sun; user;
user-zh
Theme:Re: [ANNOUNCE] Yu Li is now part of the Flink PMC
Congratulations Yu! Well deserved!
Best,
Hi Dhurandar,
With my understand I think what you need is to get notified when a file is
written successfully (committed) on the S3 FileSystem. However, currently there
is no public API for the listener and there an issue tracking it [1].
With the current version, one possible method
Congratulates Xintong !
Best
Yun
--
Sender:Leonard Xu
Date:2020/06/05 12:51:20
Recipient:dev
Cc:Xintong Song
Theme:Re: [ANNOUNCE] New Apache Flink Committer - Xintong Song
Congratulates Xintong !
Best,
Leonard Xu
> 在
Congratulations, Benchao!
Best,
Yun
--
Sender:Danny Chan
Date:2020/06/10 20:01:01
Recipient:
Theme:Re: [ANNOUNCE] New Flink Committer: Benchao Li
Congrats Benchao!
Best,
Danny Chan
在 2020年6月10日 +0800
+1 for have a editorconfig file that is more consistent with Flink's code
sytle.
From my own experience, whenever I open the Flink repo for the first time, I
have to manually change the continuation indent to 4 and disable the wildcard
imports. I also think that it should be more nice to new
Congratulations Piotr !
Best,
Yun
--
Sender:Austin Bennett
Date:2020/07/07 10:06:15
Recipient:
Theme:Re: [ANNOUNCE] New PMC member: Piotr Nowojski
Thanks for what you do, Piotr!
On Mon, Jul 6, 2020, 7:02 PM Matt Wang wrote:
>
Hi Roman,
Very thanks for the feedbacks and suggestions!
> I think UC will be the common case with multiple sources each with
DoP > 1.
> IIUC, waiting for EoP will be needed on each subtask each time one of
it's source subtask finishes.
Yes, waiting for
.
Best,
Yun
--Original Mail --
Sender:Arvid Heise
Send Date:Thu Jan 7 00:52:27 2021
Recipients:Aljoscha Krettek
CC:dev , Yun Gao
Subject:Re: [DISCUSS] FLIP-147: Support Checkpoints After Tasks Finished
Okay then at least you guys are in sync ;) (Although I'
xamples if you go beyond chained operators and
fully connected exchanges. Think of any fan-in, let's assume you have
source S1...S4, with S1+S2->M1, and S3+S4->M2. If S1 is finished, S2 and M1
is still running. Or I didn't get your question ;).
On Tue, Jan 5, 2021 at 5:00 PM Yun G
Hi all,
I would like to resume this discussion for supporting checkpoints after
tasks Finished :) Based on the previous discussion, we now implement a version
of PoC [1] to try the idea. During the PoC we also met with some possible
issues:
1. To include EndOfPartition into
d Time:2020 Dec. 15 (Tue.) 18:11
To:dev
Subject:Re: [DISCUSS] FLIP-147: Support Checkpoints After Tasks Finished
Thanks for the thorough update! I'll answer inline.
On 14.12.20 16:33, Yun Gao wrote:
> 1. To include EndOfPartition into consideration for barrier alignment at
> t
Congratulations Congxian !
Best,
Yun
--
Sender:Leonard Xu
Date:2020/10/29 21:19:56
Recipient:dev
Theme:Re: [ANNOUNCE] New Apache Flink Committer - Congxian Qiu
Congratulations! Congxian
Best,
Leonard
> 在 2020年10月29日，20:55，Stephan
he thorough update! I'll answer inline.
On 14.12.20 16:33, Yun Gao wrote:
> 1. To include EndOfPartition into consideration for barrier alignment at
> the TM side, we now tend to decouple the logic for EndOfPartition with the
> normal alignment behaviors to avoid the complex interference (whic
rained on OperatorSubtaskState. Maybe we
can store the flag inside managed or raw state without changing the format?
On Fri, Dec 25, 2020 at 8:39 AM Yun Gao wrote:
Hi all,
I tested the previous PoC with the current tests and I found some new
issues that might cause divergence, and
Hi Aljoscha,
Very thanks for the feedbacks!
For the second issue, I'm indeed thinking the race condition between
deciding to trigger and operator get finished. And for this point,
> One thought here is this: will there ever be intermediate operators that
> should be
Hi Arvid,
Very thanks for the feedbacks! I'll try to answer the questions inline:
> I'm also concerned about the notion of a final checkpoint. What happens
> when this final checkpoint times out (checkpoint timeout > async timeout)
> or fails for a different reason? I'm currently more inclined
Hi Roman,
Very thanks for the feedbacks !
> Probably it would be simpler to just decline the RPC-triggered
checkpoint
> if not all inputs of this task are finished (with
CHECKPOINT_DECLINED_TASK_NOT_READY).
> But I wonder how significantly this waiting
(binding)
Best,
Arvid
On Wed, Jan 20, 2021 at 12:13 PM Aljoscha Krettek
wrote:
> +1 (binding)
>
> Best,
> Aljoscha
>
> On 2021/01/15 22:55, Yun Gao wrote:
> >
> >Hi all,
> >
> >I would like to start the vote for FLIP-147[1], which propose to sup
Congratulations Guowei!
Best,
Yun--
Sender:Yangze Guo
Date:2021/01/20 13:48:52
Recipient:dev
Theme:Re: [ANNOUNCE] Welcome Guowei Ma as a new Apache Flink Committer
Congratulations, Guowei! Well deserved.
Best,
Yangze Guo
On Wed,
Hi all,
We have some offline discussion together with @Arvid, @Roman and @Aljoscha and
I'd
like to post some points we discussed:
1) For the problem that the "new" root task coincidently finished before
getting triggered
successfully, we have listed two options in the FLIP-147[1], for the
Hi,
Very thanks for @Timo to initiate the discussion!
I would also +1 for providing some informations to users via annotations
or documents in advanced to not suprise users before we actually remove the
legacy code.
If we finally decide to change one functionality that user could sense,
Congratulations, Danny!
Best,
Yun
--
From:Xintong Song
Send Time:2021 Jan. 13 (Wed.) 15:29
To:dev
Subject:Re: [ANNOUNCE] Welcome Danny Cranmer as a new Apache Flink Committer
Congratulations, Danny.
Welcome aboard.
Thank you~
Hi all,
I updated the FLIP[1] to reflect the major discussed points in the ML thread:
1) For the "new" root tasks finished before it received trigger message,
previously we proposed
to let JM re-compute and re-trigger the descendant tasks, but after the
discussion we realized that
it might
: [DISCUSS] FLIP-147: Support Checkpoints After Tasks Finished
Thanks for the summary! I think we can now move towards a [VOTE] thread,
right?
On 2021/01/15 13:43, Yun Gao wrote:
>1) For the problem that the "new" root task coincidently finished
>before getting triggered succe
Hi all,
I would like to start the vote for FLIP-147[1], which propose to support
checkpoints after
tasks finished and is discussed in [2].
The vote will last at least 72 hours (Jan 20th due to weekend), following the
consensus
voting process.
thanks,
Yun
[1]
Hi Roman,
Very thanks for the feedbacks! I'll try to answer the issues inline:
> 1. Option 1 is said to be not preferable because it wastes resources and adds
> complexity (new event).
> However, the resources would be wasted for a relatively short time until the
> job finishes completely.
; his colleagues at Kuaishou maintain an internal version of Flink.
One of their custom features is allowing dynamically changing operator
behaviors via the REST APIs. He's willing to contribute this feature to the
community, and came to Yun Gao and me for suggestions. After discussion, we
feel
makes sense to add `flush`, as most of them
> >>> > shouldn't buffer any data. Apart from Sinks, it's usually an operator
> >>> that
> >>> > is buffering the data (that holds true for AsyncFunction,
> >>> ReduceFunction,
> >>
Congratulations, Xintong!
Best,
Yun
--
Sender:Jingsong Li
Date:2021/06/17 10:41:22
Recipient:dev
Theme:Re: [ANNOUNCE] New PMC member: Xintong Song
Congratulations, Xintong!
Best,
Jingsong
On Thu, Jun 17, 2021 at 10:26 AM Yun
Congratulations, Arvid!
Best,
Yun
--
Sender:Jingsong Li
Date:2021/06/17 10:41:29
Recipient:dev
Theme:Re: [ANNOUNCE] New PMC member: Arvid Heise
Congratulations, Arvid!
Best,
Jingsong
On Thu, Jun 17, 2021 at 6:52 AM Matthias J.
Hi,
Very thanks @Yangze for bringing up this discuss. Overall +1 for
exposing the fine-grained resource requirements in the DataStream API.
One similar issue as Arvid has pointed out is that users may also creating
different SlotSharingGroup objects, with different names but with different
Hi,
Logically using zk HA on k8s cluster is supported.
Attaching files is not support by apache mail server, could
you update the files into some file server and paste the
connections ?
Best,
Yun
--
Sender:bhagi@R
input.
Very thanks for all the deep insights and discussions!
Best,
Yun
--
From:Dawid Wysakowicz
Send Time:2021 Jun. 3 (Thu.) 21:21
To:dev ; Till Rohrmann ; Yun Gao
Cc:Piotr Nowojski ; Guowei Ma ;
Stephan Ewen
Subject:Re: [D
Congratulations Yuan!
Best,
Yun
--Original Mail --
Sender:Zhilong Hong
Send Date:Thu Jul 8 10:50:36 2021
Recipients:dev (dev@flink.apache.org)
Subject:Re: [ANNOUNCE] New Apache Flink Committer - Yuan Mei
Congratulations, Yuan!
Best,
Zhilong
On Thu, Jul 8,
Hi there,
Since the voting time of FLIP-147[1] has passed, I'm closing the vote now.
There were seven +1 votes ( 6 / 7 are bindings) and no -1 votes:
- Dawid Wysakowicz (binding)
- Piotr Nowojski(binding)
- Jiangang Liu (binding)
- Arvid Heise (binding)
- Jing Zhang (binding)
- Leonard Xu
Hi all,
For FLIP-147[1] which targets at supports checkpoints after tasks finished and
modify operator
API and implementation to ensures the commit of last piece of data, since after
the last vote
we have more discussions[2][3] and a few updates, including changes to
PublicEvolving API,
I'd
Congratulations Yang!
Best,
Yun
--
Sender:Jark Wu
Date:2021/07/07 10:20:27
Recipient:dev
Cc:Yang Wang;
Theme:Re: [ANNOUNCE] New Apache Flink Committer - Yang Wang
Congratulations Yang Wang!
Best,
Jark
On Wed, 7 Jul 2021 at
Congratulations Guowei!
Best,
Yun
--
Sender:JING ZHANG
Date:2021/07/07 10:33:51
Recipient:dev
Theme:Re: [ANNOUNCE] New PMC member: Guowei Ma
Congratulations, Guowei Ma!
Best regards,
JING ZHANG
Zakelly Lan 于2021年7月7日周三
Congratulations Roman!
Best,
Yun
--Original Mail --
Sender:Till Rohrmann
Send Date:Wed Feb 10 20:53:21 2021
Recipients:dev
CC:Khachatryan Roman , Roman Khachatryan
Subject:Re: [ANNOUNCE] Welcome Roman Khachatryan a new Apache Flink Committer
Congratulations
Hi Lu,
The image seems not be able to shown due to the mail server limitation, could
you upload it somewhere and paste the link here ?
Logically, I think zigzag usually due to there are some small object get
created and eliminated soon in the heap. Are you running a SQL job or a
DataStream
`OperatorCoordinator` to avoid sending the element to the downstream
> > operator.
> > But I agree we could not limit the users not to emit records in the
> > `notiyCheckpointComplete`.
> >
> > Best,
> > Guowei
> >
> >
> > On Tue
hu Wang
On February 24, 2021 at 23:47:36, Piotr Nowojski (piotr.nowoj...@gmail.com)
wrote:
Thanks for the reponses Guowei and Yun,
Could you elaborate more/remind me, what does it mean to replace emitting
results from the `notifyCheckpointComplete` with `OperatorCoordinator`
approach
totally agree with that the
two are separate and we could think on them
distinctly. Regarding the order, I would still tend to we support the ordered
case, since the sinks' implementation seem to depend
on this functionality.
Best,
Yun
------
i
Send Time:2021 Mar. 4 (Thu.) 17:16
To:Kezhu Wang
Cc:dev ; Yun Gao ;
jingsongl...@gmail.com ; Guowei Ma
; Till Rohrmann
Subject:Re: Re: Re: [DISCUSS] FLIP-147: Support Checkpoints After Tasks Finished
Hi Kezhu,
What do you mean by “end-flushing”? I was suggesting to just keep
`endOfInput()
From:Kezhu Wang
Send Time:2021 Mar. 1 (Mon.) 01:26
To:Till Rohrmann
Cc:Piotr Nowojski ; Guowei Ma ;
dev ; Yun Gao ;
jingsongl...@gmail.com
Subject:Re: Re: Re: [DISCUSS] FLIP-147: Support Checkpoints After Tasks Finished
In “stop-with-savepoint —drain”, MAX_WATERMARK is not an issue.
1 - 100 of 559 matches
Mail list logo
