There is not much way to totally avoid this without massive performance loss because the connection loss could be during the the time that the confirmation is returning.
You may be able to tell if the file is yours be examining the content and ownership, but this is pretty implementation dependent. In particular, it makes queues very difficult to implement correctly. If this happens during the creation of an ephemeral file, the only option may be to close the connection (thus deleting all ephemeral files) and start over. On Thu, Oct 1, 2009 at 8:05 AM, Peter Voss <i...@petervoss.org> wrote: > 3) there's definitely an issue in the retryUntilConnected logic that you >> need to address >> >> let's say you call zkclient.create, and the connection to the server is >> lost while the request is in flight. At this point ConnectionLoss is thrown >> on the client side, however you (client) have no information on whether the >> server has made the change or not. The retry method's while loop will re-run >> the create (after reconnect), and the result seen by the caller (user code) >> could be either OK or may be NODEEXISTS exception, there's no way to know >> which. >> >> Mahadev is working on ZOOKEEPER-22 which will address this issue, but >> that's a future version, not today. >> > > Good catch. I wasn't aware that nodes could still be have been created when > receiving a ConnectionLoss. But how would you deal with that? > If we create a znode and get a ConnectionLoss exception, then wait until > the connection is back and check if the znode is there. There is no way of > knowing whether it was us who created the node or somebody else, right? -- Ted Dunning, CTO DeepDyve
