Ted Dunning wrote:
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.
One nice thing about ephemeral is that the Stat contains the owner
sessionid. As you say, it's highly implementation dependent. It's also
something we recognize is a problem for users, we've slated it for 3.3.0
http://issues.apache.org/jira/browse/ZOOKEEPER-22
Patrick
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?
