Josh Elser created HBASE-26461: ---------------------------------- Summary: [hboss] Delete self lock without orphaning znode Key: HBASE-26461 URL: https://issues.apache.org/jira/browse/HBASE-26461 Project: HBase Issue Type: Bug Reporter: Josh Elser Assignee: Josh Elser
Fallout from HBASE-26437 {quote}Could do the {{removeInMemoryLocks}} separately in HBASE-26453, but I think then znodes would get created again when unlocking, failing this PR tests. So, once we fix {{{}removeInMemoryLocks{}}}, we need to make sure {{rename}} and {{delete}} would not recreate the path again when calling {{{}unlock{}}}. {quote} The changes from HBASE-26453 inadvertently passed their unit tests because we didn't remove the Mutex object like we intended to do (after deleting a file/dir or renaming a file/dir, we intend to remove the mutex and znode for that file/dir and all beneath it). Right now, we only actually delete the children (znode and mutex objects) for that deleted/renamed path. Meaning, we are still orphaning resources. I implemented the fix in lockRename based on what we did in lockDelete, so we're making incremental progress. The lock cleanup process and Mutex logic need to be reworked because we cannot do it in two-phases as we currently do. In order to get the mutex to release it (when we are holding it already), we currently will re-create znodes back in ZooKeeper. The other solution, based on googling, appears to be to use a [Reaper|https://www.javadoc.io/doc/org.apache.curator/curator-recipes/2.4.1/org/apache/curator/framework/recipes/locks/Reaper.html]. This might also be an easier solution to the problem to do the rest of the cleanup. -- This message was sent by Atlassian Jira (v8.20.1#820001)