ZooKeeper Watches – Features & Guarantees
Keeping you updated with latest technology trends, Join DataFlair on Telegram
In our last ZooKeeper tutorial, we discussed ZooKeeper Locks. Also, there are various guarantees, with regard to watches in ZooKeeper, we will discuss them as well. However, along with this, it guarantees there are some important points about ZooKeeper Watches, we will also discuss them in detail.
So, let’s start ZooKeeper Watches.
2. What is ZooKeeper Watches?
In ZooKeeper, all of the read operations – getData(), getChildren(), and exists() – have the option of setting a watch as a side effect. Defining ZooKeeper Watches, when the data for which the watch was set changes, a watch event (one-time trigger), sent to the client which set the watch. However, in this definition of a watch, there are three key points to consider, such as:
Do you know about ZooKeeper Data Models
a. One-time trigger
When any change occurs in data, one watch event will be sent to the client. Let’s say the client will get a watch event for /znode1 if a client does a getData(“/znode1”, true) and later the data for /znode1 is changed or deleted. However, it will not send any watch event unless the client performs another read which sets a new watch, if /znode1 changes again.
b. Sent to the client
It simply means that an event is on the way to the client. However, it may not reach the client somehow, before the successful return code to the change operation reaches the client which initiated the change. Asynchronously, ZooKeeper Watches send to ZooKeeper watchers. Also, a client will never see a change for which it has set a watch until it first sees the watch event, this is an ordering guarantee offered by ZooKeeper.
However, sometimes, the network may delay or also other factors may cause different clients to see watches and further return codes from updates at different times. Though we can say, different clients will have a consistent order is the key point of it.
c. The data for which the watch was set
It says in different ways we can change a node. Basically, that makes us think of ZooKeeper as maintaining two lists of watches. Those are Data ZooKeeper Watches and Child ZooKeeper Watches. To set data watches, getData() and exists() and to set child watches, getChildren().
However, both getData() and exists() gets the information about the node’s data. And, getChildren() gets the list of children. Hence, successful setData() will trigger data watches to set the ZNode.
Locally, ZooKeeper servers which are connected to the client maintain the watches. Though it permits in order to set watches they are must lightweight. Moreover, the watch will trigger for any session events, when a client connects to a new server. However, while disconnected from a server, watches will not receive.
But at the time when the client reconnects, any previously registered watches will trigger as well as reregistered as per requirement. Also, we can say this all occurs transparently. Moreover, the watch can also be missed if the Znode is created and deleted while disconnected, then a watch for the existence of a ZNode not yet created will be missed.
Let’s revise ZooKeeper Barriers
3. What ZooKeeper Guarantees about Watches?
ZooKeeper maintains various guarantees, with regard to watches:
- Basically, with respect to other events, other watches, and asynchronous replies, watches get in order. In addition, the ZooKeeper client libraries ensure that if everything gets dispatch in order or not.
- Before seeing the new data that corresponds to that znode, a client will see a watch event for a znode it is watching.
- ZooKeeper Watch events order corresponds to the order of the updates as seen by the ZooKeeper service.
4. Things to Remember about Watches
- We must set another watch if we get a watch event and we want to get notified of future changes. It is because watches are one time triggers.
- Though, it is not possible for us to reliably see every change that happens to a node in ZooKeeper. It is due to latency between getting the event as well as sending a new request to get a watch. And also because watches are one time triggers. So, where the ZNode changes multiple times between getting the event and setting the watch again, just prepare yourself to handle the case.
- For a given notification, a watch object, or function/context pair, will only trigger once.
- Moreover, we will not get any watches until the reestablishment of connection, while we disconnect from a server.
So, this was all in Zookeeper Watches. Hope you like our explanation.
Hence, in this ZooKeeper watches tutorial, we have seen the whole about ZooKeeper Watches along with its features and important points. However, if any doubt occurs regarding ZooKeeper Watches, feel free to ask in the comment section.
See also –
ZooKeeper CLI Command