A customer started to see this in the logs, but happily everything was working as intended:
This was happening, because a race condition between the lock releasing, and lock acquiring. The thread releasing the lock removes the parent ZK node just after the thread acquiring the lock made sure, that the parent node exists.
Since this can happen without any real problem, I plan to add NODEEXISTS, and NONODE as a transient ZooKeeper exception, so the users are not confused.
Also, the original author of ZooKeeperHiveLockManager maybe planned to handle different ZooKeeperExceptions differently, and the code is hard to understand. See the continue and the break. The break only breaks the switch, and not the loop which IMHO is not intuitive:
If we do not want to try again in case of a "Serious Zookeeper exception:", then we should add a label to the do loop, and break it in the switch.
If we do want to try regardless of the type of the ZK exception, then we should just change the continue; to break; and move the lines part of the code which did not run in case of continue to the default switch, so it is easier to understand the code.
Any suggestions or ideas [~ctang.ma] or Szehon Ho?