apache/hadoop · error · IOException

Invalid value in server response: name=[${name}]

Error message

Invalid value in server response: name=[${name}]

What it means

When JsonUtilClient.toDatanodeInfo decodes a DataNode entry, it normally reads ipAddr and xferPort. For compatibility with old 1.x/0.23.x servers it can instead parse the legacy name field in host:port form. This IOException means name was present but had no colon at an index greater than zero, so no transfer address can be derived.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs-client/src/main/java/org/apache/hadoop/hdfs/web/JsonUtilClient.java:333

      return null;
    }

    // ipAddr and xferPort are the critical fields for accessing data.
    // If any one of the two is missing, an exception needs to be thrown.

    // Handle the case of old servers (1.x, 0.23.x) sending 'name' instead
    //  of ipAddr and xferPort.
    String ipAddr = getString(m, "ipAddr", null);
    int xferPort = getInt(m, "xferPort", -1);
    if (ipAddr == null) {
      String name = getString(m, "name", null);
      if (name != null) {
        int colonIdx = name.indexOf(':');
        if (colonIdx > 0) {
          ipAddr = name.substring(0, colonIdx);
          xferPort = Integer.parseInt(name.substring(colonIdx +1));
        } else {
          throw new IOException(
              "Invalid value in server response: name=[" + name + "]");
        }
      } else {
        throw new IOException(
            "Missing both 'ipAddr' and 'name' in server response.");
      }
      // ipAddr is non-null & non-empty string at this point.
    }

    // Check the validity of xferPort.
    if (xferPort == -1) {
      throw new IOException(
          "Invalid or missing 'xferPort' in server response.");
    }

    // TODO: Fix storageID
    return new DatanodeInfoBuilder().setIpAddr(ipAddr)
        .setHostName((String) m.get("hostName"))

View on GitHub (pinned to 2add963021)

Solutions

  1. Point the client at a WebHDFS endpoint served by a Hadoop 2.x or later NameNode that emits ipAddr and xferPort.
  2. Remove or fix a proxy/gateway that rewrites datanode location JSON, and verify it passes the NameNode response unchanged.
  3. If the legacy server must remain, use a client version compatible with its response format or upgrade the server.
  4. Inspect the raw GETFILEBLOCKLOCATIONS or open response and confirm each datanode object has ipAddr plus xferPort, or legacy name exactly host:port.

Example fix

// before: response contains {"name": "dn1"}
FileSystem fs = FileSystem.get(new URI("webhdfs://old-or-custom-gateway:9870"), conf);
FSDataInputStream in = fs.open(path);

// after: endpoint returns {"ipAddr": "10.0.0.5", "xferPort": 9866}
FileSystem fs = FileSystem.get(new URI("webhdfs://nn-hadoop2:9870"), conf);
FSDataInputStream in = fs.open(path);
Defensive patterns

Strategy: try-catch

Try / catch

try {
  return fs.open(path);
} catch (IOException e) {
  if (e.getMessage() != null && e.getMessage().startsWith("Invalid value in server response")) {
    throw new IllegalStateException("WebHDFS endpoint returned a datanode name without host:port; check server/proxy compatibility", e);
  }
  throw e;
}

Prevention

When it happens

Trigger: A WebHDFS response containing block locations or DataNode status has a datanode object without ipAddr and with a name such as "datanode-host" or ":9866". The parser therefore cannot split a host and xferPort. This can occur when a current client talks to a very old or nonstandard WebHDFS-compatible endpoint, or when a proxy rewrites datanode JSON.

Common situations: Mixing an old Hadoop 1.x/0.23.x server with a newer client; routing WebHDFS through a gateway that returns its own DataNode representation; a downstream service that manually constructs HDFS-like JSON; version drift in a test fixture.

Related errors

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