apache/druid · error · IllegalStateException

The lock for interval[%s] is preempted and no longer valid

Error message

The lock for interval[%s] is preempted and no longer valid

What it means

During tryAllocate, SegmentAllocateAction acquires a time-sharing/task lock for the candidate interval and then submits the allocation. If the returned lock result is marked revoked, another (higher-priority) lock preempted it between acquisition and use, making the lock invalid; Druid throws rather than allocate under a stolen lock. Allocation must be retried by the task at a higher level.

Source

Thrown at indexing-service/src/main/java/org/apache/druid/indexing/common/actions/SegmentAllocateAction.java:353

    final LockResult lockResult = toolbox.getTaskLockbox().tryLock(
        task,
        new LockRequestForNewSegment(
            lockGranularity,
            taskLockType,
            task.getGroupId(),
            dataSource,
            tryInterval,
            partialShardSpec,
            task.getPriority(),
            sequenceName,
            previousSegmentId,
            skipSegmentLineageCheck
        )
    );

    if (lockResult.isRevoked()) {
      // We had acquired a lock but it was preempted by other locks
      throw new ISE("The lock for interval[%s] is preempted and no longer valid", tryInterval);
    }

    if (lockResult.isOk()) {
      final SegmentIdWithShardSpec identifier = lockResult.getNewSegmentId();
      if (identifier != null) {
        return identifier;
      } else {
        final String msg = StringUtils.format(
            "Could not allocate pending segment for rowInterval[%s], segmentInterval[%s].",
            rowInterval,
            tryInterval
        );
        if (logOnFail) {
          log.error(msg);
        } else {
          log.debug(msg);
        }
        return null;

View on GitHub (pinned to 9b90983fd2)

Solutions

Retry the task or the allocation step; Druid tasks usually retry automatically on this error.
Pause or reschedule the conflicting higher-priority (overwrite/compaction) task so it does not overlap the streaming task's intervals.
Increase the streaming task's lock priority or configure lock priorities so low-priority tasks are preempted cleanly and restart.
Reduce interval overlap by aligning segment granularity/partitions of competing tasks.

Defensive patterns

Strategy: retry

Validate before calling

// Cannot be pre-validated: preemption is inherently racy. Optionally check current locks before allocating:
// if (toolbox.getTaskLockbox().isRevoked(task, tryInterval)) skip/retry;

Try / catch

try { id = tryAllocate(...); } catch (ISE e) { if (e.getMessage().contains("is preempted")) { /* backoff and retry allocation; task framework retries automatically */ } else throw e; }

Prevention

Avoid running compaction/overwrite tasks concurrently with streaming ingestion over the same intervals.
Set deliberate lock priorities per task type.
Monitor task logs for revoked-lock warnings and tune priorities.
Keep allocation windows short after lock acquisition.

When it happens

Trigger: A higher-priority task (e.g. an overwrite/compaction task with a REVOKED-capable priority) took an overlapping interval lock while this task's allocation was in flight; concurrent allocation under contention on the same interval.

Common situations: Compaction or manual overwrite tasks launched while streaming ingestion is running; lock priority changes mid-run; two tasks racing for the same time chunk.

Related errors

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