[
https://issues.apache.org/jira/browse/YARN-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15426700#comment-15426700
]
Daniel Templeton commented on YARN-5445:
----------------------------------------
Moving {{DFS_CLIENT_FAILOVER_MAX_ATTEMPTS_KEY}} to {{CommonConfigurationKeys}}
doesn't sound like the right solution. If the log aggregation code is going to
depend on specific behavior of HDFS why shouldn't the project depend on
hadoop-hdfs?
As you pointed out, there are other JIRAs that are attempting to resolve the
base issue that is prompting your unusual cluster config. I don't think
introducing a new configuration parameter to deal with a temporary issue is a
good idea. Config params, like diamonds, are forever, and we already have
entirely too many.
I haven't looked at the code for log aggregation. What happens what the DFS
connection fails?
> Log aggregation configured to different namenode can fail fast
> --------------------------------------------------------------
>
> Key: YARN-5445
> URL: https://issues.apache.org/jira/browse/YARN-5445
> Project: Hadoop YARN
> Issue Type: Bug
> Components: nodemanager
> Affects Versions: 2.7.1
> Reporter: Chackaravarthy
> Attachments: YARN-5445-1.patch
>
>
> Log aggregation is enabled and configured to write applogs to different
> cluster or different namespace (NN federation). In these cases, would like to
> have some configs on attempts or retries to fail fast in case the other
> cluster is completely down.
> Currently it takes default {{dfs.client.failover.max.attempts}} as 15 and
> hence adding a latency of 2 to 2.5 mins in each container launch (per node
> manager).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
