[ 
https://issues.apache.org/jira/browse/FLINK-26932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

huweihua updated FLINK-26932:
-----------------------------
    Description: 
The disk TaskManager used had some fatal error. And then TaskManager hung in 
cleanupAllocationBaseDirs and took the main thread.
 
So this TaskManager would not respond to the 
cancelTask/disconnectResourceManager request.
 
At the same time, JobMaster already take this TaskManager is lost, and schedule 
task to other TaskManager.
 
This may cause some unexpected task running.
 
After checking the log of TaskManager, TM already lost the connection with 
ResourceManager, and it is always trying to register with ResourceManager. The 
RegistrationTimeout cannot take effect because the main thread of TaskManager 
is hung-up.
 
I think there are two options to handle it.

Option 1: Add timeout for 
TaskExecutorLocalStateStoreManager.cleanupAllocationBaseDirs, But I am afraid 
some other methods would block main thread too.
Option 2: Move the registrationTimeout in another thread, we need to deal will 
the concurrency problem

 

 
 

  was:
The disk TaskManager used had some fatal error. And then TaskManager hung in 
cleanupAllocationBaseDirs and took the main thread.
 
So this TaskManager would not respond to the 
cancelTask/disconnectResourceManager request.
 
At the same time, JobMaster already take this TaskManager is lost, and schedule 
task to other TaskManager.
 
This may cause some unexpected task running.
 
After checking the log of TaskManager, TM already lost the connection with 
ResourceManager, and it is always trying to register with ResourceManager. The 
RegistrationTimeout cannot take effect because the main thread of TaskManager 
is hung-up.
 
I think there are two options to handle it. # 
Option 1: Add timeout for 
TaskExecutorLocalStateStoreManager.cleanupAllocationBaseDirs, But I am afraid 
some other methods would block main thread too.

 # 
Option 2: Move the registrationTimeout in another thread, we need to deal will 
the concurrency problem
!https://bytedance.feishu.cn/space/api/box/stream/download/asynccode/?code=ZmVkMDNhZjZkNzA2NTNkOGZjNjJmNGM0ZGYxNGY2NDFfTnV4SUd0RzQ3WnVJRWpWdVBJNFFncEMzTHdZZ3U0WDFfVG9rZW46Ym94Y25zMG1GdWM5M2hKNzJEcXhyN0FmRFgxXzE2NDg2NTE4Njg6MTY0ODY1NTQ2OF9WNA!
 
!https://bytedance.feishu.cn/space/api/box/stream/download/asynccode/?code=MDhiZDU0NDg0NzU3ZjgwYmIxOTU0YzQyMTIxMGE4YzJfQkhLMVI2bEZGUnhpR210c1BDelZDRUI3YjJDY2Q1T3NfVG9rZW46Ym94Y250aG1UTjBXTmI2TTFqYlV1eG9MTnMwXzE2NDg2NTE4NzU6MTY0ODY1NTQ3NV9WNA!


> TaskManager hung in cleanupAllocationBaseDirs not exit.
> -------------------------------------------------------
>
>                 Key: FLINK-26932
>                 URL: https://issues.apache.org/jira/browse/FLINK-26932
>             Project: Flink
>          Issue Type: Bug
>          Components: Runtime / Coordination
>            Reporter: huweihua
>            Priority: Major
>         Attachments: origin_img_v2_bb063beb-2f44-40fe-b1d2-4cc8dc87585g.png
>
>
> The disk TaskManager used had some fatal error. And then TaskManager hung in 
> cleanupAllocationBaseDirs and took the main thread.
>  
> So this TaskManager would not respond to the 
> cancelTask/disconnectResourceManager request.
>  
> At the same time, JobMaster already take this TaskManager is lost, and 
> schedule task to other TaskManager.
>  
> This may cause some unexpected task running.
>  
> After checking the log of TaskManager, TM already lost the connection with 
> ResourceManager, and it is always trying to register with ResourceManager. 
> The RegistrationTimeout cannot take effect because the main thread of 
> TaskManager is hung-up.
>  
> I think there are two options to handle it.
> Option 1: Add timeout for 
> TaskExecutorLocalStateStoreManager.cleanupAllocationBaseDirs, But I am afraid 
> some other methods would block main thread too.
> Option 2: Move the registrationTimeout in another thread, we need to deal 
> will the concurrency problem
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Reply via email to