[ 
https://issues.apache.org/jira/browse/FLINK-24038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17407145#comment-17407145
 ] 

Xintong Song commented on FLINK-24038:
--------------------------------------

bq. For the new options #1 Xintong Song listed, do you mean let the leader 
dispatcher do the deregistration? If it is, what will happen without leader.

Yes, I meant let the leading dispatcher to do the deregistration. According to 
[~trohrmann], the decision whether to shut down the cluster or not is currently 
made by the Dispatcher. IIUC, that means there should not be a shutdown without 
a leading dispatcher, because there won't be any dispatcher to make that 
decision without obtaining leadership.

> DispatcherResourceManagerComponent fails to deregister application if no 
> leading ResourceManager
> ------------------------------------------------------------------------------------------------
>
>                 Key: FLINK-24038
>                 URL: https://issues.apache.org/jira/browse/FLINK-24038
>             Project: Flink
>          Issue Type: Bug
>          Components: Runtime / Coordination
>    Affects Versions: 1.14.0
>            Reporter: Till Rohrmann
>            Priority: Critical
>             Fix For: 1.14.0
>
>
> With FLINK-21667 we introduced a change that can cause the 
> {{DispatcherResourceManagerComponent}} to fail when trying to stop the 
> application. The problem is that the {{DispatcherResourceManagerComponent}} 
> needs a leading {{ResourceManager}} to successfully execute the 
> stop/deregister application call. If this is not the case, then it will fail 
> fatally. In the case of multiple standby JobManager processes it can happen 
> that the leading {{ResourceManager}} runs somewhere else.
> I do see two possible solutions:
> 1. Run the leader election process for the whole JobManager process
> 2. Move the registration/deregistration of the application out of the 
> {{ResourceManager}} so that it can be executed w/o a leader



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to