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 >
