james strachan commented on ZOOKEEPER-78:

Thanks Flavio! 

Totally agreed on 1. Strictly speaking we should catch all exceptions and 
handle them properly (which may mean throwing some, or responding properly to 
others or whatever).

One of the main reasons for the retry logic was to avoid errors like trying to 
create a znode that already exists or loosing connection to the ZK server etc - 
but we should go through all possible exceptions and handle them much cleaner.

In particular we really need test cases that show the server closing and 
restarting during the process of acquiring the lock or after a lock owner has 
the lock etc.  

I figured I'd send a patch first and see if anyone else had a better 
implementation lying around - or knew a neater way to solve this - before I 
spent too much time getting it totally correct etc. 

For 2) I just added that so that when running the unit tests you could see INFO 
or DEBUG level logging etc (particularly when running in your IDE)

> added a high level protocol/feature - for easy Leader Election or exclusive 
> Write Lock creation
> -----------------------------------------------------------------------------------------------
>                 Key: ZOOKEEPER-78
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78
>             Project: Zookeeper
>          Issue Type: New Feature
>          Components: java client
>    Affects Versions: 3.0.0
>            Reporter: james strachan
>            Assignee: james strachan
>         Attachments: writeLock_protocol.patch
> Here's a patch which adds a little WriteLock helper class for performing 
> leader elections or creating exclusive locks in some directory znode. Note 
> its an early cut; am sure we can improve it over time. The aim is to avoid 
> folks having to use the low level ZK stuff but provide a simpler high level 
> abstraction.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to