I writing a lock implementation that agrees with the lock recipe in the documentation<http://zookeeper.apache.org/doc/current/recipes.html#sc_recipes_Locks>. In step 5, the thread needs to wait for a notification that it may have the lock. Since I'm working with many threads, each thread needs to wait on its own object. I decided that it would be easiest if the thread waits on the watcher that is passed as a parameter to zk.exists in step 4. This way, when a thread may have the lock, its watcher gets called directly.
(The other option would be to have only one watcher. Then, when watcher.process() gets called, the watcher would need to figure out which thread it should wake up.) The only problem is that I might have a memory leak. In step 5, if exists() returns false, then the node does not exist and it will never exist because it is sequential. This means that the client will forever hold a watch for a node that will never be created, and that watch will forever reference my watcher object. Therefore, even if I try to dump that watcher object (since I don't need it anymore), the client will still hold a reference to it and it won't be garbage collected. The only way that I've come up with to plug the memory leak is to recreate the znode as non-sequential, thereby triggering the watch I set, and then delete the znode to prevent a deadlock. Can anyone confirm that this is indeed a memory leak, and does anyone know a better way to prevent it?
