Database Reference
In-Depth Information
}
}
public static
void
main
(
String
[]
args
)
throws
Exception
{
ConfigWatcher configWatcher
=
new
ConfigWatcher
(
args
[
0
]);
configWatcher
.
displayConfig
();
// stay alive until process is killed or thread is interrupted
Thread
.
sleep
(
Long
.
MAX_VALUE
);
}
}
When the
ConfigUpdater
updates the znode, ZooKeeper causes the watcher to fire
with an event type of
EventType.NodeDataChanged
.
ConfigWatcher
acts on
this event in its
process()
method by reading and displaying the latest version of the
config.
Because watches are one-time signals, we tell ZooKeeper of the new watch each time we
call
read()
on
ActiveKeyValueStore
, which ensures we see future updates. We
are not guaranteed to receive every update, though, because the znode may have been up-
dated (possibly many times) during the span of time between the receipt of the watch
event and the next read, and as the client has no watch registered during that period, it is
not notified. For the configuration service, this is not a problem, because clients care only
about the latest value of a property, as it takes precedence over previous values. However,
in general you should be aware of this potential limitation.
Let's see the code in action. Launch the
ConfigUpdater
in one terminal window:
%
java ConfigUpdater localhost
Set /config to 79
Set /config to 14
Set /config to 78
Then launch the
ConfigWatcher
in another window immediately afterward:
%
java ConfigWatcher localhost
Read /config as 79
Read /config as 14
Read /config as 78
The Resilient ZooKeeper Application
The first of the
Fallacies of Distributed Computing
states that “the network is reliable.” As
they stand, our programs so far have been assuming a reliable network, so when they run
on a real network, they can fail in several ways. Let's examine some possible failure
