apache/druid · error · ISE
Failed to get locks for intervals[%s]
Error message
Failed to get locks for intervals[%s]
What it means
IndexTask.runTask, when intervals are being determined at run time (determineIntervals), attempts determineLockGranularityAndTryLock for the allocateIntervals and aborts with this ISE if the task could not obtain the necessary segment locks. Without locks the task cannot safely write segments for those intervals, so it fails immediately.
Source
Thrown at indexing-service/src/main/java/org/apache/druid/indexing/common/task/IndexTask.java:488
// Initialize maxRowsPerSegment and maxTotalRows lazily
final IndexTuningConfig tuningConfig = ingestionSchema.tuningConfig;
final PartitionsSpec partitionsSpec = tuningConfig.getGivenOrDefaultPartitionsSpec();
final PartitionAnalysis partitionAnalysis = determineShardSpecs(
toolbox,
inputSource,
tmpDir,
partitionsSpec
);
final List<Interval> allocateIntervals = new ArrayList<>(partitionAnalysis.getAllIntervalsToIndex());
final DataSchema dataSchema;
if (determineIntervals) {
final boolean gotLocks = determineLockGranularityAndTryLock(
toolbox.getTaskActionClient(),
allocateIntervals
);
if (!gotLocks) {
throw new ISE("Failed to get locks for intervals[%s]", allocateIntervals);
}
dataSchema = ingestionSchema.getDataSchema().withGranularitySpec(
ingestionSchema.getDataSchema()
.getGranularitySpec()
.withIntervals(JodaUtils.condenseIntervals(allocateIntervals))
);
} else {
dataSchema = ingestionSchema.getDataSchema();
}
ingestionState = IngestionState.BUILD_SEGMENTS;
return generateAndPublishSegments(
toolbox,
dataSchema,
inputSource,
tmpDir,
partitionAnalysisView on GitHub (pinned to 9b90983fd2)
Solutions
- Wait for the conflicting task to complete and release locks, then retry the index task
- Cancel or kill the overlapping task holding the locks (GET /druid/indexer/v1/task then POST shutdown)
- Increase the task's context "taskLockType"/priority or use exclusive/time-chunk locks as appropriate
- Stagger interval allocation so concurrent tasks do not allocate the same intervals
Example fix
// before
"context": { "taskLockType": "append" } // overlapping with a running task
// after
// first shut down the conflicting task, then submit:
"context": { "taskLockType": "replace" } Defensive patterns
Strategy: try-catch
Validate before calling
Set<Interval> locked = overlord.getLockedIntervals();
if (locked.stream().anyMatch(l -> l.overlaps(allocateIntervals))) {
waitOrAbort(); // don't submit task that will fail to acquire locks
} Try / catch
try {
runIndexTask(spec);
} catch (IllegalStateException e) {
if (e.getMessage().startsWith("Failed to get locks for intervals")) {
// back off and retry after conflicting task finishes
Thread.sleep(backoffMillis);
runIndexTask(spec);
} else throw e;
} Prevention
- Don't run overlapping batch tasks for the same intervals
- Check active locks via /druid/indexer/v1/lockingEndpoint before submitting
- Coordinate with supervisors holding stream locks
- Use task priority/context to control lock acquisition
When it happens
Trigger: Running an index task with appendToExisting/interval allocation while another task holds an overlapping time chunk lock, or segment allocation is configured such that intervals must be locked at run time and a competing task (e.g., a running supervisor's stream task or another batch task) already holds them.
Common situations: Overlapping batch tasks submitted for the same intervals; a Kafka/Kinesis supervisor holding locks for the same period; re-running a failed task while its locks were not yet released; lock priority too low to preempt the holder.
Understand the failure class
Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.
Related errors
- Attempt to add row to swapped-out sink for segment[%s].
- ColumnCapacityExceededException
- Could not create group mapping [%s] due to concurrent update
- Could not delete group mapping [%s] due to concurrent update
- Could not create role [%s] due to concurrent update contenti
AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07).
Data as JSON: /api/errors/2c782786bbf3fcab.
Report an issue: GitHub.