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
- Replace zero/negative entries with small positive durations (e.g., 1ms or 1s).
- If level 0 should back off earliest, give it the smallest positive value while keeping ascending order semantics you want.
- 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
- All backoff thresholds must be strictly positive (message says >= 0 but 0 is rejected).
- Avoid placeholder zeros in config templates.
- Prefer omitting the key to use 10s/20s/30s defaults when unsure.
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
- responseTimeThresholds must match with the number of priorit
- Number of thresholds should be {}. Was: {}
- Number of Priority Levels must be at least 1
- Decay Factor must be between 0 and 1
- Period millis must be >= 0
AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22).
Data as JSON: /api/errors/0f6f10ab7ac88edb.
Report an issue: GitHub.