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)
