apache/hadoop · warning · UnsupportedOperationException

Operation "{}" is not supported

Error message

Operation "{}" is not supported

What it means

RouterClientProtocol.upgradeStatus() throws UnsupportedOperationException naming the intercepted method. The Router implements most ClientProtocol methods by proxying, but upgradeStatus is in the UNSUPPORTED set: router-side upgrade status has no federated semantics (each nameserver upgrades independently), so the Router refuses it explicitly. finalizeUpgrade, by contrast, fans out to all namespaces.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs-rbf/src/main/java/org/apache/hadoop/hdfs/server/federation/router/RouterClientProtocol.java:1259

    RemoteMethod method = new RemoteMethod("refreshNodes", new Class<?>[] {});
    final Set<FederationNamespaceInfo> nss = namenodeResolver.getNamespaces();
    rpcClient.invokeConcurrent(nss, method, true, true);
  }

  @Override
  public void finalizeUpgrade() throws IOException {
    rpcServer.checkOperation(NameNode.OperationCategory.UNCHECKED);

    RemoteMethod method = new RemoteMethod("finalizeUpgrade",
        new Class<?>[] {});
    final Set<FederationNamespaceInfo> nss = namenodeResolver.getNamespaces();
    rpcClient.invokeConcurrent(nss, method, true, false);
  }

  @Override
  public boolean upgradeStatus() throws IOException {
    String methodName = RouterRpcServer.getMethodName();
    throw new UnsupportedOperationException(
        "Operation \"" + methodName + "\" is not supported");
  }

  @Override
  public RollingUpgradeInfo rollingUpgrade(HdfsConstants.RollingUpgradeAction action)
      throws IOException {
    rpcServer.checkOperation(NameNode.OperationCategory.READ);

    RemoteMethod method = new RemoteMethod("rollingUpgrade",
        new Class<?>[] {HdfsConstants.RollingUpgradeAction.class}, action);
    final Set<FederationNamespaceInfo> nss = namenodeResolver.getNamespaces();
    Map<FederationNamespaceInfo, RollingUpgradeInfo> ret =
        rpcClient.invokeConcurrent(
            nss, method, true, false, RollingUpgradeInfo.class);

    // Return the first rolling upgrade info
    RollingUpgradeInfo info = null;
    for (RollingUpgradeInfo infoNs : ret.values()) {

View on GitHub (pinned to 2add963021)

Solutions

  1. Target upgradeStatus at each underlying NameNode, not the Router
  2. Remove/guard the upgradeStatus call in scripts that talk to RBF endpoints
  3. Use the Router's supported admin surface (e.g. finalizeUpgrade fans out; rollingUpgrade proxies) instead

Example fix

# before: fails against Router
hdfs dfsadmin -fs hdfs://router -upgradeStatus   # conceptually

# after: query each subcluster NameNode
hdfs dfsadmin -fs hdfs://ns1 -upgradeStatus
Defensive patterns

Strategy: try-catch

Validate before calling

// Route upgrade status queries to NameNodes, not the Router
if (uriPointsAtRouter(conf)) {
  throw new UnsupportedOperationException("upgradeStatus unsupported via Router; query each NameNode");
}

Try / catch

try {
  clientProtocol.upgradeStatus();
} catch (UnsupportedOperationException e) {
  if (e.getMessage() != null && e.getMessage().contains("upgradeStatus")) {
    // expected on RBF: query each underlying NameNode for its upgrade status
  } else { throw e; }
}

Prevention

When it happens

Trigger: A management client or HA tooling invoking upgradeStatus through the Router's client RPC port; scripts mixing NameNode admin RPCs against an RBF endpoint; version upgrade checkers probing upgradeStatus on every endpoint they discover.

Common situations: Operators reuse NameNode health-check scripts against Router addresses; rolling-upgrade automation probing all ClientProtocol endpoints; SDKs calling upgradeStatus generically.

Related errors

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