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]]
