[
https://issues.apache.org/jira/browse/FLINK-34670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinzhong Li updated FLINK-34670:
--------------------------------
Description:
Now, the asyncOperations ThreadPoolExecutor of SubtaskCheckpointCoordinatorImpl
is create with a LinkedBlockingQueue and zero corePoolSize.
!image-2024-03-14-20-24-14-198.png|width=614,height=198!
And in the ThreadPoolExecutor, except for the first time the task is submitted,
*no* new thread is created until the queue is full. But the 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=614,height=175!
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=606,height=235!
was:
Now, the asyncOperations ThreadPoolExecutor of SubtaskCheckpointCoordinatorImpl
is create with a LinkedBlockingQueue and zero corePoolSize.
!image-2024-03-14-20-24-14-198.png|width=614,height=198!
And in the ThreadPoolExecutor, except for the first time the task is submitted,
*no* new thread is created until the queue is full. But the 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=614,height=175!
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=606,height=235!
> The asyncOperationsThreadPool in SubtaskCheckpointCoordinatorImpl can only
> create one worker thread
> ---------------------------------------------------------------------------------------------------
>
> 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
> Priority: Critical
> Labels: pull-request-available
> 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=614,height=198!
> And in the ThreadPoolExecutor, except for the first time the task is
> submitted, *no* new thread is created until the queue is full. But the
> 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=614,height=175!
> 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=606,height=235!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
