hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Hadoop Wiki] Update of "ZooKeeper/GSoCReadOnlyMode" by SergeyDoroshenko
Date Mon, 05 Jul 2010 15:21:12 GMT
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.
  

Mime
View raw message