apache/hadoop · error · ReconfigurationException

Could not change property {property} from '{oldVal}' to '{ne

Error message

Could not change property {property} from '{oldVal}' to '{newVal}'

What it means

NameNode.reconfigurePropertyImpl chains property.equals() checks over every runtime-reconfigurable key; the final else throws ReconfigurationException(property, newVal, getConf().get(property)), reporting the old effective value and the rejected new value. It fires when a property reached this dispatcher but matched no handler branch. That means the key as sent does not match what this NameNode build handles - a spelling or version-skew problem, not a bad value (bad values fail earlier, inside each handler).

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNode.java:2398

    } else if (property.equals(DFS_BLOCK_INVALIDATE_LIMIT_KEY)) {
      return reconfigureBlockInvalidateLimit(datanodeManager, property, newVal);
    } else if (property.equals(DFS_NAMENODE_DECOMMISSION_BACKOFF_MONITOR_PENDING_LIMIT) ||
        (property.equals(DFS_NAMENODE_DECOMMISSION_BACKOFF_MONITOR_PENDING_BLOCKS_PER_LOCK))) {
      return reconfigureDecommissionBackoffMonitorParameters(datanodeManager, property,
          newVal);
    } else if (property.equals(DFS_NAMENODE_BLOCKPLACEMENTPOLICY_MIN_BLOCKS_FOR_WRITE_KEY)) {
      return reconfigureMinBlocksForWrite(property, newVal);
    } else if (property.equals(IPC_SERVER_LOG_SLOW_RPC) ||
        (property.equals(IPC_SERVER_LOG_SLOW_RPC_THRESHOLD_MS_KEY))) {
      return reconfigureLogSlowRPC(property, newVal);
    } else if (property.equals(DFS_NAMENODE_LOCK_DETAILED_METRICS_KEY)
        || property.equals(DFS_NAMENODE_READ_LOCK_REPORTING_THRESHOLD_MS_KEY)
        || property.equals(DFS_NAMENODE_WRITE_LOCK_REPORTING_THRESHOLD_MS_KEY)) {
      return reconfigureFSNamesystemLockMetricsParameters(property, newVal);
    } else if (property.equals(DFS_NAMENODE_MAX_DIRECTORY_ITEMS_KEY)) {
      return reconfigureMaxDirItems(newVal);
    } else {
      throw new ReconfigurationException(property, newVal, getConf().get(
          property));
    }
  }

  private String reconfReplicationParameters(final String newVal,
      final String property) throws ReconfigurationException {
    BlockManager bm = namesystem.getBlockManager();
    int newSetting;
    namesystem.writeLock(RwLockMode.BM);
    try {
      if (property.equals(DFS_NAMENODE_REPLICATION_MAX_STREAMS_KEY)) {
        bm.setMaxReplicationStreams(
            adjustNewVal(DFS_NAMENODE_REPLICATION_MAX_STREAMS_DEFAULT, newVal));
        newSetting = bm.getMaxReplicationStreams();
      } else if (property.equals(
          DFS_NAMENODE_REPLICATION_STREAMS_HARD_LIMIT_KEY)) {
        bm.setReplicationStreamsHardLimit(
            adjustNewVal(DFS_NAMENODE_REPLICATION_STREAMS_HARD_LIMIT_DEFAULT,

View on GitHub (pinned to 2add963021)

Solutions

1. Run `hdfs dfsadmin -reconfig namenode <addr> -properties` and copy the key name exactly from the supported list
2. Verify the key exists in the documentation for the exact deployed version (`hadoop version`)
3. If the key is not runtime-reconfigurable on this build, set it in hdfs-site.xml and restart the NameNode
4. During rolling upgrades, finish the upgrade so client and NameNode versions match before reconfiguring newly added keys

Example fix

# before - typo'd key falls through to the else branch
hdfs dfsadmin -reconfig namenode nn1:8020 -set dfs.namenode.heartbeat.recheck=300000

# after - exact key from `dfsadmin -reconfig ... -properties`
hdfs dfsadmin -reconfig namenode nn1:8020 -set dfs.namenode.heartbeat.recheck-interval=300000

# Only reconfig keys the NN itself declares
KEY=dfs.namenode.heartbeat.recheck-interval
if ! hdfs dfsadmin -reconfig namenode nn1:8020 -properties | grep -qx "$KEY"; then
  echo "$KEY not runtime-reconfigurable on this NN"; exit 1
fi
hdfs dfsadmin -reconfig namenode nn1:8020 -set "$KEY=300000"

// Java: gate keys against the server's own declared list before calling
boolean reconfigurable = supportedProperties.contains(key);

catch (ReconfigurationException e) {
  log.warn("NN rejected reconfig of {} from [{}] to [{}]: {}",
      e.getProperty(), e.getOldValue(), e.getNewValue(), e.getCause());
  // fall back to: set in hdfs-site.xml + rolling restart of the NameNode
}

When it happens

Trigger: `hdfs dfsadmin -reconfig namenode <addr> -set <key>=<value>` where <key> is misspelled or is a reconfigurable key of a different Hadoop version than the running NameNode; also a programmatic ReconfigurableBase.reconfigureProperty call with an unsupported key.

Common situations: Typos in the property name in ops scripts; using a key added in a newer release against an older NameNode; mixed-version clusters mid rolling upgrade where the client's key list is newer than the NN's.

Related errors

• For enabling or disabling storage policy satisfier, must pas
• Could not change property {} from '{}' to '{}'
• {} is not boolean value
• The journal edits cache is not enabled, which is a requireme
• DISK_BALANCER_NOT_ENABLED

AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/cd7a2c677a092fcd. Report an issue: GitHub.