Consider a case where dynamic reload of properties is required. An application can leverage ZooKeeper's service for providing such a capability.
The concept is that of a Publish Subscribe model but spanned across mulitple VMs (either on same machine or different).
The solution is of two folds:
1) First one being a file change listener. This piece of code is responsible for detecting any change and updating the data stored in Zookeeper.
2) Set a watch from the client on this data node being changed.
A quick demo should help clarify the concept.
1) zk-file-change-watcher.jar (executes java class ZkFileChangeWatcher): All it does is creates node in Zookeeper data tree "/CONFIG/DYNAMIC-FILE" if it doesnt exist and sets a watch. If this node changes, ZooKeeper service will notify this client of the change which it takes action (prints to the screen). As seen in screenshot (Denoted by "Waiting for changes" messages in terminal 1 and 2 on L.H.S.)
2) fs-file-change-watcher.jar (executes java class FSFileChangeWatcher): This creates a file listener and checks (polling) every 5 seconds for file changes by checking its timestamp. If the file has changed, it reads data from the file and pushes that change to data node: /CONFIG/DYNAMIC-FILE created by #1. Note when this jar runs for the first time, it doesn't have last updated timestamp, hence it displays message "Last modified timestamp changed" and pushes latest data to the node. Terminal on the R.H.S. displays this execution of this jar.
3) When the file (dynamic-file.txt) changes, both the listeners created in #1 and #2 act accordingly and update is displayed to the clients.
Below screenshot displays just before updating the file (4 is being added to the file) in vi editor. Displayed in bottom left terminal.
Below screenshot confirms the update received at the client in terminals #1 and #2. Terminal on right hand side displays File time stamp change message.
The concept is that of a Publish Subscribe model but spanned across mulitple VMs (either on same machine or different).
The solution is of two folds:
1) First one being a file change listener. This piece of code is responsible for detecting any change and updating the data stored in Zookeeper.
2) Set a watch from the client on this data node being changed.
A quick demo should help clarify the concept.
1) zk-file-change-watcher.jar (executes java class ZkFileChangeWatcher): All it does is creates node in Zookeeper data tree "/CONFIG/DYNAMIC-FILE" if it doesnt exist and sets a watch. If this node changes, ZooKeeper service will notify this client of the change which it takes action (prints to the screen). As seen in screenshot (Denoted by "Waiting for changes" messages in terminal 1 and 2 on L.H.S.)
2) fs-file-change-watcher.jar (executes java class FSFileChangeWatcher): This creates a file listener and checks (polling) every 5 seconds for file changes by checking its timestamp. If the file has changed, it reads data from the file and pushes that change to data node: /CONFIG/DYNAMIC-FILE created by #1. Note when this jar runs for the first time, it doesn't have last updated timestamp, hence it displays message "Last modified timestamp changed" and pushes latest data to the node. Terminal on the R.H.S. displays this execution of this jar.
3) When the file (dynamic-file.txt) changes, both the listeners created in #1 and #2 act accordingly and update is displayed to the clients.
Below screenshot displays just before updating the file (4 is being added to the file) in vi editor. Displayed in bottom left terminal.
Below screenshot confirms the update received at the client in terminals #1 and #2. Terminal on right hand side displays File time stamp change message.
It helped me lot.thanks
ReplyDeleteVideoTrent: YouTube, the world's most entertaining online
ReplyDeleteIn an interview with The Game Project in January of 2016, he youtube mp3 said he was thrilled to take on the