Zookeeper Missing Events/miss event

Today on the statistics page found a node is missing, after careful analysis, found two applications on the same node (while monitoring ZK) one of the missing an event, check ZK cluster not found abnormal ...

Through the network search, the occurrence of Miss event is said to be listening before there is node, delete only register, so this is normal phenomenon.

Troubleshoot network problems, because I believe that when ZK is notified event, there is an abnormal hint.

Java code

2. Cat/path/to/log/file | grep nodechildrenchanged
6. 2013-05-: £ º[Main-eventthread] (Zookeepermonitor.java:158) WARN xxx. zookeepermonitor-nodechildrenchanged,reloading data with event:watchedevent state:syncconnected type: nodechildrenchanged path:/node/svr
8. 2013-05-31 02:< Span class= "number" >30:23,906 [main-eventthread]  ( Zookeepermonitor.java:158)  warn  xxx. zookeepermonitor - nodechildrenchanged,reloading data with event:watchedevent  state:syncconnected type:nodechildrenchanged path:/node/svr  
10. 2013-05- : +:179 [Main-eventthread] (Zookeepermonitor.java:158) WARN xxx. zookeepermonitor-nodechildrenchanged,reloading data with event:watchedevent state:syncconnected type: nodechildrenchanged path:/node/svr
14. Compared to other normal applications, the last one is missing an event.

forced to resist or bite the bullet and find the next, found the answer is as follows:------------finally quoted Xu Wang as an article explaining the Genesis-------------

All zookeeper read operations, including GetData (), GetChildren (), and exists (), have a switch that allows you to set a watch at the same time as the operation. In zookeeper, watch is a one-time trigger that is sent to the client setting watch when the data of the watch is set to change. There are three key points in the definition of watch :

• Disposable Trigger

  A watch event will be sent to the client when the data changes. For example, if the client performs an action GetData ("/znode1″, true"), and then/znode1 changes or deletes, the client will get a/znode1 watch event. If the/znode1 is changed again, the client is no longer sent a watch event if the client does not have a new watch set.

• sent to client

• was set to watch data

  this Refers to the different ways in which nodes change. You can assume that zookeeper maintains a list of two watch lists: Data watch and child watch. GetData () and exists () Set data Watch, and GetChildren () sets child watch. Or, you can think of watch as being set according to the return value. GetData () and exists () return the information for the node itself, and GetChildren () returns a list of child nodes. Therefore, setData () triggers the data watch set on the Znode (if set succeeds). A successful  create () operation triggers the data watch on the created Znode, as well as child watch on its parent node. A successful  delete () operation will trigger both the Znode data watch and the child watch (because there is no subnodes), and it will also trigger the parent of the children watch.

Watch is maintained locally by the zookeeper server on the client connection. This reduces the overhead of setting up, maintaining, and distributing watch. When a client connects to a new server, watch will be triggered at any session event. Watch cannot be received when it loses connection with a server. When the client is reconnected, all previously registered watch will be re-registered, if necessary. Usually this is completely transparent. Watch may be lost only in one special case: For an znode exist watch that is not created, the Watch event may be lost if it was created during a client disconnection and then deleted before the client connection.  

What protection does zookeeper offer to watch?

These guarantees are provided for Watch,zookeeper:

• Watch and other events, other watch, and asynchronous replies are all ordered. The Zookeeper client library guarantees that all events are distributed sequentially.

• The client will ensure that it receives the watch event before it sees the new data for the corresponding znode. This ensures that the data is present when the process () again uses the ZK client access

• The sequence of watch events received from zookeeper must be consistent with the sequence of events seen by the zookeeper service.

Some notable things about watch

• Watch is a one-time trigger, and if you get a watch event and you want to continue to be notified of future changes, you should set up a watch.

• < P style= "line-height:15px; Text-align:left; padding:0px; margin:0px; " > Because watch is a one-time trigger, and getting events to send a new set of Watch requests this process will have a delay, so you can't make sure you see all the events that occur on a node in zookeeper. So please handle this situation where multiple znode changes may occur in this time window. ( You can not handle it, but at least recognize it). That is, if the process is slow and no new watch is registered, there will be no notification when there are other events appearing in the process ()!! It may be that you didn't realize it before, so it leads to this topic ***********

• A Watch object or a function/context pair that is only notified once for an event. For example, if the same watch object is registered two times on the same file by exists and GetData, and the file is deleted, the Watch object will only receive a deletion notification of the file. //The same watch registers the same node multiple times only generates an event. Here I thought, if a watch registers a different node, should there be more than one event?

• When you disconnect from a server (such as a server failure), you will not be able to get any watch until you connect again. Use these session events to enter Safe mode: you will not receive events in the disconnected state, so your program should be cautious during this time.

Zookeeper Missing Events/miss event