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/FAQ" by PatrickHunt
Date Fri, 05 Mar 2010 17:49:50 GMT
Dear Wiki user,

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

The "ZooKeeper/FAQ" page has been changed by PatrickHunt.
http://wiki.apache.org/hadoop/ZooKeeper/FAQ?action=diff&rev1=10&rev2=11

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

  SESSION_EXPIRED automatically closes the ZooKeeper handle. In a correctly operating cluster,
you should never see SESSION_EXPIRED. It means that the client was partitioned off from the
ZooKeeper service for more the the session timeout and ZooKeeper decided that the client died.
Because the ZooKeeper service is ground truth, the client should consider itself dead and
go into recovery. If the client is only reading state from ZooKeeper, recovery means just
reconnecting. In more complex applications, recovery means recreating ephemeral nodes, vying
for leadership roles, and reconstructing published state.
  
  Library writers should be conscious of the severity of the expired state and not try to
recover from it. Instead libraries should return a fatal error. Even if the library is simply
reading from ZooKeeper, the user of the library may also be doing other things with ZooKeeper
that requires more complex recovery.
+ 
+ Session expiration is managed by the ZooKeeper cluster itself, not by the client. When the
ZK client establishes a session with the cluster it provides a "timeout" value. This value
is used by the cluster to determine when the client's session expires. Expirations happens
when the cluster does not hear from the client within the specified session timeout period
(i.e. no heartbeat). At session expiration the cluster will delete any/all ephemeral nodes
owned by that session and immediately notify any/all connected clients of the change (anyone
watching those znodes). At this point the client of the expired session is still disconnected
from the cluster, it will not be notified of the session expiration until/unless it is able
to re-establish a connection to the cluster. The client will stay in disconnected state until
the TCP connection is re-established with the cluster, at which point the watcher of the expired
session will receive the "session expired" notification.
+ 
+ Example state transitions for an expired session as seen by the expired session's watcher:
+ 
+  1. 'connected' : session is established and client is communicating with cluster (client/server
communication is operating properly)
+  1.  .... client is partitioned from the cluster
+  1. 'disconnected' : client has lost connectivity with the cluster
+  1.  .... time elapses, after 'timeout' period the cluster expires the session, nothing
is seen by client as it is disconnected from cluster
+  1.  .... time elapses, the client regains network level connectivity with the cluster
+  1. 'expired' : eventually the client reconnects to the cluster, it is then notified of
the expiration
  
  <<BR>>
  <<Anchor(4)>>

Mime
View raw message