apache/hadoop · error · IllegalArgumentException

responseTimeThreshold millis must be >= 0

Error message

responseTimeThreshold millis must be >= 0

What it means

In the same parseBackOffResponseTimeThreshold loop, every per-level backoff threshold must be a positive duration; a value of 0ms or negative (which the misleading message calls 'must be >= 0' while the code requires > 0) throws IllegalArgumentException at scheduler construction. A non-positive threshold would make a queue back off before any request is even measured, so it is rejected.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/DecayRpcScheduler.java:451

  private static long[] parseBackOffResponseTimeThreshold(String ns,
      Configuration conf, int numLevels) {
    long[] responseTimeThresholds = conf.getTimeDurations(ns + "." +
            IPC_DECAYSCHEDULER_BACKOFF_RESPONSETIME_THRESHOLDS_KEY,
        TimeUnit.MILLISECONDS);
    // backoff thresholds not specified
    if (responseTimeThresholds.length == 0) {
      return getDefaultBackOffResponseTimeThresholds(numLevels);
    }
    // backoff thresholds specified but not match with the levels
    if (responseTimeThresholds.length != numLevels) {
      throw new IllegalArgumentException(
          "responseTimeThresholds must match with the number of priority " +
          "levels");
    }
    // invalid thresholds
    for (long responseTimeThreshold: responseTimeThresholds) {
      if (responseTimeThreshold <= 0) {
        throw new IllegalArgumentException(
            "responseTimeThreshold millis must be >= 0");
      }
    }
    return responseTimeThresholds;
  }

  // 10s for level 0, 20s for level 1, 30s for level 2, ...
  private static long[] getDefaultBackOffResponseTimeThresholds(int numLevels) {
    long[] ret = new long[numLevels];
    for (int i = 0; i < ret.length; i++) {
      ret[i] = 10000*(i+1);
    }
    return ret;
  }

  private static Boolean parseBackOffByResponseTimeEnabled(String ns,
      Configuration conf) {
    return conf.getBoolean(ns + "." +

View on GitHub (pinned to 2add963021)

Solutions

  1. Replace zero/negative entries with small positive durations (e.g., 1ms or 1s).
  2. If level 0 should back off earliest, give it the smallest positive value while keeping ascending order semantics you want.
  3. Remove the thresholds property to use defaults (10s,20s,30s,...).

Example fix

// before (core-site.xml)
<property><name>ipc.8020.decay-scheduler.backoff.responsetime.thresholds</name><value>0s,10s,20s</value></property>
<!-- 0s entry -> IllegalArgumentException: responseTimeThreshold millis must be >= 0 -->

// after
<property><name>ipc.8020.decay-scheduler.backoff.responsetime.thresholds</name><value>1s,10s,20s</value></property>
Defensive patterns

Strategy: validation

Validate before calling

for (long t : th) { // th from getTimeDurations of the thresholds key
  if (t <= 0) throw new ConfigException("backoff thresholds must each be > 0, got " + t);
}

Prevention

When it happens

Trigger: Including a 0 (e.g., '0s,10s,20s' to make level 0 back off immediately) in decay-scheduler.backoff.responsetime.thresholds; a negative value; a malformed duration that parses to 0.

Common situations: Attempting to disable backoff for the lowest-priority queue by zeroing its threshold; hand-edited XML with placeholder zeros left in.

Understand the failure class

Background: Config validation failed: what "invalid value for {key}" and settings-rejection errors mean across 19 open-source libraries — this error's family across 19 libraries.

Related errors


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