rangareddy commented on issue #9015: URL: https://github.com/apache/hudi/issues/9015#issuecomment-5102986183
This issue was reviewed as part of the JIRA-migrated backlog triage. Findings: There is no quotable stack trace on this issue. The template's Stacktrace section was submitted with the placeholder text intact, and the traces you did provide -- including in reply to the request on 2023-06-20 -- were posted as screenshots, so the failure cannot be searched against or reproduced. There is also no reproduction script for the multi-writer setup. The diagnosis offered on 2023-06-21 -- check whether a lock file already exists at `.hoodie/lock` and remove it manually -- was never followed up. That is the usual cause of this exception with `FileSystemBasedLockProvider`: a writer that dies without releasing the lock leaves the file behind, and subsequent writers cannot acquire it. Worth knowing if you revisit this: `FileSystemBasedLockProvider` now handles that case itself. It reads a lock expiry (`hoodie.write.lock.filesystem.expire`) and, in `tryLock`, checks whether an existing lock has expired and deletes it if so -- `FileSystemBasedLockProvider.java:121-128` logs `Delete expired lock file` when it does. So a stale lock left by a crashed writer no longer blocks writers indefinitely, provided the expiry is set sensibly for your job duration. We are closing this as stale rather than as fixed, because your specific failure was never established -- with only screenshots it is not possible to confirm it was the stale-lock case. If you still hit lock acquisition failures on a recent version, please open a fresh issue with the stack trace as text and the lock-provider configuration. -- 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]
