Piotr Nowojski created FLINK-17477:
--------------------------------------
Summary: resumeConsumption call should happen as quickly as
possible to minimise latency
Key: FLINK-17477
URL: https://issues.apache.org/jira/browse/FLINK-17477
Project: Flink
Issue Type: Improvement
Components: Runtime / Checkpointing, Runtime / Network
Reporter: Piotr Nowojski
Fix For: 1.11.0
We should be calling {{InputGate#resumeConsumption()}} as soon as possible (to
avoid any unnecessary delay/latency when task is idling). Currently I think
it’s mostly fine - the important bit is that on the happy path, we always
{{resumeConsumption}} before trying to complete the checkpoint, so that netty
threads will start resuming the network traffic while the task thread is doing
the synchronous part of the checkpoint and starting asynchronous part. But I
think in two places we are first aborting checkpoint and only then resuming
consumption (in CheckpointBarrierAligner):
{{code}}
// let the task know we are not completing this
notifyAbort(currentCheckpointId,
new CheckpointException(
"Barrier id: " + barrierId,
CheckpointFailureReason.CHECKPOINT_DECLINED_SUBSUMED));
// abort the current checkpoint
releaseBlocksAndResetBarriers();
{{code}}
// let the task know we skip a checkpoint
notifyAbort(currentCheckpointId,
new
CheckpointException(CheckpointFailureReason.CHECKPOINT_DECLINED_INPUT_END_OF_STREAM));
// no chance to complete this checkpoint
releaseBlocksAndResetBarriers();
{{code}}
It’s not a big deal, as those are a rare conditions, but it would be better to
be consistent everywhere: first release blocks and resume consumption, before
anything else happens.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
