Sergey Doroshenko commented on ZOOKEEPER-704:
Dave, thanks for feedback,
Did you check http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode ?
Approach described there is similar to what you've proposed: make server
distinguish read-only and usual clients.
However, I was thinking that r-o client should go to read-only mode right after
server it's tied to is partitioned, without trying to reconnect to majority.
But your idea that client should try all servers first is definitely a better
Also I think current behavior of ZooKeeper client should remain unchanged.
I mean, there should be either new class for r-o client, or new functionality
in current client which is explicitly triggered say by a flag passed to ctor.
The idea is not to break code for current users.
> GSoC 2010: Read-Only Mode
> Key: ZOOKEEPER-704
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-704
> Project: Zookeeper
> Issue Type: Wish
> Reporter: Henry Robinson
> Read-only mode
> Possible Mentor
> Henry Robinson (henry at apache dot org)
> Java and TCP/IP networking
> When a ZooKeeper server loses contact with over half of the other servers in
> an ensemble ('loses a quorum'), it stops responding to client requests
> because it cannot guarantee that writes will get processed correctly. For
> some applications, it would be beneficial if a server still responded to read
> requests when the quorum is lost, but caused an error condition when a write
> request was attempted.
> This project would implement a 'read-only' mode for ZooKeeper servers (maybe
> only for Observers) that allowed read requests to be served as long as the
> client can contact a server.
> This is a great project for getting really hands-on with the internals of
> ZooKeeper - you must be comfortable with Java and networking otherwise you'll
> have a hard time coming up to speed.
This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.