apache/iceberg · warning
Interrupted finding locks to unlock {}.{}
Error message
Interrupted finding locks to unlock {}.{} What it means
MetastoreLock.unlock() interrupts the thread waiting on Hive Metastore lock cleanup when the RPC to locate held locks (get_locks) is interrupted. Since the unlock is failing during shutdown/rollback, the library logs a warning, restores the interrupt status, and gives up; the Hive locks may be left orphaned until the metastore's lock timeout reaps them. This is a best-effort path, not a thrown exception.
Source
Thrown at hive-metastore/src/main/java/org/apache/iceberg/hive/MetastoreLock.java:423
id = lockId.get();
}
doUnlock(id);
} catch (InterruptedException ie) {
if (id != null) {
// Interrupted unlock. We try to unlock one more time if we have a lockId
try {
Thread.interrupted(); // Clear the interrupt status flag for now, so we can retry unlock
LOG.warn("Interrupted unlock we try one more time {}.{}", databaseName, tableName, ie);
doUnlock(id);
} catch (Exception e) {
LOG.warn("Failed to unlock even on 2nd attempt {}.{}", databaseName, tableName, e);
} finally {
Thread.currentThread().interrupt(); // Set back the interrupt status
}
} else {
Thread.currentThread().interrupt(); // Set back the interrupt status
LOG.warn("Interrupted finding locks to unlock {}.{}", databaseName, tableName, ie);
}
} catch (Exception e) {
LOG.warn("Failed to unlock {}.{}", databaseName, tableName, e);
}
}
private void doUnlock(long lockId) throws TException, InterruptedException {
metaClients.run(
client -> {
client.unlock(lockId);
return null;
});
}
private void acquireJvmLock() {
if (jvmLock != null) {
throw new IllegalStateException(
String.format("Cannot call acquireLock twice for %s", fullName));View on GitHub (pinned to 86d9c8fc54)
Solutions
- Re-check Hive metastore for orphaned locks (SHOW LOCKS / metastore lock tables) and clear them or let heartbeats/timeouts expire them.
- Avoid interrupting threads during commit; cancel at a point between operations, or use a lock manager (e.g. DynamoDbLockManager) that cleans up reliably.
- Ensure the metastore client call timeout is shorter than the interrupt source's patience so cleanup completes before cancellation.
- Increase hive.txn.timeout / lock reaper settings so orphaned locks do not block subsequent commits.
Example fix
// before future.cancel(true); // interrupts commit thread mid-unlock, orphans locks // after future.cancel(false); // or await commit completion before cancelling
Defensive patterns
Strategy: retry
Validate before calling
// before committing, check for pre-existing locks
List<ShowLocksResponseElement> locks = client.showLocks(new ShowLocksRequest(db, table)).getLocks();
if (locks.stream().anyMatch(l -> l.getState().equals("ACQUIRED"))) {
throw new IllegalStateException("Hive lock already held on " + db + "." + table);
} Try / catch
try {
commitWithLock();
} catch (InterruptedException ie) {
Thread.currentThread().interrupt();
// schedule lock cleanup in a separate, non-interrupted thread
cleanupExecutor.submit(() -> unlockQuietly(db, table));
} Prevention
- Don't interrupt threads that are mid-commit; prefer cooperative cancellation checkpoints.
- Use a lock manager (DynamoDbLockManager) that supports reliable unlock on cancellation.
- Tune hive lock timeout so orphaned locks expire quickly.
- Monitor SHOW LOCKS for accumulating ACQUIRED locks on Iceberg tables.
When it happens
Trigger: Thread waiting inside unlock()'s Thrift client call (get_locks via IMetaStoreClient) is interrupted — typically Task.cancel(), query cancellation, or JVM shutdown interrupting the Iceberg commit/abort path that acquired a Hive lock on databaseName.tableName.
Common situations: Spark/Flink/Trino query cancellation while a Hive-lock-based Iceberg commit is aborting; executor shutdown during long commits; kill -SIGINT of a job mid-commit.
Understand the failure class
Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.
Related errors
- Failed to acquire locks from metastore because the underlyin
- Failed to heartbeat for hive lock. %s
- Metastore operation failed for %s.%s
- Could not acquire the lock on %s.%s, lock request ended in s
- Interrupted while trying to find lock for table %s.%s
AI-assisted analysis of apache/iceberg@86d9c8fc54 (2026-09-12).
Data as JSON: /api/errors/93a24663682187e8.
Report an issue: GitHub.