[jira] [Created] (HBASE-26461) [hboss] Delete self lock without orphaning znode

["Josh Elser (Jira)" <ji...@apache.org>]

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)