joshelser commented on pull request #29: URL: https://github.com/apache/hbase-filesystem/pull/29#issuecomment-971115237
Oh, funny. So, my tests do actually clean up ZK, but not for the reason I thought :) ``` 2021-11-16 21:20:30,424 [main] DEBUG sync.ZKTreeLockManager (ZKTreeLockManager.java:recursiveDelete(229)) - Removing all mutex and znodes for paths beneath /s3a/embedded/hboss-junit/src 2021-11-16 21:20:30,429 [main] INFO sync.ZKTreeLockManager (ZKTreeLockManager.java:removeInMemoryLocks(253)) - Not removing /s3a/embedded because it's not beneath /s3a/embedded/hboss-junit/src 2021-11-16 21:20:30,430 [main] INFO sync.ZKTreeLockManager (ZKTreeLockManager.java:removeInMemoryLocks(253)) - Not removing /s3a/embedded/hboss-junit because it's not beneath /s3a/embedded/hboss-junit/src 2021-11-16 21:20:30,430 [main] INFO sync.ZKTreeLockManager (ZKTreeLockManager.java:removeInMemoryLocks(253)) - Not removing /s3a because it's not beneath /s3a/embedded/hboss-junit/src 2021-11-16 21:20:30,430 [main] INFO sync.ZKTreeLockManager (ZKTreeLockManager.java:removeInMemoryLocks(253)) - Not removing /s3a/embedded/hboss-junit/dest because it's not beneath /s3a/embedded/hboss-junit/src 2021-11-16 21:20:30,430 [main] INFO sync.ZKTreeLockManager (ZKTreeLockManager.java:removeInMemoryLocks(253)) - Not removing /s3a/embedded/hboss-junit/src because it's not beneath /s3a/embedded/hboss-junit/src 2021-11-16 21:20:30,430 [main] INFO sync.ZKTreeLockManager (ZKTreeLockManager.java:removeInMemoryLocks(253)) - Not removing / because it's not beneath /s3a/embedded/hboss-junit/src 2021-11-16 21:20:30,430 [main] DEBUG sync.ZKTreeLockManager (ZKTreeLockManager.java:writeUnlock(160)) - writeLock /s3a/embedded/hboss-junit/src release 2021-11-16 21:20:30,430 [main] INFO sync.ZKTreeLockManager (ZKTreeLockManager.java:get(403)) - Lock cached for /s3a/embedded/hboss-junit/src 2021-11-16 21:20:30,434 [main] DEBUG sync.ZKTreeLockManager (ZKTreeLockManager.java:writeUnlock(160)) - writeLock /s3a/embedded/hboss-junit/dest release 2021-11-16 21:20:30,434 [main] INFO sync.ZKTreeLockManager (ZKTreeLockManager.java:get(403)) - Lock cached for /s3a/embedded/hboss-junit/dest 2021-11-16 21:20:30,439 [main] INFO oss.TestZNodeCleanup (TestZNodeCleanup.java:teardown(79)) - Dumping contents of ZooKeeper after test from /s3a/embedded/hboss-junit 2021-11-16 21:20:30,439 [main] INFO oss.TestZNodeCleanup (TestZNodeCleanup.java:printZkBFS(88)) - /s3a/embedded/hboss-junit 2021-11-16 21:20:30,440 [main] INFO oss.TestZNodeCleanup (TestZNodeCleanup.java:printZkBFS(88)) - /s3a/embedded/hboss-junit/.hboss-lock-znode 2021-11-16 21:20:30,440 [main] INFO oss.TestZNodeCleanup (TestZNodeCleanup.java:printZkBFS(88)) - /s3a/embedded/hboss-junit/dest 2021-11-16 21:20:30,441 [main] INFO oss.TestZNodeCleanup (TestZNodeCleanup.java:printZkBFS(88)) - /s3a/embedded/hboss-junit/dest/.hboss-lock-znode ``` This is the logging I added after a successful `mv /src /dest`. We clean up the corresponding node for `/src` in ZK for HBOSS as expected, but I still got `removeInMemoryLocks()` wrong in that I don't remove the Mutex for the parent `/src` znode. That's a bug and the same one I thought I fixed. Go figure. However, because we don't remove that parent src lock, we can call release on it _without_ recreating the state in ZK. However, we do orphan the Mutex inside Curator/HBOSS which is no good. However, I think this also happens for lockDelete, so I think it might be best to fix that separately. Let me sleep on it and see what I think in the morning. Thanks for your careful eyes, Wellington. Curious what you think, too. -- 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: issues-unsubscr...@hbase.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
