Database Reference
In-Depth Information
Sessions
A ZooKeeper client is configured with the list of servers in the ensemble. On startup, it
tries to connect to one of the servers in the list. If the connection fails, it tries another serv-
er in the list, and so on, until it either successfully connects to one of them or fails because
all ZooKeeper servers are unavailable.
Once a connection has been made with a ZooKeeper server, the server creates a new ses-
sion for the client. A session has a timeout period that is decided on by the application that
creates it. If the server hasn't received a request within the timeout period, it may expire
the session. Once a session has expired, it may not be reopened, and any ephemeral nodes
associated with the session will be lost. Although session expiry is a comparatively rare
event, since sessions are long lived, it is important for applications to handle it (we will
see how in
The Resilient ZooKeeper Application
)
.
Sessions are kept alive by the client sending ping requests (also known as heartbeats)
whenever the session is idle for longer than a certain period. (Pings are automatically sent
by the ZooKeeper client library, so your code doesn't need to worry about maintaining the
session.) The period is chosen to be low enough to detect server failure (manifested by a
read timeout) and reconnect to another server within the session timeout period.
Failover to another ZooKeeper server is handled automatically by the ZooKeeper client,
and crucially, sessions (and associated ephemeral znodes) are still valid after another serv-
er takes over from the failed one.
During failover, the application will receive notifications of disconnections and connec-
tions to the service. Watch notifications will not be delivered while the client is disconnec-
ted, but they will be delivered when the client successfully reconnects. Also, if the applic-
ation tries to perform an operation while the client is reconnecting to another server, the
operation will fail. This underlines the importance of handling connection loss exceptions
in real-world ZooKeeper applications (described in
The Resilient ZooKeeper Applica-
Time
There are several time parameters in ZooKeeper. The
tick time
is the fundamental period
of time in ZooKeeper and is used by servers in the ensemble to define the schedule on
which their interactions run. Other settings are defined in terms of tick time, or are at least
constrained by it. The session timeout, for example, may not be less than 2 ticks or more
than 20. If you attempt to set a session timeout outside this range, it will be modified to
fall within the range.
