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)
