[
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
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
> 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
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
