apache/iceberg · error · LockException

Failed to find lock for table %s.%s

Error message

Failed to find lock for table %s.%s

What it means

After creating the lock request, MetastoreLock polls ShowLocks results to find the lock it just created by matching agentInfo. If a poll iteration completes without finding the agent's own lock among the table's locks, this LockException is thrown. It means the lock created by this client vanished or was never visible in the metastore's lock listing.

Source

Thrown at hive-metastore/src/main/java/org/apache/iceberg/hive/MetastoreLock.java:323

                LockResponse lockResponse = metaClients.run(client -> client.lock(request));
                lockInfo.lockId = lockResponse.getLockid();
                lockInfo.lockState = lockResponse.getState();
              } catch (TException te) {
                LOG.warn("Failed to create lock {}", request, te);
                try {
                  // If we can not check for lock, or we do not find it, then rethrow the exception
                  // Otherwise we are happy as the findLock sets the lockId and the state correctly
                  if (HiveVersion.min(HiveVersion.HIVE_2)) {
                    LockInfo lockFound = findLock();
                    if (lockFound != null) {
                      lockInfo.lockId = lockFound.lockId;
                      lockInfo.lockState = lockFound.lockState;
                      LOG.info("Found lock {} by agentInfo {}", lockInfo, agentInfo);
                      return;
                    }
                  }

                  throw new LockException(
                      "Failed to find lock for table %s.%s", databaseName, tableName);
                } catch (InterruptedException e) {
                  Thread.currentThread().interrupt();
                  interrupted.set(true);
                  LOG.warn(
                      "Interrupted while trying to find lock for table {}.{}",
                      databaseName,
                      tableName,
                      e);
                  throw new LockException(
                      e,
                      "Interrupted while trying to find lock for table %s.%s",
                      databaseName,
                      tableName);
                }
              } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
                interrupted.set(true);

View on GitHub (pinned to 86d9c8fc54)

Solutions

1. Increase hive.txn.timeout / lock heartbeat interval so short-lived locks are not purged during acquisition.
2. Ensure one JVM per host uses MetastoreLock, or that concurrent processes on the same host don't share/steal each other's locks (agentInfo collisions).
3. Re-run the commit; this is usually transient once the stale lock situation clears.
4. Check metastore logs for lock expiry/abortion events around the failure time to identify who removed the lock.

Example fix

// before
conf.setProperty("hive.txn.timeout", "60s");
// after
conf.setProperty("hive.txn.timeout", "600s"); // lock survives slow acquisition polls

// before committing, confirm the table's lock state via metastore:
// ShowLocksResponse resp = client.showLocks(req);
// abort if a foreign EXCLUSIVE lock already exists

try {
  table.commit(apply);
} catch (LockException e) {
  if (e.getMessage().startsWith("Failed to find lock")) {
    // transient lock loss; refresh and retry once metastore is stable
    backoffRetry(() -> { table.refresh(); table.commit(apply); });
  } else throw e;
}

When it happens

Trigger: Calling commit on a Hive-catalog table when a showLocks poll no longer lists a lock whose agentInfo matches this client — e.g. the lock expired (hive.txn.timeout) and was purged between creation and the polling check, or another process aborted it.

Common situations: Very slow commits or GC pauses letting the lock expire mid-acquisition; multiple JVMs on the same host with colliding agentInfo and one unlocking the other's lock; metastore purging locks after a heartbeat failure.

Related errors

• Timed out after %s ms waiting for lock on %s.%s
• Could not acquire the lock on %s.%s, lock request ended in s
• Cannot call acquireLock twice for %s
• Failed to acquire lock on file: %s with owner: %s
• Interrupted in call to listTables

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