Hi everyone, I am a bit late to the voting party but let me ask three questions:
1) Why do we execute the trigger plan computation in the main thread if we cannot guarantee that all tasks are still running when triggering the checkpoint? Couldn't we do the computation in a different thread in order to relieve the main thread a bit. 2) The implementation of the DefaultCheckpointPlanCalculator seems to go over the whole topology for every calculation. Wouldn't it be more efficient to maintain the set of current tasks to trigger and check whether anything has changed and if so check the succeeding tasks until we have found the current checkpoint trigger frontier? 3) When are we going to send the endOfInput events to a downstream task? If this happens after we call finish on the upstream operator but before snapshotState then it would be possible to shut down the whole topology with a single final checkpoint. I think this part could benefit from a bit more detailed description in the FLIP. Cheers, Till On Fri, Jul 2, 2021 at 8:36 AM Yun Gao <yungao...@aliyun.com.invalid> wrote: > 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 (non-binding) > - Guowei Ma (binding) > > Thus I'm happy to announce that the update to the FLIP-147 is accepted. > > Very thanks everyone! > > Best, > Yun > > [1] https://cwiki.apache.org/confluence/x/mw-ZCQ
