[
https://issues.apache.org/jira/browse/YARN-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13850689#comment-13850689
]
Karthik Kambatla commented on YARN-1028:
----------------------------------------
bq. TestRMFailOver.verifyClientConnection: Shouldn't have a tight loop?
Sorry, I am not sure I understand. Mind spelling it out for me?
bq. You don't need the createRMProxy() method in ClientRMProxy & ServerRMProxy
at all if you make the one in RMProxy public.
INSTANCE is created in the static initializer of ClientRMProxy and
ServerRMProxy. To make sure the initializer is invoked, we need those methods.
bq. If we have a common impl of createRMFailoverProxyProvider in RMProxy then
we probably dont need to do INSTANCE.createRMFailoverProxyProvider right?
createRMFailoverProxyProvider is not a static method, it needs the INSTANCE for
getting the RM address.
bq. Configuration: Trying to simplify things here. Keeping it consistent with
HDFS is making things harder for YARN given we already have some configs that
are released. So I propose that we try to reuse existing configs or deprecate
them in favor of new configs.
bq. I am in favor of getting rid of the waitForever / failoverForever. They are
extra headaches in the configuration and in practice we never want to
wait/failover forever. forever can be approximated to multiple hours/days using
appropriate settings for the retry/failover timeouts.
We might be going around in circles here, and probably rightly so. My initial
patch didn't introduce any of the HDFS kind configs. On Tom's suggestion, I
introduced them. After deploying a cluster and using it, I find the
client.failover-* configs easier to reason about as a user. I do understand the
concern of too many configs and the user having to track which one applies
when. Deprecating the old ones altogether isn't compatible either. I think the
current patch is a happy medium. Is it okay if we revisit this as part of
YARN-1460 - let me re-purpose that JIRA and make it a blocker for 2.4.
> Add FailoverProxyProvider like capability to RMProxy
> ----------------------------------------------------
>
> Key: YARN-1028
> URL: https://issues.apache.org/jira/browse/YARN-1028
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Bikas Saha
> Assignee: Karthik Kambatla
> Attachments: yarn-1028-1.patch, yarn-1028-10.patch,
> yarn-1028-2.patch, yarn-1028-3.patch, yarn-1028-4.patch, yarn-1028-5.patch,
> yarn-1028-6.patch, yarn-1028-7.patch, yarn-1028-8.patch, yarn-1028-9.patch,
> yarn-1028-draft-cumulative.patch
>
>
> RMProxy layer currently abstracts RM discovery and implements it by looking
> up service information from configuration. Motivated by HDFS and using
> existing classes from Common, we can add failover proxy providers that may
> provide RM discovery in extensible ways.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)