[FLINK-17477] resumeConsumption call should happen as quickly as possible to minimise latency

• Type: Improvement
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: 1.11.0, 1.12.0
• Component/s: Runtime / Checkpointing, Runtime / Network
• Assignee: Unassigned
• Reporter: Piotr Nowojski
• Created: 30/Apr/20 09:42
• Updated: 08/Dec/20 11:05

Description

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):

// 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();

// 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();

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.

Issue Links

• is caused by: FLINK-16404 Avoid caching buffers for blocked input channels before barrier alignment