[
https://issues.apache.org/jira/browse/YARN-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14542105#comment-14542105
]
Allen Wittenauer commented on YARN-3639:
----------------------------------------
bq. on the same node
I don't see what that has to do with:
bq. After analysis, we found the root cause is renewing HDFS tokens in the
recovering process. The HDFS client created by the renewer would firstly try to
connect to the original namenode, the result of which is time-out after 10~20s,
and then the client tries to connect to the new namenode. The entire recovery
cost 15*#apps seconds according our test.
What happens if the two NNs aren't on the same node as the RM? Does the
problem still exist?
(It should also be noted that running the NN and RM on the same node for other
than trivial deployments has never been a recommended configuration.)
> It takes too long time for RM to recover all apps if the original active RM
> and namenode is deployed on the same node.
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: YARN-3639
> URL: https://issues.apache.org/jira/browse/YARN-3639
> Project: Hadoop YARN
> Issue Type: Bug
> Components: resourcemanager
> Reporter: Xianyin Xin
>
> If the node on which the active RM runs dies and if the active namenode is
> running on the same node, the new RM will take long time to recover all apps.
> After analysis, we found the root cause is renewing HDFS tokens in the
> recovering process. The HDFS client created by the renewer would firstly try
> to connect to the original namenode, the result of which is time-out after
> 10~20s, and then the client tries to connect to the new namenode. The entire
> recovery cost 15*#apps seconds according our test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
