wombatu-kun commented on code in PR #20206:
URL: https://github.com/apache/hudi/pull/20206#discussion_r4202966684
##########
hudi-client/hudi-client-common/src/main/java/org/apache/hudi/client/transaction/lock/FileSystemBasedLockProvider.java:
##########
@@ -179,15 +183,35 @@ public boolean tryLock(long time, TimeUnit unit) {
public void unlock() {
synchronized (LOCK_FILE_MONITOR) {
try {
- if (storage.exists(this.lockFile)) {
- storage.deleteFile(this.lockFile);
- }
+ deleteOwnLockFile();
} catch (IOException io) {
throw new
HoodieIOException(generateLogStatement(LockState.FAILED_TO_RELEASE), io);
}
}
}
+ private void deleteOwnLockFile() throws IOException {
+ String ownContent = ownLockContent;
+ if (ownContent == null) {
Review Comment:
With `hoodie.write.lock.filesystem.expire` at its default of 0, nothing
removes a lock file left by a crashed writer any more, so every later write on
the table fails until someone deletes the file by hand - is that intended? If
so, the class javadoc's "if writeClient crash and never run again" and the
expire config's doc should say that crash recovery now needs an expiry or
manual cleanup.
--
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]
