apache/iceberg · warning

Failed to acquire Zookeeper lock

Error message

Failed to acquire Zookeeper lock

What it means

ZkLockFactory.tryLock catches any Exception while attempting to acquire the ZooKeeper shared lock, logs this warning, and returns false instead of propagating. Callers see a failed lock acquisition (a retry is expected) rather than a thrown error.

Source

Thrown at flink/v2.3/flink/src/main/java/org/apache/iceberg/flink/maintenance/api/ZkLockFactory.java:218

    }

    @Override
    public boolean tryLock() {
      VersionedValue<Integer> versionedValue = sharedCount.getVersionedValue();
      if (isHeld(versionedValue)) {
        LOG.debug("Lock is already held for path: {}", lockPath);
        return false;
      }

      try {
        boolean acquired = sharedCount.trySetCount(versionedValue, LOCKED);
        if (!acquired) {
          LOG.debug("Failed to acquire lock for path: {}", lockPath);
        }

        return acquired;
      } catch (Exception e) {
        LOG.warn("Failed to acquire Zookeeper lock", e);
        return false;
      }
    }

    @Override
    public boolean isHeld() {
      return isHeld(sharedCount.getVersionedValue());
    }

    private static boolean isHeld(VersionedValue<Integer> versionedValue) {
      try {
        return versionedValue.getValue() == LOCKED;
      } catch (Exception e) {
        throw new RuntimeException("Failed to check Zookeeper lock status", e);
      }
    }

    @Override

View on GitHub (pinned to 86d9c8fc54)

Solutions

  1. Inspect the logged stack trace for the underlying KeeperException (ConnectionLoss, SessionExpired, NoAuth)
  2. Verify ZooKeeper connectivity, quorum health, and session timeouts
  3. Check zNode ACLs/permissions for the configured lock path
  4. Retry — tryLock returns false and the maintenance trigger will be attempted again
Defensive patterns

Strategy: retry

Validate before calling

// check ZK connectivity ahead of triggering maintenance
 curator.checkExists().forPath(lockPath);

Try / catch

boolean acquired = lockFactory.tryLock();
if (!acquired) { /* schedule retry on next trigger */ }

Prevention

When it happens

Trigger: Exception thrown by the Curator SharedCount/InterProcessMutex operations inside tryLock — e.g. connection loss, session expiry, or KeeperException while setting the count on lockPath.

Common situations: ZooKeeper ensemble unreachable or flapping; session timeouts under load; wrong lock path or insufficient zNode permissions; maintenance coordinator triggering table maintenance while the ZK quorum is degraded.

Related errors


AI-assisted analysis of apache/iceberg@86d9c8fc54 (2026-09-12). Data as JSON: /api/errors/a04952a84db49d85. Report an issue: GitHub.