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,
          partitionAnalysis

View on GitHub (pinned to 9b90983fd2)

Solutions

  1. Wait for the conflicting task to complete and release locks, then retry the index task
  2. Cancel or kill the overlapping task holding the locks (GET /druid/indexer/v1/task then POST shutdown)
  3. Increase the task's context "taskLockType"/priority or use exclusive/time-chunk locks as appropriate
  4. 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

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


AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07). Data as JSON: /api/errors/2c782786bbf3fcab. Report an issue: GitHub.