[ 
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)

Reply via email to