You're right, we should have an "error handling" section in that doc, the assumption is that this is the algo when things are working, but what happens if things go awry?
One way to handle the issue you describe, is when the client reconnects to the cluster, if the session is not expired it could look at any outstanding requests it made and not gotten responses for. In this case it could scan the list looking for any znode that it created (see the Stat object) and make a determination based on that. I see you entered ZOOKEEPER-1262, perhaps you could supply a patch to the docs detailing this? (btw - your email address is getting flagged by gmail as spam, so I suspect no-one has seen this email - Harsh alerted me about this issue) Patrick On Thu, Oct 27, 2011 at 11:26 AM, Jordan Zimmerman <[email protected]> wrote: > http://zookeeper.apache.org/doc/trunk/recipes.html#sc_recipes_Locks > > I've just been informed that the recipe for Locking (and probably others) is > seriously incorrect. When creating a sequential ephemeral node, there is a > possibility that the ZK server can crash before the result is returned to the > client. The implication is that the client will never know what Number was > assigned to its node. Because the session is still valid, a dead lock will > result. > > This is very bad (unless I'm missing something). The documentation leads > people to write code that won't behave correctly. > > -JZ >
