Anthony Urso commented on ZOOKEEPER-104:

>> You might consider throwing KeeperException on KeptSet.add to avoid 
>> problems, for example, with addAll.

KeptSet.add does throw a wrapped KeeperException whenever one is caught. I have 
to wrap it in an unchecked exception because of the Set interface.

>> the idea is to let ZooKeeper store the elements of a set despite failures of 
>> the client that created these elements

For my needs, I would like the set to contain the nodes even if the creating 
client dies.  But I've made it configurable at instantiation in the new patch.

>> Again on KeptSet.add, it seems to me that you can shrink your synchronized 
>> block.

Good idea.  I think catching NodeExistsException eliminates the need for it 

>> the set is not resync'd with the server after disconnect

I think that's fixed now, by synchronizing upon getting any event with a 
connected state.

>> rather than add returning false, which would happen if the client added a 
>> string that was already present

Good catch, fixed.

>> Also note that the set is updated via a watch (even for changes made by this 
>> client), so you could add a string and an immediate check for existence may 
>> fail.


> KeptSet: a distributed data stucture backed by the children of a ZooKeeper 
> node
> -------------------------------------------------------------------------------
>                 Key: ZOOKEEPER-104
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-104
>             Project: Zookeeper
>          Issue Type: New Feature
>          Components: java client
>            Reporter: Anthony Urso
>            Assignee: Anthony Urso
>            Priority: Minor
>         Attachments: ZOOKEEPER-104.patch
> Here is an implementation of a ZooKeeper backed Java Set. It should be 
> generally useful.

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