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);
}
}
@OverrideView on GitHub (pinned to 86d9c8fc54)
Solutions
- Inspect the logged stack trace for the underlying KeeperException (ConnectionLoss, SessionExpired, NoAuth)
- Verify ZooKeeper connectivity, quorum health, and session timeouts
- Check zNode ACLs/permissions for the configured lock path
- 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
- Ensure the ZooKeeper ensemble is healthy and reachable from TaskManagers
- Set correct ACLs on the lock path
- Tune session/connection timeouts for expected maintenance durations
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
- 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/a04952a84db49d85.
Report an issue: GitHub.