Curator/Zookeeper lock cleanup

Question

I’m using the InterProcessSemaphoreMutex for a distributed locking recipe.

A typical path for a lock might be

/lock/calendar/uuid

Where uuid is of course a uuid and hence many lock paths may be generated.

I’d assume these paths need to be cleaned up eventually, so I’ve tried using childreaper and reaper to do so after I unlock the lock.

ChildReaper kind of works. If I add /lock/calendar/uuid it happily removes the children. the log shows it removes the leases and locks and the node itself is shown to be gone in zkClient However suddenly it begins complaining in a seemingly endless loop that the path is gone. This despite trying Mode.Delete and Mode.Until Gone.

Reaper does nothing, probably because /lock/calendar/uuid has children.

Am I missing something? Do I not need to clean up these locks? What do I need to worry concurrency wise about.

Answer 1

InterProcessSemaphoreMutex creates additional child nodes such as leases, locks, etc. My workaround for this particular type of lock is to add additional path /lock/path/leases, /lock/path/locks, etc to the Reaper when you acquire the lock.

Answer 2

If you use the latest ZooKeeper 3.5.x and the latest Curator, Curator uses "container" nodes for all its recipes and these are automatically cleaned up as needed. Curator's Reaper has been deprecated.