voonhous commented on code in PR #19334:
URL: https://github.com/apache/hudi/pull/19334#discussion_r3629095383
##########
hudi-sync/hudi-hive-sync/src/main/java/org/apache/hudi/hive/transaction/lock/HiveMetastoreBasedLockProvider.java:
##########
@@ -192,17 +195,15 @@ private void acquireLockInternal(long time, TimeUnit
unit, LockComponent lockCom
final LockRequest lockRequestFinal = lockRequest;
this.lock = executor.submit(() -> hiveClient.lock(lockRequestFinal))
.get(time, unit);
-
- // refresh lock in case that certain commit takes a long time.
- Heartbeat heartbeat = new Heartbeat(hiveClient, lock.getLockid());
- long heartbeatIntervalMs = lockConfiguration.getConfig()
- .getLong(LOCK_HEARTBEAT_INTERVAL_MS_KEY,
DEFAULT_LOCK_HEARTBEAT_INTERVAL_MS);
- future = executor.scheduleAtFixedRate(heartbeat, heartbeatIntervalMs /
2, heartbeatIntervalMs, TimeUnit.MILLISECONDS);
+ scheduleHeartbeat();
} catch (InterruptedException | TimeoutException e) {
if (this.lock == null || this.lock.getState() != LockState.ACQUIRED) {
LockResponse lockResponse =
this.hiveClient.checkLock(lockRequest.getTxnid());
Review Comment:
Not this PR's bug, but while we're here: `checkLock()` takes a **lock id**,
and `getTxnid()` is always `0` for a request built via `LockRequestBuilder`. If
this recovery path ever fires, the recovered `lockid` is dubious -- and it now
also feeds `scheduleHeartbeat()` -> `heartbeat(0, lockid)`. Fine to keep it
consistent with the main path here, but maybe add a `// pre-existing: txnid vs
lockid` note or file a follow-up.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
