Jinzhong Li created FLINK-34670: ----------------------------------- Summary: Use SynchronousQueue to create asyncOperationsThreadPool for SubtaskCheckpointCoordinatorImpl Key: FLINK-34670 URL: https://issues.apache.org/jira/browse/FLINK-34670 Project: Flink Issue Type: Bug Components: Runtime / Checkpointing, Runtime / State Backends Affects Versions: 1.18.0, 1.19.0 Reporter: Jinzhong Li Fix For: 1.20.0 Attachments: image-2024-03-14-20-24-14-198.png, image-2024-03-14-20-27-37-540.png, image-2024-03-14-20-33-28-851.png
Now, the asyncOperations ThreadPoolExecutor of SubtaskCheckpointCoordinatorImpl is create with a LinkedBlockingQueue and zero corePoolSize. !image-2024-03-14-20-24-14-198.png|width=456,height=147! And in the ThreadPoolExecutor, except for the first time the task is submitted, *no* new thread is created until the queue is full. But this capacity of LinkedBlockingQueue is Integer.Max. This means that there is almost *only one thread* working in this thread pool, even if there are many concurrent checkpoint requests or checkpoint abort requests waiting to be processed. !image-2024-03-14-20-27-37-540.png|width=575,height=164! This problem can be verified by changing ExecutorService implementation in UT SubtaskCheckpointCoordinatorTest#testNotifyCheckpointAbortedDuringAsyncPhase. When the LinkedBlockingQueue is used, this UT will deadlock because only one worker thread can be created. !image-2024-03-14-20-33-28-851.png|width=598,height=232! -- This message was sent by Atlassian Jira (v8.20.10#820010)