[
https://issues.apache.org/jira/browse/HDFS-14560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861206#comment-16861206
]
Íñigo Goiri commented on HDFS-14560:
------------------------------------
Thanks [~sodonnell] for the patch.
A few minor comments:
* I would use LambdaTestUtils#intercept for verifying the exceptions.
* I would verify that the initial values in
{{TestRefreshNamenodeReplicationConfig}} (at least in
{{testParamsCanBeReconfigured}}).
* I am not sure there is a point on capturing ReconfigurationException and then
fail in {{testParamsCanBeReconfigured()}}, just letting it go should be enough.
* We can use {{for (String key : keys)}} in a couple of the cases where we use
indices.
* Let's use Logger style logs with {}.
* It is a little inconsistent the order of the parameters in
{{reconfigureSPSModeEvent}} and {{reconfReplicationParameters}}.
* Expand the imports in {{TestRefreshNamenodeReplicationConfig}}.
* Do we need 1 DN for the mini cluster? I would like to minimize the time for
this test.
* Looks like getReplicationStreamsHardLimit() and getBlocksReplWorkMultiplier()
are there just for the tests. What about reducing the visibility and marking it
as VisibleForTesting?
* The preconditions seem pretty repetitive. I think this could be set as a
common pattern somewhere but at least here.
> Allow block replication parameters to be refreshable
> ----------------------------------------------------
>
> Key: HDFS-14560
> URL: https://issues.apache.org/jira/browse/HDFS-14560
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: namenode
> Affects Versions: 3.3.0
> Reporter: Stephen O'Donnell
> Assignee: Stephen O'Donnell
> Priority: Major
> Attachments: HDFS-14560.001.patch, HDFS-14560.002.patch
>
>
> There are 3 key parameters that control the speed of block replication across
> the cluster:
> {code}
> dfs.namenode.replication.max-streams
> dfs.namenode.replication.max-streams-hard-limit
> dfs.namenode.replication.work.multiplier.per.iteration
> {code}
> These are used when decomissioning nodes and when under replicated blocks are
> being recovered across the cluster. There are times when it may be desirable
> to increase the speed of replication and then reduce it again (eg during off
> peak hours) without restarting the namenode.
> Therefore it would be good to be able to reconfigure / refresh these
> parameters dynamically without a namenode restart.
> This Jira is to allow these parameters to be refreshed at runtime without a
> restart.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
