[
https://issues.apache.org/jira/browse/FLINK-40521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rui Fan resolved FLINK-40521.
-----------------------------
Fix Version/s: 2.4.0
Resolution: Fixed
Merged to master(2.4.0) via: a0d52bdb14520661c0332938ec4b073ae5e57aac
> 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
> Priority: Major
> Labels: pull-request-available
> Fix For: 2.4.0
>
>
> `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)
