apache/iceberg · warning

Failed to acquire Zookeeper lock

Error message

Failed to acquire Zookeeper lock

What it means

ZkLockFactory's lock (used by the Flink maintenance/rewrite commit coordinator) attempts to acquire a shared-count lock on a ZooKeeper path. Any exception during acquisition (connection loss, session expired, node errors) is caught, logged with this warning, and tryLock returns false rather than throwing. The caller should treat this as 'lock not acquired' and retry later.

Source

Thrown at flink/v2.2/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. Check taskmanager logs for the accompanying stack trace to identify the ZooKeeper error (connection loss vs session expiry).
2. Verify ZooKeeper connectivity from the Flink cluster and ensure the ensemble is healthy.
3. Retry the maintenance job; tryLock is designed to fail soft and can succeed once ZK recovers.
4. Tune session/connection timeouts in the Curator client if transient expiries are frequent.

boolean acquired = false;
for (int attempt = 0; attempt < 3 && !acquired; attempt++) {
  acquired = lock.tryLock(); // returns false on ZK errors
  if (!acquired) {
    Thread.sleep(1000L * (attempt + 1));
  }
}
if (!acquired) {
  throw new IllegalStateException("Could not acquire Zookeeper lock after retries");
}

When it happens

Trigger: ZkLock.tryLock calls into Curator's SharedCount/lock APIs and catches Exception when ZooKeeper is unreachable, the session expires, or the lock path cannot be read/created.

Common situations: ZooKeeper ensemble restart or network partition during a maintenance trigger; session timeout too short for the job; ZK quorum loss.

Related errors

• Failed to release lock
• Failed to acquire Zookeeper lock
• Connection to Zookeeper timed out
• Interrupted while connecting to Zookeeper
• Failed to initialize SharedCount

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