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?action=diff&rev1=4&rev2=5 -------------------------------------------------- * 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>> - * 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>> + * 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. * Recovering from partitioning has two aspects:<<BR>> * On the server side, when server regains a quorum, it should notify all currently connected read-only clients about mode change; after this it can answer to write requests.
