option 2 is probably not feasible, as checkpoint may take a long time or
may fail.
Option 1 might work, although it complicates the job recovery and
checkpoint. After checkpoint completion, we need to clean up those control
signals stored in HA service.
On Tue, Jun 8, 2021 at 1:14 AM 刘建刚 wrote:
Thanks for the reply. It is a good question. There are multi choices as
follows:
1. We can persist control signals in HighAvailabilityServices and replay
them after failover.
2. Only tell the users that the control signals take effect after they
are checkpointed.
Steven Wu [via Apach
I can see the benefits of control flow. E.g., it might help the old (and
inactive) FLIP-17 side input. I would suggest that we add more details of
some of the potential use cases.
Here is one mismatch with using control flow for dynamic config. Dynamic
config is typically targeted/loaded by one sp
+1 on separating the effort into two steps:
1. Introduce a common control flow framework, with flexible interfaces
for generating / reacting to control messages for various purposes.
2. Features that leverating the control flow can be worked on
concurrently
Meantime, keeping collectin
Very thanks Jiangang for bringing this up and very thanks for the discussion!
I also agree with the summarization by Xintong and Jing that control flow seems
to be
a common buidling block for many functionalities and dynamic configuration
framework
is a representative application that frequentl
