[Hadoop Wiki] Update of "ZooKeeper/GSoCReadOnlyMode" by Sergey Doroshenko

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change notification.

The "ZooKeeper/GSoCReadOnlyMode" page has been changed by Sergey Doroshenko.
http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode

--------------------------------------------------

New page:
'''Abstract'''

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. 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 that allowed read requests to be served as long as the client can contact a server.

<<BR>>

'''Detailed description'''

Currently when ZK looses a quorum, say 3 of 5 servers become dead, 2 others which are alive

 1. start throwing exceptions during leader election
 1. drop existing clients connections
 1. drop new clients should ones connect

-- and so and so in a loop, until quorum will be re-established.

Naive idea is to change current behaviour in the way that server doesn't drop clients when partitioned (only informs them about partitioning), and only throw exceptions when client is attempting a write. This is backwards incompatible change on how users currently manage sessions.

<<BR>>

My idea is to do the following:

 * Create "read-only" Zookeeper client -- either by adding read-only mode in current !ZooKeeper class (and passing "mode" parameter in ctor), or by creating separate class (possibly by extending current !ZooKeeper to allow transparent usage by ZK users).
 * Make server distinguish these 2 types of clients. For old ones behaviour remains the same, which eliminates backwards incompatibility. <<BR>>For new "read-only" clients server actions are these: <<BR>>
  * when we are in quorum, allow all operations, as if the client is the normal one
  * when partitioning occurs, inform clients about state change
  * when we are partitioned, allow only read operations, answer with exception to writes

Benefits of this approach: transparent usage of a new client, backwards compatible.

Drawbacks: more coupling between server and client.

<<BR>>

'''Related links'''

Jira ticket: [[https://issues.apache.org/jira/browse/ZOOKEEPER-704|ZOOKEEPER-704]]

My GSoC [[http://docs.google.com/View?id=dghqvqdd_51ffvhcsdb|proposal]]