fhan688 commented on PR #20395: URL: https://github.com/apache/hudi/pull/20395#issuecomment-6307495082
> #20206 already fixes this: its `unlock()` and `close()` delete the lock file only while it still holds the content this instance wrote, which covers the failed-contender and repeated-unlock cases here, a lock taken over after expiry, and a lock file whose write failed after the exclusive create. That last case regresses in this PR, since `lockAcquired` stays false and nothing removes the file, so every later writer stays blocked at the default expiry of 0; is there a case here that #20206 misses? Thanks for pointing this out. I do not see a case covered by this PR that #20206 misses, so I will close this PR as a duplicate. One separate follow-up concern is that the read/compare/delete sequence in #20206 is not an atomic conditional delete across processes, but that is an architectural issue outside the scope of this PR. -- 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]
