I understand. I believe that despite my "checkExists()" calls, I am seeing one case where I still see an unexpected NodeExistsException.
On Tue, Sep 1, 2015 at 2:14 PM, Gregory Chanan <[email protected]> wrote: > Just to reiterate Jordan's point -- given ZooKeeper's server semantics you > cannot avoid NodeExistsExceptions in general. > > If ZooKeeper had different semantics -- for example state-based APIs > (e.g."this node should exist at the end of this call") rather than > action-based APIs (e.g. "create") -- it would be possible to avoid these > exceptions. Or if you could enforce single-writer at a time semantics. > > But given ZooKeeper's API choices, I believe most adminstrators simply > live with the exceptions or filter them out. > > Greg > > On Tue, Sep 1, 2015 at 7:19 AM, Daniel Kashtan <[email protected]> > wrote: > >> I can definitely work around this problem by configuring my log4j file to >> WARN for the admins and then have a separate file with a verbose view set >> to INFO. >> >> What would be ideal is to have an option to call the .start() method with >> a checkExists(). I am already doing using checkExists() in other parts of >> my code, but if I am using the Shared Value recipe I believe I cannot avoid >> these exceptions being thrown in the server (please correct me if I am >> wrong though). >> >> Personally I can tolerate the NodeExists exceptions in the logs, but when >> administrators are running the software in production and see exceptions in >> the logs they think something is broken. >> >> On Mon, Aug 31, 2015 at 7:49 PM, Jordan Zimmerman < >> [email protected]> wrote: >> >>> Why would this be needed? It adds an additional ZK call for no good >>> reason. If the node exists, the exception is thrown. In any event, even if >>> checkExists() succeeds there’s a chance that another process can create the >>> node before the create() call is made. So, it doesn’t do what you want >>> anyway. >>> >>> -Jordan >>> >>> On August 31, 2015 at 2:46:09 PM, Cameron McKenzie ( >>> [email protected]) wrote: >>> >>> Would it be possible in the future to have Curator have the option to >>> run a checkExists() before the .start() call on a recipe like Shared-Value? >>> Is the extra overhead not worth the trouble? >>> >>> >> >> >> -- >> -Daniel >> > > -- -Daniel
