flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kurt Young (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FLINK-4806) ResourceManager stop listening JobManager's leader address
Date Wed, 12 Oct 2016 01:22:20 GMT

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

Kurt Young updated FLINK-4806:
------------------------------
    Description: 
Currently in flip-6 branch, when RM receives a registration from JM, it will verify the leader
session id of JM and attach a JobManagerLeaderListener with it for monitoring the future changes.

Maybe we can simplify it a little bit. We don't monitor the leadership change of the JM, after
the verification passed when JM registered itself, we simply write down the leader id of the
registered the JM for future rpc filtering, and start heartbeat monitor with JM. 
If JM's leadership has been changed, the new JM will register itself, and RM will verify its
leadership when received registration, and RM can decide whether accept or reject the registration.
It's kind of like JM's information in RM is preempted only by new JM but not by RM itself
with leadership change listener. By doing this, we can simplify the logic inside RM and don't
have to do any error handling with leader listener. 

  was:
Currently in flip-6 branch, when RM receives a registration from JM, it will verify the leader
session id of JM and attach a JobManagerLeaderListener with it for monitoring the future changes.

Maybe we can simplify it a little bit. We don't monitor the leadership change of the JM, after
the verification passed when JM registered itself, we simply write down the leader id of the
registered the JM for future rpc filtering, and start heartbeat monitor with JM. 
If JM's leadership has been changed, the new JM will register itself, and RM will verify its
leadership when received registration, and RM can decide whether accept or reject the registration.
It's kind of like JM's information in RM is preempted only by new 


> ResourceManager stop listening JobManager's leader address
> ----------------------------------------------------------
>
>                 Key: FLINK-4806
>                 URL: https://issues.apache.org/jira/browse/FLINK-4806
>             Project: Flink
>          Issue Type: Sub-task
>          Components: Cluster Management
>            Reporter: Kurt Young
>
> Currently in flip-6 branch, when RM receives a registration from JM, it will verify the
leader session id of JM and attach a JobManagerLeaderListener with it for monitoring the future
changes. 
> Maybe we can simplify it a little bit. We don't monitor the leadership change of the
JM, after the verification passed when JM registered itself, we simply write down the leader
id of the registered the JM for future rpc filtering, and start heartbeat monitor with JM.

> If JM's leadership has been changed, the new JM will register itself, and RM will verify
its leadership when received registration, and RM can decide whether accept or reject the
registration. It's kind of like JM's information in RM is preempted only by new JM but not
by RM itself with leadership change listener. By doing this, we can simplify the logic inside
RM and don't have to do any error handling with leader listener. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message