[
https://issues.apache.org/jira/browse/FLINK-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933879#comment-16933879
]
TisonKun commented on FLINK-4233:
---------------------------------
Thanks for picking up this topic! I'm thinking of something similar to this one
recently.
Basically it requires a new ZKLeaderRetrievalService that works like
{{PathChildrenCache}} in Curator(or we just reuse it) to monitoring leader
latch registry. In this way, retriever will automatic treat the latch with the
smallest sequential number as the leader info node and retrieve the
information. As side effects, leader needs not to "publish" its leader
information any more.
The downside would be overhead so-called {{PathChildrenCache}} costs. However,
given that there is typically 1 or 2 latch at the same time and leader
changes(after we tolerate SUSPENDED a.k.a CONNECTIONLOSS) is rare event,
hopefully it doesn't impact too much.
> Simplify leader election / leader session ID assignment
> -------------------------------------------------------
>
> Key: FLINK-4233
> URL: https://issues.apache.org/jira/browse/FLINK-4233
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / Coordination
> Affects Versions: 1.0.3
> Reporter: Stephan Ewen
> Priority: Major
>
> Currently, there are two separate actions and znodes involved in leader
> election and communication of the leader session ID and leader URL.
> This leads to some quite elaborate code that tries to make sure that the
> leader session ID and leader URL always eventually converge to those of the
> leader.
> It is simpler to just encode both the ID and the URL into an id-string that
> is attached to the leader latch znode. One would have to create a new leader
> latch each time a contender re-applies for leadership.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
