[
https://issues.apache.org/jira/browse/YARN-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15709834#comment-15709834
]
Jian He commented on YARN-5709:
-------------------------------
When I had offline discussion with [~xgong], the ultimate goal is to remove the
old EmbeddedElectorService, as we saw the hadoop common's elector
implementation kept on having issues one after another in our internal stress
testing. We wanted to just replace that with curator implementation. After
all, there's no point maintaining two.
bq. I feel the code should be checking for !curatorBased instead of
isEmbeddedElector
which code is this ?
bq. The code that initializes the elector should be at the same place
irrespective of whether it is curator-based or not.
Does this mean CuratorLeaderElector initialization should be inside the
AdminService ? I don't think it needs to be the case even for the old
EmbeddedElectorService too, if you look at the implementation, there's no
dependency between the EmbeddedElectorService and AdminService at all.
> Cleanup Curator-based leader election code
> ------------------------------------------
>
> Key: YARN-5709
> URL: https://issues.apache.org/jira/browse/YARN-5709
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: resourcemanager
> Affects Versions: 2.8.0
> Reporter: Karthik Kambatla
> Assignee: Daniel Templeton
> Priority: Critical
>
> While reviewing YARN-5677 and YARN-5694, I noticed we could make the
> curator-based election code cleaner. It is nicer to get this fixed in 2.8
> before we ship it, but this can be done at a later time as well.
> # By EmbeddedElector, we meant it was running as part of the RM daemon. Since
> the Curator-based elector is also running embedded, I feel the code should be
> checking for {{!curatorBased}} instead of {{isEmbeddedElector}}
> # {{LeaderElectorService}} should probably be named
> {{CuratorBasedEmbeddedElectorService}} or some such.
> # The code that initializes the elector should be at the same place
> irrespective of whether it is curator-based or not.
> # We seem to be caching the CuratorFramework instance in RM. It makes more
> sense for it to be in RMContext. If others are okay with it, we might even be
> better of having {{RMContext#getCurator()}} method to lazily create the
> curator framework and then cache it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
