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 SergeyDoroshenko. http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode?action=diff&rev1=5&rev2=6 -------------------------------------------------- - '''Abstract''' + == 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. - 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 will implement a 'read-only' mode for ZooKeeper servers that allows read requests to be served as long as the client can contact a server - 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. + == Detailed description == + === Client-side changes === + * '''API:'''<<BR>>To enable read-only functionality, user should pass optional boolean parameter to the ZooKeeper's constructor. When a client with r-o mode enabled is connected to a server-in-majority, it behaves as a normal one. But if server is partitioned, read requests issued by such client are allowed, while write requests fail with exception.<<BR>>If r-o mode is disabled for a client it won't connect to any server if there's no quorum. + * '''Session handling:'''<<BR>> + * '''Session states. '''New session state is introduced, CONNECTEDREADONLY. Client will move to this state when it's connected to a partitioned server (which automatically implies that only clients with r-o mode enabled can be in this state). If we're in this state we can issue only read requests. From this state session could transition to CONNECTED -- if client's reconnected to r/w server -- and to all states reachable from CONNECTED state. + * '''Session events. '''How will application know mode's changed? Default watcher of r-o client will inform application about mode change from usual to read-only and vice versa, besides current notifications like connection loss. + * - <<BR>> - - '''Detailed description''' - - <<BR>> - - * New client class for read-only mode will be created by extending !ZooKeeper class.<<BR>>When this client is connected to a server-in-majority, it should behave as a normal one. But when server is partitioned, client will allow only read requests, write requests will fail on the server.<<BR>> - - * How application will know mode's changed?<<BR>>Global callback for read-only client will inform application about mode change from usual to read-only and vice versa, besides current notifications like connection loss.<<BR>> - - * Make server distinguish these two types of clients: add "am-i-readonly-client" field to a packet client sends to a server. <<BR>>This will involve changes in both Java and C clients.<<BR>> + * Make server distinguish these two types of clients: add "am-i-readonly-client" field to a packet client sends to a server during connection handshake. If a server in r-o mode receives connection request from not r-o client, it rejects the client.<<BR>>This will involve changes in both Java and C clients.<<BR>> * Currently, server still accepts connections even if it's partitioned, but drops them quickly after they get connected.<<BR>><<BR>>This should be changed in this way: when server loses a quorum, it doesn't drop read-only clients. It just informs them about mode change (they will receive notification via their global watcher). After this it should respond to read requests and throw exceptions to write requests.<<BR>>(For normal not read-only clients, server will behave as it does now.)<<BR>><<BR>>Implementation details:<<BR>>Create new subclass of !ZooKeeperServer, !ReadOnlyZooKeeperServer, which has a pretty simple chain of request processors -- only one !ReadOnlyRequestProcessor, which answers to read requests and throws exceptions to state-changing operations. When server, namely !QuorumPeer, loses a quorum it destroys whichever !ZooKeeperServer was running and goes to LOOKING state (this is a current logic which doesn't need to be altered), and creates !ReadOnlyZooKeeperServer (new logic). Then, when some client connects to this peer, if running server sees this is a read-only client, it starts handling its requests; if it's a usual client, server drops the connection, as it does currently.<<BR>>When the peer reconnects to the majority, it acts similarly to other state changes: shutdowns zk server (which will cause notification of all read-only clients about state change), and switches to another state.
