What causes "Option value {} for {} is found. It should be an integer" in apache/hadoop?

Use plain integer strings ("6", "3") for both unit-count keys

apache/hadoop · error · IllegalArgumentException

Option value {} for {} is found. It should be an integer

Error message

Option value {} for {} is found. It should be an integer

What it means

ECSchema.extractIntOption wraps Integer.parseInt; when a "numDataUnits" or "numParityUnits" value is not a parseable integer (fractional string, letters, empty, embedded whitespace) a NumberFormatException is converted into this IllegalArgumentException naming the offending value and key. The schema never gets built because the counts cannot be interpreted.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/io/erasurecode/ECSchema.java:142

    }

    // After some cleanup
    this.extraOptions = Collections.unmodifiableMap(extraOptions);
  }

  private int extractIntOption(String optionKey, Map<String, String> options) {
    int result = -1;

    try {
      if (options.containsKey(optionKey)) {
        result = Integer.parseInt(options.get(optionKey));
        if (result <= 0) {
          throw new IllegalArgumentException("Bad option value " + result +
              " found for " + optionKey);
        }
      }
    } catch (NumberFormatException e) {
      throw new IllegalArgumentException("Option value " +
          options.get(optionKey) + " for " + optionKey +
          " is found. It should be an integer");
    }

    return result;
  }

  /**
   * Get the codec name
   * @return codec name
   */
  public String getCodecName() {
    return codecName;
  }

  /**
   * Get extra options specific to an erasure code.
   * @return extra options

View on GitHub (pinned to 2add963021)

Solutions

Use plain integer strings ("6", "3") for both unit-count keys
Trim values and reject/fix fractional formats before constructing the schema
Pre-validate with Integer.parseInt in your own code to fail with a clearer message pointing at the source field

Example fix

// before
opts.put("numDataUnits", "6.0"); // float string
new ECSchema(opts); // throws: It should be an integer

// after
opts.put("numDataUnits", Integer.toString(6));

Defensive patterns

Strategy: validation

Validate before calling

for (String k : new String[]{"numDataUnits", "numParityUnits"}) {
  String v = allOptions.get(k);
  if (v != null) {
    Integer.parseInt(v.trim()); // throws early with your own context
  }
}
new ECSchema(allOptions);

Try / catch

try {
  new ECSchema(allOptions);
} catch (IllegalArgumentException e) {
  Throwable cause = e; // NumberFormatException context is embedded in message
  throw new IllegalArgumentException("Non-integer EC schema option: "
      + allOptions, e);
}

Prevention

Emit integers with Integer.toString when generating policy files; never serialize floats for unit counts
Trim whitespace from values parsed from pretty-printed XML
Reject values matching non-digit patterns at config load time

When it happens

Trigger: new ECSchema(map) with values like "6.0", "3.5", "six", "" or " 6"; JSON/XML numbers serialized as floats or with locale-specific formatting; empty <numDataUnits></numDataUnits> elements.

Common situations: Schema options round-tripped through systems that reformat numbers (floats, thousands separators); hand-edited policy files; whitespace introduced by pretty-printed XML.

Related errors

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