You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@zookeeper.apache.org by Jordan Zimmerman <jz...@netflix.com> on 2011/10/27 20:26:02 UTC

Major issue with recipe doc

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

Re: Major issue with recipe doc

Posted by Patrick Hunt <ph...@apache.org>.
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
<jz...@netflix.com> 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
>