[
https://issues.apache.org/jira/browse/AMBARI-12138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14622578#comment-14622578
]
Matt Foley commented on AMBARI-12138:
-------------------------------------
This jira overlaps with AMBARI-11192 - The Default hdfs-site.xml Should Have
Client Retry Logic Enabled For Rolling Upgrade.
Different reason, same intended change.
However, that patch was implemented, then reverted for the reasons given here:
https://issues.apache.org/jira/browse/AMBARI-11192?focusedCommentId=14615924&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14615924
It turns out that the stuff that happens under the covers when
dfs.client.retry.policy.enabled is set to true in an HA environment, have a bad
side effect: If a primary NN is killed "dirty", then clients attempting to
connect to it have a 10 minute delay before switching over to the new NN. So
the underlying mechanisms need to be fixed before
dfs.client.retry.policy.enabled can be safely set to true for HA clusters.
In the meantime, HA seems to work as expected even with
dfs.client.retry.policy.enabled set to false.
> Set dfs.client.retry.policy.enabled property to true when HDFS HA is enabled
> ----------------------------------------------------------------------------
>
> Key: AMBARI-12138
> URL: https://issues.apache.org/jira/browse/AMBARI-12138
> Project: Ambari
> Issue Type: Improvement
> Components: ambari-web
> Affects Versions: 2.1.0
> Reporter: sam liu
> Attachments: AMBARI-12138.patch
>
>
> After enabling HDFS HA, hdfs-site.xml does not include property
> dfs.client.retry.policy.enabled and 'hdfs getconf -confKey
> dfs.client.retry.policy.enabled' returns empty value.
> The property dfs.client.retry.policy.enabled is important when HA is enabled,
> as it enables HDFS client retry in case of NameNode failure. So, after
> enabling HDFS HA, Ambari should set this property to true in hdfs-site.xml.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
