ZooKeeper Sessions | Process of Sessions in ZooKeeper

In our last ZooKeeper tutorial, we discussed ZooKeeper watches. Today, we will see ZooKeeper Sessions. Moreover, we will discuss the complete working process of Sessions in ZooKeeper, which contains ZooKeeper sessions timeout, how to create a client session.

So, let’s start ZooKeeper Sessions.

What are ZooKeeper Sessions?

As we know for the operation of ZooKeeper, Sessions in ZooKeeper play the very important role. In FIFO order, all requests execute in session. Basically, the session establishes as soon as a ZooKeeper Client connects to a Server. After that, it assigns a session id to the client.

Moreover, to keep the ZooKeeper Sessions valid, the client sends heartbeats at a particular time interval.

However if for more than the period (ZooKeeper Session Timeout- specified at the starting of the service) the ZooKeeper ensemble does not receive heartbeats from a client, then it assumes that the client died.

Detailed Description of ZooKeeper Sessions

Basically, with the ZooKeeper service by creating a handle to the service using a language binding, a ZooKeeper client establishes a session in ZooKeeper.

To one of the servers which make up the ZooKeeper service at which point it switches to the CONNECTED state, the client library tries to connect. It happens as soon as the handle starts off in the CONNECTING state, once created.

In addition, the handle will move to the CLOSED state if an unrecoverable error occurs. Errors can be of any type: if the application explicitly closes the handle, ZooKeeper Sessions expiration or authentication failure.

Now you can see the figure above explains the possible state transitions of a ZooKeeper client.

 a. How to Create A Client Session

However, it is must that the application code offers a string (connection string) which consists of a comma-separated list of host: port pairs, in order to create a client session, though, each corresponds to a ZooKeeper server. For e.g. “127.0.0.1:4545” or “127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002”.
Added in 3.2.0:

Now, to the connection string, an optional chroot suffix may append. So, when interpreting all paths relative to this root, it will run the client commands.

On using the example would look like: 127.0.0.1:4545/app/a or 127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002/app/a. Here at “/app/a”, the client will get root.

Particularly, in multi-tenant environments this feature is useful. Especially, where each user of a particular ZooKeeper service could be rooted differently.

This makes reuse much simpler as each user can code his/her application as if it were rooted at /, while actual location (say /app/a) could be determined at deployment time.

b. What Happens in Session Creation

After that client library of ZooKeeper will pick an arbitrary server and further try to connect to it. Until a connection (re-)establishes, the client will automatically try the next server in the list, if this connection fails, or if the client disconnects from the server for any reason.

c. The server creates Session Id

Now, ZooKeeper creates sessions in ZooKeeper, when a client gets a handle on the ZooKeeper service, which is a 64-bit number, and that assigns to the client.

d. Server creates the password and sends it to client

As a part of the connection handshake, the client will send the session id, if the client connects to a different ZooKeeper server. However, the server creates a password for the session id that any ZooKeeper server can validate, as a security measure.

And, when the client establishes the session, the password is sent to the client with the session id. Moreover, with the session id, the client sends this password at the time it reestablishes the session with a new server.

e. Client Specifies Timeout

However, the ZooKeeper session timeout is in milliseconds, as soon as the parameters to the ZooKeeper client library calls to create a ZooKeeper session. Basically, the server responds with the ZooKeeper session Timeout that it can give the client as the client sends a requested timeout.

f. Session Re-establishment

The session will either again transition to the connected state or it will transition to the expired state when connectivity between the client and at least one of the servers is re-established.

g. Session Expiration

Though itself, ZooKeeper cluster manages Session expiration.
In addition, if the ZooKeeper Cluster does not hear (i.e. no heartbeat) within the specified ZooKeeper Sessions Timeout period from the client, expirations happens. As a result, the ZooKeeper Cluster deletes ephemeral nodes of that session by itself. 

However, until/unless it is able to re-establish a connection to the cluster in ZooKeeper, it will not be notified of the session expiration, at this point the client of the expired session is still disconnected from the cluster.

And, until the TCP connection re-establishes with the cluster, the client will stay in the disconnected state. Hence,  at that time the session expired notification will be sent to the watcher.
So, this was all in ZooKeeper sessions. Hope you like our explanation.

Conclusion

Hence, we have seen the whole about Zookeeper Sessions. Though, if any doubt occurs regarding Sessions in ZooKeeper, feel free to ask in the comment tab. We are happy to help!