Conversation
Does not delete the top level `gc/lock/` path, instead it just deletes all locks underneath the path. Updates ITs and the Admin utility to delete gc locks the same way.
keith-turner
left a comment
keith-turner
left a comment
There was a problem hiding this comment.
Which test was failing? Was there a problem with the ZooZap code?
core/src/main/java/org/apache/accumulo/core/fate/zookeeper/ServiceLock.java
Outdated
Show resolved
Hide resolved
The ZooZap code was incorrect. #6077 replaced the use of
The new ServiceLock code was calling |
keith-turner
left a comment
keith-turner
left a comment
There was a problem hiding this comment.
The new ServiceLock code was calling recursiveDelete directly with the top-level path. So it was removing all the gc locks
Ok, so it seems after these changes that the ServiceLock method and ZooZap.removeSingletonLock now behave in a very similar way, except they seem to report/log differently. Noticed that could lead to inconsistent logging/printing.
Yes I think we can iterate a bit further on this and remove the |
Switches to using ServiceLock.deleteLocks for tserver locks so lock deletes can show up in the Admin log (if debug is enabled). Fixed a bug where the command would fail if no scan servers were running. Added the ability to also force stop the compaction-coordinator server
getLockData() also throws NoNodeException if nothing exists.
2 participants
Does not delete the top level
gc/lock/path, instead it just deletes all locks underneath the path.Added validation checks from other lock deletion code paths.
Updates ITs and the Admin utility to delete gc locks the same way.
Fixes IT failures caused by #6077