I removed them on the ref branch. They do have value - the idea is that you really only need a single watch for any node for any path at a time - theoretically.
So the idea is to kind of keep you abreast of how many watches are created per path. But I think the impl is a little off vs the output. Eg, it reports "violations", but I think it's actually simply the stats of watches that have been added, removed for each path. I think maybe the original idea was once that a violation would be if you had multiple watches for a path at the same time, but I'm not sure that it works that way (I think it's a simple counter kept for each path for add/remove watch), and I don't think even under perfect conditions, that's how tests would work. We simulate multiple nodes, clients against a single zktestserver in a way that you wouldn't get 'violations' flagged correctly. So I think it really just gives you the stats on how many watches have been used for each path essentially. Which is useful theoretically in that you might notice you are all of a sudden using tons more watches for a given path after a patch vs before. But practically, I think this has offered no real value to devs and has some cost and complication in maintaining - hence I pulled it in my work.You can also get this kind of information directly from ZK I believe, with admin commands, vs the fairly invasive way done here. - Mark On Mon, May 17, 2021 at 12:27 PM Mike Drob <[email protected]> wrote: > [Resending to the correct list] > > Hi Devs, > > Do folks use the Zookeeper watch limits? What are they useful for > debugging? Can somebody give me an example of when they have been > helpful to you? > > The main reason I am asking is because I am looking at switching our > TestZookeeper to use the new 3.7.0 ZooKeeperServerEmbedded feature and > it would greatly simplify my task if I didn't need to worry about the > watch limits. > > It's believable that they add value, but they also look like the logic > hasn't been touched since 2014 by the mighty Tim Potter. > > Most of the times that I see them come up in the test output, it's > because something else failed anyway and we had lots of other watches > not get cleaned up, and the object release tracker went haywire as > well. > > Maybe Mark has some stuff on reference branch that makes these more > constrained as well? > > Hoping somebody knows the historical context and use case for these! > > Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- - Mark http://about.me/markrmiller
