I would recommend not spending a whole lot of time figuring out how to make Zookeeper lie to the clients. It is hard enough to make distributed software that tells the truth.
Why don't you just make the ZK structure match what you are trying to do? For instance, have a znode containing the key and a separate znode that is just for watching. Then the server has the option of updating both znodes or just the key depending on what behavior you want to get. This is simple and straightforward and makes it very clear what you mean to do. Why hack the server for such a thing? On Fri, Sep 2, 2011 at 1:37 AM, Mahadev Konar <[email protected]>wrote: > Ben, > I dont think I fully understand the use case. Is it possible that you > can register a different callback for that key? > > Something like: > > zk.exists(String path, Watcher watcher) > > where you can register a different watcher for this path? > > Would this work? > > mahadev > > > On Thu, Sep 1, 2011 at 5:58 PM, Ben Hall <[email protected]> wrote: > > Hi, > > > > We have an interesting problem use case that we wanted to ping the group > about. > > > > We have a Key on all of our Ensemble servers. All of our clients are > also subscribed to this key. We want to remove the key from the ensemble > servers without this action getting propagated down to the clients. Or if > it does get propagated down - at a minimum we do not want to watch callback > function to be called. > > > > Is there a way to in essence sever the watches from the server > perspective without the client knowing? > > > > We are investing looking into the hidden keys on the zookeeper servers > that hold the list of watches and possibly editing that key. has anyone > done that before? Do we know what happens when that key is edited manually? > > > > Any other suggestions or possibilities available to us? > > > > Thanks > > Ben >
