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)

Reply via email to