Rui Fan created FLINK-40521:
-------------------------------
Summary: Potential lost priority-barrier wakeup in
LocalInputChannel during checkpointing-during-recovery
Key: FLINK-40521
URL: https://issues.apache.org/jira/browse/FLINK-40521
Project: Flink
Issue Type: Sub-task
Components: Runtime / Checkpointing
Reporter: Rui Fan
Assignee: Rui Fan
`hasPendingPriorityEvent` is set lock-free in `notifyPriorityEvent` [1] and
cleared lock-free in `pullPriorityFromSubpartitionView` [2]. The clear decides
on the `next.getNextDataType()` snapshot from when the current barrier was
popped; if a next barrier is enqueued after that pop, its set-true is clobbered
by the clear. The flag then stays false — and a further priority element fires
no new notify — so the barrier sits unconsumed in `subpartitionView` (the
recovery path reaches it only via this flag) until recovery ends and self-heals.
Not currently reachable: Flink runs no concurrent unaligned checkpoints, so a
second barrier can't be pending while the first still is. Documented as a code
comment rather than fixed; a fix would be a compare-and-clear under
`recoveredBuffers`.
[1]
[https://github.com/apache/flink/blob/76e774e04ff84ea305714153c5f4790fff98437c/flink-runtime/src/main/java/org/apache/flink/runtime/io/network/partition/consumer/LocalInputChannel.java#L776-L782]
[2]
[https://github.com/apache/flink/blob/76e774e04ff84ea305714153c5f4790fff98437c/flink-runtime/src/main/java/org/apache/flink/runtime/io/network/partition/consumer/LocalInputChannel.java#L667-L674]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
