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

  1. Re-check Hive metastore for orphaned locks (SHOW LOCKS / metastore lock tables) and clear them or let heartbeats/timeouts expire them.
  2. Avoid interrupting threads during commit; cancel at a point between operations, or use a lock manager (e.g. DynamoDbLockManager) that cleans up reliably.
  3. Ensure the metastore client call timeout is shorter than the interrupt source's patience so cleanup completes before cancellation.
  4. 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

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


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