Github user tillrohrmann commented on the issue:
https://github.com/apache/flink/pull/2629
The `notifyCheckpointComplete` will mitigate the problem of adding latency
a little bit but not get rid of it because the tasks are only notified about a
completed checkpoint if the whole checkpoint (all operators have finished their
checkpoints) has succeeded. This can take a noticeable amount of time if you
have a complex topology.
I really would not like to build in a hand tailored solution for the
`AsyncWaitOperator` into the `StreamTask`. This is imo not a good design,
because the `StreamTask` should not know anything about the operators which are
executed within it.
I still think that the checkpoint lock would be a better solution because
then the `Emitter` thread can continue emitting elements right after the
checkpoint (local) has completed and we don't have to introduce custom control
logic for the `AsyncWaitOperator`.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
