apache/pulsar · error · ManagedLedgerException

Timeout during managed ledger delete operation

Error message

Timeout during managed ledger delete operation

What it means

ManagedLedgerImpl.delete() waits on a latch for the async deletion of all cursors and ledgers to complete. If the async delete chain does not finish within AsyncOperationTimeoutSeconds, this ManagedLedgerException is thrown. The underlying ledgers/cursors may still exist partially deleted afterwards.

Source

Thrown at managed-ledger/src/main/java/org/apache/bookkeeper/mledger/impl/ManagedLedgerImpl.java:3413

        final CountDownLatch counter = new CountDownLatch(1);
        final AtomicReference<ManagedLedgerException> exception = new AtomicReference<>();

        asyncDelete(new DeleteLedgerCallback() {
            @Override
            public void deleteLedgerComplete(Object ctx) {
                counter.countDown();
            }

            @Override
            public void deleteLedgerFailed(ManagedLedgerException e, Object ctx) {
                exception.set(e);
                counter.countDown();
            }

        }, null);

        if (!counter.await(AsyncOperationTimeoutSeconds, TimeUnit.SECONDS)) {
            throw new ManagedLedgerException("Timeout during managed ledger delete operation");
        }

        if (exception.get() != null) {
            log.error().exception(exception.get()).log("Error deleting managed ledger");
            throw exception.get();
        }
    }

    @Override
    public void asyncDelete(final DeleteLedgerCallback callback, final Object ctx) {

        // Delete the managed ledger without closing, since we are not interested in gracefully closing cursors and
        // ledgers
        setFencedForDeletion();
        cancelScheduledTasks();

        // Truncate to ensure the offloaded data is not orphaned.
        // Also ensures the BK ledgers are deleted and not just scheduled for deletion

View on GitHub (pinned to 820761864e)

Solutions

Verify BookKeeper and ZooKeeper connectivity; deletion timeouts almost always follow an infra outage
Retry delete() — it is idempotent for already-deleted components; use ManagedLedgerFactory.asyncDelete() to avoid the sync timeout path
Use the admin API (async) for topic deletion so the timeout does not surface as a hard exception
Clean up partially-deleted ledger metadata if retries keep failing (orphan ledgers consume space)

Example fix

// before
factory.delete(ledgerName); // sync, times out
// after
factory.asyncDelete(ledgerName)
       .exceptionally(ex -> { log.warn("delete failed, will retry", ex); return null; });

Defensive patterns

Strategy: retry

Validate before calling

// ensure infra reachable before delete
if (!zkConnected || !bkAvailable) { queueForLaterDelete(ledgerName); return; }

Try / catch

try {
    factory.delete(ledgerName);
} catch (ManagedLedgerException e) {
    retryWithBackoff(() -> factory.asyncDelete(ledgerName));
}

Prevention

Prefer factory.asyncDelete() over the sync delete()
Make deletion idempotent and retriable
Watch for orphan ledgers after repeated delete timeouts
Defer deletions during metadata-store incidents

When it happens

Trigger: Calling the synchronous ManagedLedger delete() when deleting individual ledgers via BookKeeper or removing cursor metadata from the metadata store takes longer than AsyncOperationTimeoutSeconds — e.g. unresponsive bookies or ZooKeeper session issues.

Common situations: Topic deletion (retention/policy cleanup) during a BookKeeper outage or ZooKeeper latency spike; deleting a topic with many ledgers on a loaded cluster; orphaned partial deletions requiring manual metadata cleanup.

Understand the failure class

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

AI-assisted analysis of apache/pulsar@820761864e (2026-09-06). Data as JSON: /api/errors/8bb74a843fef9897. Report an issue: GitHub.