You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@zookeeper.apache.org by an...@apache.org on 2018/11/09 16:41:43 UTC
[06/18] zookeeper git commit: ZOOKEEPER-3155: Remove Forrest XMLs and their build process from the …
http://git-wip-us.apache.org/repos/asf/zookeeper/blob/ab59048a/zookeeper-docs/src/documentation/content/xdocs/index.xml
----------------------------------------------------------------------
diff --git a/zookeeper-docs/src/documentation/content/xdocs/index.xml b/zookeeper-docs/src/documentation/content/xdocs/index.xml
deleted file mode 100644
index 969e482..0000000
--- a/zookeeper-docs/src/documentation/content/xdocs/index.xml
+++ /dev/null
@@ -1,87 +0,0 @@
-<?xml version="1.0"?>
-<!--
- Copyright 2002-2004 The Apache Software Foundation
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" "http://forrest.apache.org/dtd/document-v20.dtd">
-
-<document>
-
- <header>
- <title>ZooKeeper: Because Coordinating Distributed Systems is a Zoo</title>
- </header>
-
- <body>
- <p>ZooKeeper is a high-performance coordination service for
- distributed applications. It exposes common services - such as
- naming, configuration management, synchronization, and group
- services - in a simple interface so you don't have to write them
- from scratch. You can use it off-the-shelf to implement
- consensus, group management, leader election, and presence
- protocols. And you can build on it for your own, specific needs.
- </p>
-
- <p>
- The following documents describe concepts and procedures to get
- you started using ZooKeeper. If you have more questions, please
- ask the <a href="ext:lists">mailing list</a> or browse the
- archives.
- </p>
- <ul>
-
- <li><strong>ZooKeeper Overview</strong><p>Technical Overview Documents for Client Developers, Adminstrators, and Contributors</p>
- <ul><li><a href="zookeeperOver.html">Overview</a> - a bird's eye view of ZooKeeper, including design concepts and architecture</li>
- <li><a href="zookeeperStarted.html">Getting Started</a> - a tutorial-style guide for developers to install, run, and program to ZooKeeper</li>
- <li><a href="ext:relnotes">Release Notes</a> - new developer and user facing features, improvements, and incompatibilities</li>
- </ul>
- </li>
-
- <li><strong>Developers</strong><p> Documents for Developers using the ZooKeeper Client API</p>
- <ul>
- <li><a href="ext:api/index">API Docs</a> - the technical reference to ZooKeeper Client APIs</li>
- <li><a href="zookeeperProgrammers.html">Programmer's Guide</a> - a client application developer's guide to ZooKeeper</li>
- <li><a href="javaExample.html">ZooKeeper Java Example</a> - a simple Zookeeper client appplication, written in Java</li>
- <li><a href="zookeeperTutorial.html">Barrier and Queue Tutorial</a> - sample implementations of barriers and queues</li>
- <li><a href="recipes.html">ZooKeeper Recipes</a> - higher level solutions to common problems in distributed applications</li>
- </ul>
- </li>
-
- <li><strong>Administrators & Operators</strong> <p> Documents for Administrators and Operations Engineers of ZooKeeper Deployments</p>
- <ul>
- <li><a href="zookeeperAdmin.html">Administrator's Guide</a> - a guide for system administrators and anyone else who might deploy ZooKeeper</li>
- <li><a href="zookeeperQuotas.html">Quota Guide</a> - a guide for system administrators on Quotas in ZooKeeper. </li>
- <li><a href="zookeeperJMX.html">JMX</a> - how to enable JMX in ZooKeeper</li>
- <li><a href="zookeeperHierarchicalQuorums.html">Hierarchical quorums</a></li>
- <li><a href="zookeeperObservers.html">Observers</a> - non-voting ensemble members that easily improve ZooKeeper's scalability</li>
- <li><a href="zookeeperReconfig.html">Dynamic Reconfiguration</a> - a guide on how to use dynamic reconfiguration in ZooKeeper</li>
- </ul>
- </li>
-
- <li><strong>Contributors</strong><p> Documents for Developers Contributing to the ZooKeeper Open Source Project</p>
- <ul>
- <li><a href="zookeeperInternals.html">ZooKeeper Internals</a> - assorted topics on the inner workings of ZooKeeper</li>
- </ul>
- </li>
-
- <li><strong>Miscellaneous ZooKeeper Documentation</strong>
- <ul>
- <li><a href="ext:wiki">Wiki</a></li>
- <li><a href="ext:faq">FAQ</a></li>
- </ul>
- </li>
- </ul>
- </body>
-
-</document>
http://git-wip-us.apache.org/repos/asf/zookeeper/blob/ab59048a/zookeeper-docs/src/documentation/content/xdocs/javaExample.xml
----------------------------------------------------------------------
diff --git a/zookeeper-docs/src/documentation/content/xdocs/javaExample.xml b/zookeeper-docs/src/documentation/content/xdocs/javaExample.xml
deleted file mode 100644
index 16f7795..0000000
--- a/zookeeper-docs/src/documentation/content/xdocs/javaExample.xml
+++ /dev/null
@@ -1,664 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!--
- Copyright 2002-2004 The Apache Software Foundation
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!DOCTYPE article PUBLIC "-//OASIS//DTD Simplified DocBook XML V1.0//EN"
-"http://www.oasis-open.org/docbook/xml/simple/1.0/sdocbook.dtd">
-<article id="ar_JavaExample">
- <title>ZooKeeper Java Example</title>
-
- <articleinfo>
- <legalnotice>
- <para>Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License. You may
- obtain a copy of the License at <ulink
- url="http://www.apache.org/licenses/LICENSE-2.0">http://www.apache.org/licenses/LICENSE-2.0</ulink>.</para>
-
- <para>Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an "AS IS"
- BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
- implied. See the License for the specific language governing permissions
- and limitations under the License.</para>
- </legalnotice>
-
- <abstract>
- <para>This article contains sample Java code for a simple watch client.</para>
-
- </abstract>
- </articleinfo>
-
- <section id="ch_Introduction">
- <title>A Simple Watch Client</title>
-
- <para>To introduce you to the ZooKeeper Java API, we develop here a very simple
- watch client. This ZooKeeper client watches a ZooKeeper node for changes
- and responds to by starting or stopping a program.</para>
-
- <section id="sc_requirements"><title>Requirements</title>
-
- <para>The client has four requirements:</para>
-
- <itemizedlist><listitem><para>It takes as parameters:</para>
- <itemizedlist>
- <listitem><para>the address of the ZooKeeper service</para></listitem>
- <listitem><para>the name of a znode - the one to be watched</para></listitem>
- <listitem><para>the name of a file to write the output to</para></listitem>
- <listitem><para>an executable with arguments.</para></listitem></itemizedlist></listitem>
- <listitem><para>It fetches the data associated with the znode and starts the executable.</para></listitem>
- <listitem><para>If the znode changes, the client refetches the contents and restarts the executable.</para></listitem>
- <listitem><para>If the znode disappears, the client kills the executable.</para></listitem></itemizedlist>
-
- </section>
-
- <section id="sc_design">
- <title>Program Design</title>
-
- <para>Conventionally, ZooKeeper applications are broken into two units, one which maintains the connection,
- and the other which monitors data. In this application, the class called the <emphasis role="bold">Executor</emphasis>
- maintains the ZooKeeper connection, and the class called the <emphasis role="bold">DataMonitor</emphasis> monitors the data
- in the ZooKeeper tree. Also, Executor contains the main thread and contains the execution logic.
- It is responsible for what little user interaction there is, as well as interaction with the exectuable program you
- pass in as an argument and which the sample (per the requirements) shuts down and restarts, according to the
- state of the znode.</para>
-
- </section>
-
- </section>
-
- <section id="sc_executor"><title>The Executor Class</title>
- <para>The Executor object is the primary container of the sample application. It contains
- both the <emphasis role="bold">ZooKeeper</emphasis> object, <emphasis role="bold">DataMonitor</emphasis>, as described above in
- <xref linkend="sc_design"/>. </para>
-
- <programlisting>
- // from the Executor class...
-
- public static void main(String[] args) {
- if (args.length < 4) {
- System.err
- .println("USAGE: Executor hostPort znode filename program [args ...]");
- System.exit(2);
- }
- String hostPort = args[0];
- String znode = args[1];
- String filename = args[2];
- String exec[] = new String[args.length - 3];
- System.arraycopy(args, 3, exec, 0, exec.length);
- try {
- new Executor(hostPort, znode, filename, exec).run();
- } catch (Exception e) {
- e.printStackTrace();
- }
- }
-
- public Executor(String hostPort, String znode, String filename,
- String exec[]) throws KeeperException, IOException {
- this.filename = filename;
- this.exec = exec;
- zk = new ZooKeeper(hostPort, 3000, this);
- dm = new DataMonitor(zk, znode, null, this);
- }
-
- public void run() {
- try {
- synchronized (this) {
- while (!dm.dead) {
- wait();
- }
- }
- } catch (InterruptedException e) {
- }
- }
-</programlisting>
-
-
- <para>
- Recall that the Executor's job is to start and stop the executable whose name you pass in on the command line.
- It does this in response to events fired by the ZooKeeper object. As you can see in the code above, the Executor passes
- a reference to itself as the Watcher argument in the ZooKeeper constructor. It also passes a reference to itself
- as DataMonitorListener argument to the DataMonitor constructor. Per the Executor's definition, it implements both these
- interfaces:
- </para>
-
- <programlisting>
-public class Executor implements Watcher, Runnable, DataMonitor.DataMonitorListener {
-...</programlisting>
-
- <para>The <emphasis role="bold">Watcher</emphasis> interface is defined by the ZooKeeper Java API.
- ZooKeeper uses it to communicate back to its container. It supports only one method, <command>process()</command>, and ZooKeeper uses
- it to communciates generic events that the main thread would be intersted in, such as the state of the ZooKeeper connection or the ZooKeeper session.The Executor
- in this example simply forwards those events down to the DataMonitor to decide what to do with them. It does this simply to illustrate
- the point that, by convention, the Executor or some Executor-like object "owns" the ZooKeeper connection, but it is free to delegate the events to other
- events to other objects. It also uses this as the default channel on which to fire watch events. (More on this later.)</para>
-
-<programlisting>
- public void process(WatchedEvent event) {
- dm.process(event);
- }
-</programlisting>
-
- <para>The <emphasis role="bold">DataMonitorListener</emphasis>
- interface, on the other hand, is not part of the the ZooKeeper API. It is a completely custom interface,
- designed for this sample application. The DataMonitor object uses it to communicate back to its container, which
- is also the the Executor object.The DataMonitorListener interface looks like this:</para>
- <programlisting>
-public interface DataMonitorListener {
- /**
- * The existence status of the node has changed.
- */
- void exists(byte data[]);
-
- /**
- * The ZooKeeper session is no longer valid.
- *
- * @param rc
- * the ZooKeeper reason code
- */
- void closing(int rc);
-}
-</programlisting>
- <para>This interface is defined in the DataMonitor class and implemented in the Executor class.
- When <command>Executor.exists()</command> is invoked,
- the Executor decides whether to start up or shut down per the requirements. Recall that the requires say to kill the executable when the
- znode ceases to <emphasis>exist</emphasis>. </para>
-
- <para>When <command>Executor.closing()</command>
- is invoked, the Executor decides whether or not to shut itself down in response to the ZooKeeper connection permanently disappearing.</para>
-
- <para>As you might have guessed, DataMonitor is the object that invokes
- these methods, in response to changes in ZooKeeper's state.</para>
-
- <para>Here are Executor's implementation of
- <command>DataMonitorListener.exists()</command> and <command>DataMonitorListener.closing</command>:
- </para>
- <programlisting>
-public void exists( byte[] data ) {
- if (data == null) {
- if (child != null) {
- System.out.println("Killing process");
- child.destroy();
- try {
- child.waitFor();
- } catch (InterruptedException e) {
- }
- }
- child = null;
- } else {
- if (child != null) {
- System.out.println("Stopping child");
- child.destroy();
- try {
- child.waitFor();
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- }
- try {
- FileOutputStream fos = new FileOutputStream(filename);
- fos.write(data);
- fos.close();
- } catch (IOException e) {
- e.printStackTrace();
- }
- try {
- System.out.println("Starting child");
- child = Runtime.getRuntime().exec(exec);
- new StreamWriter(child.getInputStream(), System.out);
- new StreamWriter(child.getErrorStream(), System.err);
- } catch (IOException e) {
- e.printStackTrace();
- }
- }
-}
-
-public void closing(int rc) {
- synchronized (this) {
- notifyAll();
- }
-}
-</programlisting>
-
-</section>
-<section id="sc_DataMonitor"><title>The DataMonitor Class</title>
-<para>
-The DataMonitor class has the meat of the ZooKeeper logic. It is mostly
-asynchronous and event driven. DataMonitor kicks things off in the constructor with:</para>
-<programlisting>
-public DataMonitor(ZooKeeper zk, String znode, Watcher chainedWatcher,
- DataMonitorListener listener) {
- this.zk = zk;
- this.znode = znode;
- this.chainedWatcher = chainedWatcher;
- this.listener = listener;
-
- // Get things started by checking if the node exists. We are going
- // to be completely event driven
- <emphasis role="bold">zk.exists(znode, true, this, null);</emphasis>
-}
-</programlisting>
-
-<para>The call to <command>ZooKeeper.exists()</command> checks for the existence of the znode,
-sets a watch, and passes a reference to itself (<command>this</command>)
-as the completion callback object. In this sense, it kicks things off, since the
-real processing happens when the watch is triggered.</para>
-
-<note>
-<para>Don't confuse the completion callback with the watch callback. The <command>ZooKeeper.exists()</command>
-completion callback, which happens to be the method <command>StatCallback.processResult()</command> implemented
-in the DataMonitor object, is invoked when the asynchronous <emphasis>setting of the watch</emphasis> operation
-(by <command>ZooKeeper.exists()</command>) completes on the server. </para>
-<para>
-The triggering of the watch, on the other hand, sends an event to the <emphasis>Executor</emphasis> object, since
-the Executor registered as the Watcher of the ZooKeeper object.</para>
-
-<para>As an aside, you might note that the DataMonitor could also register itself as the Watcher
-for this particular watch event. This is new to ZooKeeper 3.0.0 (the support of multiple Watchers). In this
-example, however, DataMonitor does not register as the Watcher.</para>
-</note>
-
-<para>When the <command>ZooKeeper.exists()</command> operation completes on the server, the ZooKeeper API invokes this completion callback on
-the client:</para>
-
-<programlisting>
-public void processResult(int rc, String path, Object ctx, Stat stat) {
- boolean exists;
- switch (rc) {
- case Code.Ok:
- exists = true;
- break;
- case Code.NoNode:
- exists = false;
- break;
- case Code.SessionExpired:
- case Code.NoAuth:
- dead = true;
- listener.closing(rc);
- return;
- default:
- // Retry errors
- zk.exists(znode, true, this, null);
- return;
- }
-
- byte b[] = null;
- if (exists) {
- try {
- <emphasis role="bold">b = zk.getData(znode, false, null);</emphasis>
- } catch (KeeperException e) {
- // We don't need to worry about recovering now. The watch
- // callbacks will kick off any exception handling
- e.printStackTrace();
- } catch (InterruptedException e) {
- return;
- }
- }
- if ((b == null && b != prevData)
- || (b != null && !Arrays.equals(prevData, b))) {
- <emphasis role="bold">listener.exists(b);</emphasis>
- prevData = b;
- }
-}
-</programlisting>
-
-<para>
-The code first checks the error codes for znode existence, fatal errors, and
-recoverable errors. If the file (or znode) exists, it gets the data from the znode, and
-then invoke the exists() callback of Executor if the state has changed. Note,
-it doesn't have to do any Exception processing for the getData call because it
-has watches pending for anything that could cause an error: if the node is deleted
-before it calls <command>ZooKeeper.getData()</command>, the watch event set by
-the <command>ZooKeeper.exists()</command> triggers a callback;
-if there is a communication error, a connection watch event fires when
-the connection comes back up.
-</para>
-
-<para>Finally, notice how DataMonitor processes watch events: </para>
-<programlisting>
- public void process(WatchedEvent event) {
- String path = event.getPath();
- if (event.getType() == Event.EventType.None) {
- // We are are being told that the state of the
- // connection has changed
- switch (event.getState()) {
- case SyncConnected:
- // In this particular example we don't need to do anything
- // here - watches are automatically re-registered with
- // server and any watches triggered while the client was
- // disconnected will be delivered (in order of course)
- break;
- case Expired:
- // It's all over
- dead = true;
- listener.closing(KeeperException.Code.SessionExpired);
- break;
- }
- } else {
- if (path != null && path.equals(znode)) {
- // Something has changed on the node, let's find out
- zk.exists(znode, true, this, null);
- }
- }
- if (chainedWatcher != null) {
- chainedWatcher.process(event);
- }
- }
-</programlisting>
-<para>
-If the client-side ZooKeeper libraries can re-establish the
-communication channel (SyncConnected event) to ZooKeeper before
-session expiration (Expired event) all of the session's watches will
-automatically be re-established with the server (auto-reset of watches
-is new in ZooKeeper 3.0.0). See <ulink
-url="zookeeperProgrammers.html#ch_zkWatches">ZooKeeper Watches</ulink>
-in the programmer guide for more on this. A bit lower down in this
-function, when DataMonitor gets an event for a znode, it calls
-<command>ZooKeeper.exists()</command> to find out what has changed.
-</para>
-</section>
-
-<section id="sc_completeSourceCode">
- <title>Complete Source Listings</title>
- <example id="eg_Executor_java"><title>Executor.java</title><programlisting>
-/**
- * A simple example program to use DataMonitor to start and
- * stop executables based on a znode. The program watches the
- * specified znode and saves the data that corresponds to the
- * znode in the filesystem. It also starts the specified program
- * with the specified arguments when the znode exists and kills
- * the program if the znode goes away.
- */
-import java.io.FileOutputStream;
-import java.io.IOException;
-import java.io.InputStream;
-import java.io.OutputStream;
-
-import org.apache.zookeeper.KeeperException;
-import org.apache.zookeeper.WatchedEvent;
-import org.apache.zookeeper.Watcher;
-import org.apache.zookeeper.ZooKeeper;
-
-public class Executor
- implements Watcher, Runnable, DataMonitor.DataMonitorListener
-{
- String znode;
-
- DataMonitor dm;
-
- ZooKeeper zk;
-
- String filename;
-
- String exec[];
-
- Process child;
-
- public Executor(String hostPort, String znode, String filename,
- String exec[]) throws KeeperException, IOException {
- this.filename = filename;
- this.exec = exec;
- zk = new ZooKeeper(hostPort, 3000, this);
- dm = new DataMonitor(zk, znode, null, this);
- }
-
- /**
- * @param args
- */
- public static void main(String[] args) {
- if (args.length < 4) {
- System.err
- .println("USAGE: Executor hostPort znode filename program [args ...]");
- System.exit(2);
- }
- String hostPort = args[0];
- String znode = args[1];
- String filename = args[2];
- String exec[] = new String[args.length - 3];
- System.arraycopy(args, 3, exec, 0, exec.length);
- try {
- new Executor(hostPort, znode, filename, exec).run();
- } catch (Exception e) {
- e.printStackTrace();
- }
- }
-
- /***************************************************************************
- * We do process any events ourselves, we just need to forward them on.
- *
- * @see org.apache.zookeeper.Watcher#process(org.apache.zookeeper.proto.WatcherEvent)
- */
- public void process(WatchedEvent event) {
- dm.process(event);
- }
-
- public void run() {
- try {
- synchronized (this) {
- while (!dm.dead) {
- wait();
- }
- }
- } catch (InterruptedException e) {
- }
- }
-
- public void closing(int rc) {
- synchronized (this) {
- notifyAll();
- }
- }
-
- static class StreamWriter extends Thread {
- OutputStream os;
-
- InputStream is;
-
- StreamWriter(InputStream is, OutputStream os) {
- this.is = is;
- this.os = os;
- start();
- }
-
- public void run() {
- byte b[] = new byte[80];
- int rc;
- try {
- while ((rc = is.read(b)) > 0) {
- os.write(b, 0, rc);
- }
- } catch (IOException e) {
- }
-
- }
- }
-
- public void exists(byte[] data) {
- if (data == null) {
- if (child != null) {
- System.out.println("Killing process");
- child.destroy();
- try {
- child.waitFor();
- } catch (InterruptedException e) {
- }
- }
- child = null;
- } else {
- if (child != null) {
- System.out.println("Stopping child");
- child.destroy();
- try {
- child.waitFor();
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- }
- try {
- FileOutputStream fos = new FileOutputStream(filename);
- fos.write(data);
- fos.close();
- } catch (IOException e) {
- e.printStackTrace();
- }
- try {
- System.out.println("Starting child");
- child = Runtime.getRuntime().exec(exec);
- new StreamWriter(child.getInputStream(), System.out);
- new StreamWriter(child.getErrorStream(), System.err);
- } catch (IOException e) {
- e.printStackTrace();
- }
- }
- }
-}
-</programlisting>
-
-</example>
-
-<example id="eg_DataMonitor_java">
- <title>DataMonitor.java</title>
- <programlisting>
-/**
- * A simple class that monitors the data and existence of a ZooKeeper
- * node. It uses asynchronous ZooKeeper APIs.
- */
-import java.util.Arrays;
-
-import org.apache.zookeeper.KeeperException;
-import org.apache.zookeeper.WatchedEvent;
-import org.apache.zookeeper.Watcher;
-import org.apache.zookeeper.ZooKeeper;
-import org.apache.zookeeper.AsyncCallback.StatCallback;
-import org.apache.zookeeper.KeeperException.Code;
-import org.apache.zookeeper.data.Stat;
-
-public class DataMonitor implements Watcher, StatCallback {
-
- ZooKeeper zk;
-
- String znode;
-
- Watcher chainedWatcher;
-
- boolean dead;
-
- DataMonitorListener listener;
-
- byte prevData[];
-
- public DataMonitor(ZooKeeper zk, String znode, Watcher chainedWatcher,
- DataMonitorListener listener) {
- this.zk = zk;
- this.znode = znode;
- this.chainedWatcher = chainedWatcher;
- this.listener = listener;
- // Get things started by checking if the node exists. We are going
- // to be completely event driven
- zk.exists(znode, true, this, null);
- }
-
- /**
- * Other classes use the DataMonitor by implementing this method
- */
- public interface DataMonitorListener {
- /**
- * The existence status of the node has changed.
- */
- void exists(byte data[]);
-
- /**
- * The ZooKeeper session is no longer valid.
- *
- * @param rc
- * the ZooKeeper reason code
- */
- void closing(int rc);
- }
-
- public void process(WatchedEvent event) {
- String path = event.getPath();
- if (event.getType() == Event.EventType.None) {
- // We are are being told that the state of the
- // connection has changed
- switch (event.getState()) {
- case SyncConnected:
- // In this particular example we don't need to do anything
- // here - watches are automatically re-registered with
- // server and any watches triggered while the client was
- // disconnected will be delivered (in order of course)
- break;
- case Expired:
- // It's all over
- dead = true;
- listener.closing(KeeperException.Code.SessionExpired);
- break;
- }
- } else {
- if (path != null && path.equals(znode)) {
- // Something has changed on the node, let's find out
- zk.exists(znode, true, this, null);
- }
- }
- if (chainedWatcher != null) {
- chainedWatcher.process(event);
- }
- }
-
- public void processResult(int rc, String path, Object ctx, Stat stat) {
- boolean exists;
- switch (rc) {
- case Code.Ok:
- exists = true;
- break;
- case Code.NoNode:
- exists = false;
- break;
- case Code.SessionExpired:
- case Code.NoAuth:
- dead = true;
- listener.closing(rc);
- return;
- default:
- // Retry errors
- zk.exists(znode, true, this, null);
- return;
- }
-
- byte b[] = null;
- if (exists) {
- try {
- b = zk.getData(znode, false, null);
- } catch (KeeperException e) {
- // We don't need to worry about recovering now. The watch
- // callbacks will kick off any exception handling
- e.printStackTrace();
- } catch (InterruptedException e) {
- return;
- }
- }
- if ((b == null && b != prevData)
- || (b != null && !Arrays.equals(prevData, b))) {
- listener.exists(b);
- prevData = b;
- }
- }
-}
-</programlisting>
-</example>
-</section>
-
-
-
-</article>
http://git-wip-us.apache.org/repos/asf/zookeeper/blob/ab59048a/zookeeper-docs/src/documentation/content/xdocs/recipes.xml
----------------------------------------------------------------------
diff --git a/zookeeper-docs/src/documentation/content/xdocs/recipes.xml b/zookeeper-docs/src/documentation/content/xdocs/recipes.xml
deleted file mode 100644
index 40a31ad..0000000
--- a/zookeeper-docs/src/documentation/content/xdocs/recipes.xml
+++ /dev/null
@@ -1,688 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!--
- Copyright 2002-2004 The Apache Software Foundation
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!DOCTYPE article PUBLIC "-//OASIS//DTD Simplified DocBook XML V1.0//EN"
-"http://www.oasis-open.org/docbook/xml/simple/1.0/sdocbook.dtd">
-<article id="ar_Recipes">
- <title>ZooKeeper Recipes and Solutions</title>
-
- <articleinfo>
- <legalnotice>
- <para>Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License. You may
- obtain a copy of the License at <ulink
- url="http://www.apache.org/licenses/LICENSE-2.0">http://www.apache.org/licenses/LICENSE-2.0</ulink>.</para>
-
- <para>Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an "AS IS"
- BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
- implied. See the License for the specific language governing permissions
- and limitations under the License.</para>
- </legalnotice>
-
- <abstract>
- <para>This guide contains pseudocode and guidelines for using Zookeeper to
- solve common problems in Distributed Application Coordination. It
- discusses such problems as event handlers, queues, and locks..</para>
-
- <para>$Revision: 1.6 $ $Date: 2008/09/19 03:46:18 $</para>
- </abstract>
- </articleinfo>
-
- <section id="ch_recipes">
- <title>A Guide to Creating Higher-level Constructs with ZooKeeper</title>
-
- <para>In this article, you'll find guidelines for using
- ZooKeeper to implement higher order functions. All of them are conventions
- implemented at the client and do not require special support from
- ZooKeeper. Hopfully the community will capture these conventions in client-side libraries
- to ease their use and to encourage standardization.</para>
-
- <para>One of the most interesting things about ZooKeeper is that even
- though ZooKeeper uses <emphasis>asynchronous</emphasis> notifications, you
- can use it to build <emphasis>synchronous</emphasis> consistency
- primitives, such as queues and locks. As you will see, this is possible
- because ZooKeeper imposes an overall order on updates, and has mechanisms
- to expose this ordering.</para>
-
- <para>Note that the recipes below attempt to employ best practices. In
- particular, they avoid polling, timers or anything else that would result
- in a "herd effect", causing bursts of traffic and limiting
- scalability.</para>
-
- <para>There are many useful functions that can be imagined that aren't
- included here - revocable read-write priority locks, as just one example.
- And some of the constructs mentioned here - locks, in particular -
- illustrate certain points, even though you may find other constructs, such
- as event handles or queues, a more practical means of performing the same
- function. In general, the examples in this section are designed to
- stimulate thought.</para>
-
- <section id="sc_recipes_errorHandlingNote">
- <title>Important Note About Error Handling</title>
-
- <para>When implementing the recipes you must handle recoverable exceptions
- (see the <ulink url="https://cwiki.apache.org/confluence/display/ZOOKEEPER/FAQ">FAQ</ulink>). In
- particular, several of the recipes employ sequential ephemeral
- nodes. When creating a sequential ephemeral node there is an error case in
- which the create() succeeds on the server but the server crashes before
- returning the name of the node to the client. When the client reconnects its
- session is still valid and, thus, the node is not removed. The implication is
- that it is difficult for the client to know if its node was created or not. The
- recipes below include measures to handle this.</para>
- </section>
-
- <section id="sc_outOfTheBox">
- <title>Out of the Box Applications: Name Service, Configuration, Group
- Membership</title>
-
- <para>Name service and configuration are two of the primary applications
- of ZooKeeper. These two functions are provided directly by the ZooKeeper
- API.</para>
-
- <para>Another function directly provided by ZooKeeper is <emphasis>group
- membership</emphasis>. The group is represented by a node. Members of the
- group create ephemeral nodes under the group node. Nodes of the members
- that fail abnormally will be removed automatically when ZooKeeper detects
- the failure.</para>
- </section>
-
- <section id="sc_recipes_eventHandles">
- <title>Barriers</title>
-
- <para>Distributed systems use <emphasis>barriers</emphasis>
- to block processing of a set of nodes until a condition is met
- at which time all the nodes are allowed to proceed. Barriers are
- implemented in ZooKeeper by designating a barrier node. The
- barrier is in place if the barrier node exists. Here's the
- pseudo code:</para>
-
- <orderedlist>
- <listitem>
- <para>Client calls the ZooKeeper API's <emphasis
- role="bold">exists()</emphasis> function on the barrier node, with
- <emphasis>watch</emphasis> set to true.</para>
- </listitem>
-
- <listitem>
- <para>If <emphasis role="bold">exists()</emphasis> returns false, the
- barrier is gone and the client proceeds</para>
- </listitem>
-
- <listitem>
- <para>Else, if <emphasis role="bold">exists()</emphasis> returns true,
- the clients wait for a watch event from ZooKeeper for the barrier
- node.</para>
- </listitem>
-
- <listitem>
- <para>When the watch event is triggered, the client reissues the
- <emphasis role="bold">exists( )</emphasis> call, again waiting until
- the barrier node is removed.</para>
- </listitem>
- </orderedlist>
-
- <section id="sc_doubleBarriers">
- <title>Double Barriers</title>
-
- <para>Double barriers enable clients to synchronize the beginning and
- the end of a computation. When enough processes have joined the barrier,
- processes start their computation and leave the barrier once they have
- finished. This recipe shows how to use a ZooKeeper node as a
- barrier.</para>
-
- <para>The pseudo code in this recipe represents the barrier node as
- <emphasis>b</emphasis>. Every client process <emphasis>p</emphasis>
- registers with the barrier node on entry and unregisters when it is
- ready to leave. A node registers with the barrier node via the <emphasis
- role="bold">Enter</emphasis> procedure below, it waits until
- <emphasis>x</emphasis> client process register before proceeding with
- the computation. (The <emphasis>x</emphasis> here is up to you to
- determine for your system.)</para>
-
- <informaltable colsep="0" frame="none" rowsep="0">
- <tgroup cols="2">
- <tbody>
- <row>
- <entry align="center"><emphasis
- role="bold">Enter</emphasis></entry>
-
- <entry align="center"><emphasis
- role="bold">Leave</emphasis></entry>
- </row>
-
- <row>
- <entry align="left"><orderedlist>
- <listitem>
- <para>Create a name <emphasis><emphasis>n</emphasis> =
- <emphasis>b</emphasis>+“/”+<emphasis>p</emphasis></emphasis></para>
- </listitem>
-
- <listitem>
- <para>Set watch: <emphasis
- role="bold">exists(<emphasis>b</emphasis> + ‘‘/ready’’,
- true)</emphasis></para>
- </listitem>
-
- <listitem>
- <para>Create child: <emphasis role="bold">create(
- <emphasis>n</emphasis>, EPHEMERAL)</emphasis></para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">L = getChildren(b,
- false)</emphasis></para>
- </listitem>
-
- <listitem>
- <para>if fewer children in L than<emphasis>
- x</emphasis>, wait for watch event</para>
- </listitem>
-
- <listitem>
- <para>else <emphasis role="bold">create(b + ‘‘/ready’’,
- REGULAR)</emphasis></para>
- </listitem>
- </orderedlist></entry>
-
- <entry><orderedlist>
- <listitem>
- <para><emphasis role="bold">L = getChildren(b,
- false)</emphasis></para>
- </listitem>
-
- <listitem>
- <para>if no children, exit</para>
- </listitem>
-
- <listitem>
- <para>if <emphasis>p</emphasis> is only process node in
- L, delete(n) and exit</para>
- </listitem>
-
- <listitem>
- <para>if <emphasis>p</emphasis> is the lowest process
- node in L, wait on highest process node in L</para>
- </listitem>
-
- <listitem>
- <para>else <emphasis
- role="bold">delete(<emphasis>n</emphasis>) </emphasis>if
- still exists and wait on lowest process node in L</para>
- </listitem>
-
- <listitem>
- <para>goto 1</para>
- </listitem>
- </orderedlist></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- <para>On entering, all processes watch on a ready node and
- create an ephemeral node as a child of the barrier node. Each process
- but the last enters the barrier and waits for the ready node to appear
- at line 5. The process that creates the xth node, the last process, will
- see x nodes in the list of children and create the ready node, waking up
- the other processes. Note that waiting processes wake up only when it is
- time to exit, so waiting is efficient.
- </para>
-
- <para>On exit, you can't use a flag such as <emphasis>ready</emphasis>
- because you are watching for process nodes to go away. By using
- ephemeral nodes, processes that fail after the barrier has been entered
- do not prevent correct processes from finishing. When processes are
- ready to leave, they need to delete their process nodes and wait for all
- other processes to do the same.</para>
-
- <para>Processes exit when there are no process nodes left as children of
- <emphasis>b</emphasis>. However, as an efficiency, you can use the
- lowest process node as the ready flag. All other processes that are
- ready to exit watch for the lowest existing process node to go away, and
- the owner of the lowest process watches for any other process node
- (picking the highest for simplicity) to go away. This means that only a
- single process wakes up on each node deletion except for the last node,
- which wakes up everyone when it is removed.</para>
- </section>
- </section>
-
- <section id="sc_recipes_Queues">
- <title>Queues</title>
-
- <para>Distributed queues are a common data structure. To implement a
- distributed queue in ZooKeeper, first designate a znode to hold the queue,
- the queue node. The distributed clients put something into the queue by
- calling create() with a pathname ending in "queue-", with the
- <emphasis>sequence</emphasis> and <emphasis>ephemeral</emphasis> flags in
- the create() call set to true. Because the <emphasis>sequence</emphasis>
- flag is set, the new pathnames will have the form
- _path-to-queue-node_/queue-X, where X is a monotonic increasing number. A
- client that wants to be removed from the queue calls ZooKeeper's <emphasis
- role="bold">getChildren( )</emphasis> function, with
- <emphasis>watch</emphasis> set to true on the queue node, and begins
- processing nodes with the lowest number. The client does not need to issue
- another <emphasis role="bold">getChildren( )</emphasis> until it exhausts
- the list obtained from the first <emphasis role="bold">getChildren(
- )</emphasis> call. If there are are no children in the queue node, the
- reader waits for a watch notification to check the queue again.</para>
-
- <note>
- <para>There now exists a Queue implementation in ZooKeeper
- recipes directory. This is distributed with the release --
- zookeeper-recipes/zookeeper-recipes-queue directory of the release artifact.
- </para>
- </note>
-
- <section id="sc_recipes_priorityQueues">
- <title>Priority Queues</title>
-
- <para>To implement a priority queue, you need only make two simple
- changes to the generic <ulink url="#sc_recipes_Queues">queue
- recipe</ulink> . First, to add to a queue, the pathname ends with
- "queue-YY" where YY is the priority of the element with lower numbers
- representing higher priority (just like UNIX). Second, when removing
- from the queue, a client uses an up-to-date children list meaning that
- the client will invalidate previously obtained children lists if a watch
- notification triggers for the queue node.</para>
- </section>
- </section>
-
- <section id="sc_recipes_Locks">
- <title>Locks</title>
-
- <para>Fully distributed locks that are globally synchronous, meaning at
- any snapshot in time no two clients think they hold the same lock. These
- can be implemented using ZooKeeeper. As with priority queues, first define
- a lock node.</para>
-
- <note>
- <para>There now exists a Lock implementation in ZooKeeper
- recipes directory. This is distributed with the release --
- zookeeper-recipes/zookeeper-recipes-lock directory of the release artifact.
- </para>
- </note>
-
- <para>Clients wishing to obtain a lock do the following:</para>
-
- <orderedlist>
- <listitem>
- <para>Call <emphasis role="bold">create( )</emphasis> with a pathname
- of "_locknode_/guid-lock-" and the <emphasis>sequence</emphasis> and
- <emphasis>ephemeral</emphasis> flags set. The <emphasis>guid</emphasis>
- is needed in case the create() result is missed. See the note below.</para>
- </listitem>
-
- <listitem>
- <para>Call <emphasis role="bold">getChildren( )</emphasis> on the lock
- node <emphasis>without</emphasis> setting the watch flag (this is
- important to avoid the herd effect).</para>
- </listitem>
-
- <listitem>
- <para>If the pathname created in step <emphasis
- role="bold">1</emphasis> has the lowest sequence number suffix, the
- client has the lock and the client exits the protocol.</para>
- </listitem>
-
- <listitem>
- <para>The client calls <emphasis role="bold">exists( )</emphasis> with
- the watch flag set on the path in the lock directory with the next
- lowest sequence number.</para>
- </listitem>
-
- <listitem>
- <para>if <emphasis role="bold">exists( )</emphasis> returns false, go
- to step <emphasis role="bold">2</emphasis>. Otherwise, wait for a
- notification for the pathname from the previous step before going to
- step <emphasis role="bold">2</emphasis>.</para>
- </listitem>
- </orderedlist>
-
- <para>The unlock protocol is very simple: clients wishing to release a
- lock simply delete the node they created in step 1.</para>
-
- <para>Here are a few things to notice:</para>
-
- <itemizedlist>
- <listitem>
- <para>The removal of a node will only cause one client to wake up
- since each node is watched by exactly one client. In this way, you
- avoid the herd effect.</para>
- </listitem>
- </itemizedlist>
-
- <itemizedlist>
- <listitem>
- <para>There is no polling or timeouts.</para>
- </listitem>
- </itemizedlist>
-
- <itemizedlist>
- <listitem>
- <para>Because of the way you implement locking, it is easy to see the
- amount of lock contention, break locks, debug locking problems,
- etc.</para>
- </listitem>
- </itemizedlist>
-
- <section id="sc_recipes_GuidNote">
- <title>Recoverable Errors and the GUID</title>
- <itemizedlist>
- <listitem>
- <para>If a recoverable error occurs calling <emphasis role="bold">create()</emphasis> the
- client should call <emphasis role="bold">getChildren()</emphasis> and check for a node
- containing the <emphasis>guid</emphasis> used in the path name.
- This handles the case (noted <ulink url="#sc_recipes_errorHandlingNote">above</ulink>) of
- the create() succeeding on the server but the server crashing before returning the name
- of the new node.</para>
- </listitem>
- </itemizedlist>
- </section>
-
- <section>
- <title>Shared Locks</title>
-
- <para>You can implement shared locks by with a few changes to the lock
- protocol:</para>
-
- <informaltable colsep="0" frame="none" rowsep="0">
- <tgroup cols="2">
- <tbody>
- <row>
- <entry align="center"><emphasis role="bold">Obtaining a read
- lock:</emphasis></entry>
-
- <entry align="center"><emphasis role="bold">Obtaining a write
- lock:</emphasis></entry>
- </row>
-
- <row>
- <entry align="left"><orderedlist>
- <listitem>
- <para>Call <emphasis role="bold">create( )</emphasis> to
- create a node with pathname
- "<filename>guid-/read-</filename>". This is the
- lock node use later in the protocol. Make sure to set both
- the <emphasis>sequence</emphasis> and
- <emphasis>ephemeral</emphasis> flags.</para>
- </listitem>
-
- <listitem>
- <para>Call <emphasis role="bold">getChildren( )</emphasis>
- on the lock node <emphasis>without</emphasis> setting the
- <emphasis>watch</emphasis> flag - this is important, as it
- avoids the herd effect.</para>
- </listitem>
-
- <listitem>
- <para>If there are no children with a pathname starting
- with "<filename>write-</filename>" and having a lower
- sequence number than the node created in step <emphasis
- role="bold">1</emphasis>, the client has the lock and can
- exit the protocol. </para>
- </listitem>
-
- <listitem>
- <para>Otherwise, call <emphasis role="bold">exists(
- )</emphasis>, with <emphasis>watch</emphasis> flag, set on
- the node in lock directory with pathname staring with
- "<filename>write-</filename>" having the next lowest
- sequence number.</para>
- </listitem>
-
- <listitem>
- <para>If <emphasis role="bold">exists( )</emphasis>
- returns <emphasis>false</emphasis>, goto step <emphasis
- role="bold">2</emphasis>.</para>
- </listitem>
-
- <listitem>
- <para>Otherwise, wait for a notification for the pathname
- from the previous step before going to step <emphasis
- role="bold">2</emphasis></para>
- </listitem>
- </orderedlist></entry>
-
- <entry><orderedlist>
- <listitem>
- <para>Call <emphasis role="bold">create( )</emphasis> to
- create a node with pathname
- "<filename>guid-/write-</filename>". This is the
- lock node spoken of later in the protocol. Make sure to
- set both <emphasis>sequence</emphasis> and
- <emphasis>ephemeral</emphasis> flags.</para>
- </listitem>
-
- <listitem>
- <para>Call <emphasis role="bold">getChildren( )
- </emphasis> on the lock node <emphasis>without</emphasis>
- setting the <emphasis>watch</emphasis> flag - this is
- important, as it avoids the herd effect.</para>
- </listitem>
-
- <listitem>
- <para>If there are no children with a lower sequence
- number than the node created in step <emphasis
- role="bold">1</emphasis>, the client has the lock and the
- client exits the protocol.</para>
- </listitem>
-
- <listitem>
- <para>Call <emphasis role="bold">exists( ),</emphasis>
- with <emphasis>watch</emphasis> flag set, on the node with
- the pathname that has the next lowest sequence
- number.</para>
- </listitem>
-
- <listitem>
- <para>If <emphasis role="bold">exists( )</emphasis>
- returns <emphasis>false</emphasis>, goto step <emphasis
- role="bold">2</emphasis>. Otherwise, wait for a
- notification for the pathname from the previous step
- before going to step <emphasis
- role="bold">2</emphasis>.</para>
- </listitem>
- </orderedlist></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
-
- <para>Notes:</para>
-
- <itemizedlist>
- <listitem>
- <para>It might appear that this recipe creates a herd effect:
- when there is a large group of clients waiting for a read
- lock, and all getting notified more or less simultaneously
- when the "<filename>write-</filename>" node with the lowest
- sequence number is deleted. In fact. that's valid behavior:
- as all those waiting reader clients should be released since
- they have the lock. The herd effect refers to releasing a
- "herd" when in fact only a single or a small number of
- machines can proceed.</para>
- </listitem>
- </itemizedlist>
-
- <itemizedlist>
- <listitem>
- <para>See the <ulink url="#sc_recipes_GuidNote">note for Locks</ulink> on how to use the guid in the node.</para>
- </listitem>
- </itemizedlist>
-
- </section>
-
- <section id="sc_revocableSharedLocks">
- <title>Revocable Shared Locks</title>
-
- <para>With minor modifications to the Shared Lock protocol, you make
- shared locks revocable by modifying the shared lock protocol:</para>
-
- <para>In step <emphasis role="bold">1</emphasis>, of both obtain reader
- and writer lock protocols, call <emphasis role="bold">getData(
- )</emphasis> with <emphasis>watch</emphasis> set, immediately after the
- call to <emphasis role="bold">create( )</emphasis>. If the client
- subsequently receives notification for the node it created in step
- <emphasis role="bold">1</emphasis>, it does another <emphasis
- role="bold">getData( )</emphasis> on that node, with
- <emphasis>watch</emphasis> set and looks for the string "unlock", which
- signals to the client that it must release the lock. This is because,
- according to this shared lock protocol, you can request the client with
- the lock give up the lock by calling <emphasis role="bold">setData()
- </emphasis> on the lock node, writing "unlock" to that node.</para>
-
- <para>Note that this protocol requires the lock holder to consent to
- releasing the lock. Such consent is important, especially if the lock
- holder needs to do some processing before releasing the lock. Of course
- you can always implement <emphasis>Revocable Shared Locks with Freaking
- Laser Beams</emphasis> by stipulating in your protocol that the revoker
- is allowed to delete the lock node if after some length of time the lock
- isn't deleted by the lock holder.</para>
- </section>
- </section>
-
- <section id="sc_recipes_twoPhasedCommit">
- <title>Two-phased Commit</title>
-
- <para>A two-phase commit protocol is an algorithm that lets all clients in
- a distributed system agree either to commit a transaction or abort.</para>
-
- <para>In ZooKeeper, you can implement a two-phased commit by having a
- coordinator create a transaction node, say "/app/Tx", and one child node
- per participating site, say "/app/Tx/s_i". When coordinator creates the
- child node, it leaves the content undefined. Once each site involved in
- the transaction receives the transaction from the coordinator, the site
- reads each child node and sets a watch. Each site then processes the query
- and votes "commit" or "abort" by writing to its respective node. Once the
- write completes, the other sites are notified, and as soon as all sites
- have all votes, they can decide either "abort" or "commit". Note that a
- node can decide "abort" earlier if some site votes for "abort".</para>
-
- <para>An interesting aspect of this implementation is that the only role
- of the coordinator is to decide upon the group of sites, to create the
- ZooKeeper nodes, and to propagate the transaction to the corresponding
- sites. In fact, even propagating the transaction can be done through
- ZooKeeper by writing it in the transaction node.</para>
-
- <para>There are two important drawbacks of the approach described above.
- One is the message complexity, which is O(n²). The second is the
- impossibility of detecting failures of sites through ephemeral nodes. To
- detect the failure of a site using ephemeral nodes, it is necessary that
- the site create the node.</para>
-
- <para>To solve the first problem, you can have only the coordinator
- notified of changes to the transaction nodes, and then notify the sites
- once coordinator reaches a decision. Note that this approach is scalable,
- but it's is slower too, as it requires all communication to go through the
- coordinator.</para>
-
- <para>To address the second problem, you can have the coordinator
- propagate the transaction to the sites, and have each site creating its
- own ephemeral node.</para>
- </section>
-
- <section id="sc_leaderElection">
- <title>Leader Election</title>
-
- <para>A simple way of doing leader election with ZooKeeper is to use the
- <emphasis role="bold">SEQUENCE|EPHEMERAL</emphasis> flags when creating
- znodes that represent "proposals" of clients. The idea is to have a znode,
- say "/election", such that each znode creates a child znode "/election/guid-n_"
- with both flags SEQUENCE|EPHEMERAL. With the sequence flag, ZooKeeper
- automatically appends a sequence number that is greater than any one
- previously appended to a child of "/election". The process that created
- the znode with the smallest appended sequence number is the leader.
- </para>
-
- <para>That's not all, though. It is important to watch for failures of the
- leader, so that a new client arises as the new leader in the case the
- current leader fails. A trivial solution is to have all application
- processes watching upon the current smallest znode, and checking if they
- are the new leader when the smallest znode goes away (note that the
- smallest znode will go away if the leader fails because the node is
- ephemeral). But this causes a herd effect: upon a failure of the current
- leader, all other processes receive a notification, and execute
- getChildren on "/election" to obtain the current list of children of
- "/election". If the number of clients is large, it causes a spike on the
- number of operations that ZooKeeper servers have to process. To avoid the
- herd effect, it is sufficient to watch for the next znode down on the
- sequence of znodes. If a client receives a notification that the znode it
- is watching is gone, then it becomes the new leader in the case that there
- is no smaller znode. Note that this avoids the herd effect by not having
- all clients watching the same znode. </para>
-
- <para>Here's the pseudo code:</para>
-
- <para>Let ELECTION be a path of choice of the application. To volunteer to
- be a leader: </para>
-
- <orderedlist>
- <listitem>
- <para>Create znode z with path "ELECTION/guid-n_" with both SEQUENCE and
- EPHEMERAL flags;</para>
- </listitem>
-
- <listitem>
- <para>Let C be the children of "ELECTION", and i be the sequence
- number of z;</para>
- </listitem>
-
- <listitem>
- <para>Watch for changes on "ELECTION/guid-n_j", where j is the largest
- sequence number such that j < i and n_j is a znode in C;</para>
- </listitem>
- </orderedlist>
-
- <para>Upon receiving a notification of znode deletion: </para>
-
- <orderedlist>
- <listitem>
- <para>Let C be the new set of children of ELECTION; </para>
- </listitem>
-
- <listitem>
- <para>If z is the smallest node in C, then execute leader
- procedure;</para>
- </listitem>
-
- <listitem>
- <para>Otherwise, watch for changes on "ELECTION/guid-n_j", where j is the
- largest sequence number such that j < i and n_j is a znode in C;
- </para>
- </listitem>
- </orderedlist>
-
- <para>Notes:</para>
-
- <itemizedlist>
- <listitem>
- <para>Note that the znode having no preceding znode on the list of
- children does not imply that the creator of this znode is aware that it is
- the current leader. Applications may consider creating a separate znode
- to acknowledge that the leader has executed the leader procedure. </para>
- </listitem>
- </itemizedlist>
-
- <itemizedlist>
- <listitem>
- <para>See the <ulink url="#sc_recipes_GuidNote">note for Locks</ulink> on how to use the guid in the node.</para>
- </listitem>
- </itemizedlist>
-
- </section>
- </section>
-</article>
http://git-wip-us.apache.org/repos/asf/zookeeper/blob/ab59048a/zookeeper-docs/src/documentation/content/xdocs/site.xml
----------------------------------------------------------------------
diff --git a/zookeeper-docs/src/documentation/content/xdocs/site.xml b/zookeeper-docs/src/documentation/content/xdocs/site.xml
deleted file mode 100644
index 614fa6c..0000000
--- a/zookeeper-docs/src/documentation/content/xdocs/site.xml
+++ /dev/null
@@ -1,97 +0,0 @@
-<?xml version="1.0"?>
-<!--
- Copyright 2002-2004 The Apache Software Foundation
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!--
-Forrest site.xml
-
-This file contains an outline of the site's information content. It is used to:
-- Generate the website menus (though these can be overridden - see docs)
-- Provide semantic, location-independent aliases for internal 'site:' URIs, eg
-<link href="site:changes"> links to changes.html (or ../changes.html if in
- subdir).
-- Provide aliases for external URLs in the external-refs section. Eg, <link
- href="ext:cocoon"> links to http://xml.apache.org/cocoon/
-
-See http://forrest.apache.org/docs/linking.html for more info.
--->
-
-<site label="ZooKeeper" href="" xmlns="http://apache.org/forrest/linkmap/1.0">
-
- <docs label="Overview">
- <welcome label="Welcome" href="index.html" />
- <overview label="Overview" href="zookeeperOver.html" />
- <started label="Getting Started" href="zookeeperStarted.html" />
- <relnotes label="Release Notes" href="ext:relnotes" />
- </docs>
-
- <docs label="Developer">
- <api label="API Docs" href="ext:api/index" />
- <program label="Programmer's Guide" href="zookeeperProgrammers.html" />
- <javaEx label="Java Example" href="javaExample.html" />
- <barTutor label="Barrier and Queue Tutorial" href="zookeeperTutorial.html" />
- <recipes label="Recipes" href="recipes.html" />
- </docs>
-
- <docs label="Admin & Ops">
- <admin label="Administrator's Guide" href="zookeeperAdmin.html" />
- <quota label="Quota Guide" href="zookeeperQuotas.html" />
- <jmx label="JMX" href="zookeeperJMX.html" />
- <observers label="Observers Guide" href="zookeeperObservers.html" />
- <reconfig label="Dynamic Reconfiguration" href="zookeeperReconfig.html" />
- </docs>
-
- <docs label="Contributor">
- <internals label="ZooKeeper Internals" href="zookeeperInternals.html" />
- </docs>
-
- <docs label="Miscellaneous">
- <wiki label="Wiki" href="ext:wiki" />
- <faq label="FAQ" href="ext:faq" />
- <lists label="Mailing Lists" href="ext:lists" />
- <!--<other label="Other Info" href="zookeeperOtherInfo.html" />-->
- </docs>
-
-
-
- <external-refs>
- <site href="http://zookeeper.apache.org/"/>
- <lists href="http://zookeeper.apache.org/mailing_lists.html"/>
- <releases href="http://zookeeper.apache.org/releases.html">
- <download href="#Download" />
- </releases>
- <jira href="http://zookeeper.apache.org/issue_tracking.html"/>
- <wiki href="https://cwiki.apache.org/confluence/display/ZOOKEEPER" />
- <faq href="https://cwiki.apache.org/confluence/display/ZOOKEEPER/FAQ" />
- <zlib href="http://www.zlib.net/" />
- <lzo href="http://www.oberhumer.com/opensource/lzo/" />
- <gzip href="http://www.gzip.org/" />
- <cygwin href="http://www.cygwin.com/" />
- <osx href="http://www.apple.com/macosx" />
- <relnotes href="releasenotes.html" />
- <api href="api/">
- <started href="overview-summary.html#overview_description" />
- <index href="index.html" />
- <org href="org/">
- <apache href="apache/">
- <zookeeper href="zookeeper/">
- </zookeeper>
- </apache>
- </org>
- </api>
- </external-refs>
-
-</site>
http://git-wip-us.apache.org/repos/asf/zookeeper/blob/ab59048a/zookeeper-docs/src/documentation/content/xdocs/tabs.xml
----------------------------------------------------------------------
diff --git a/zookeeper-docs/src/documentation/content/xdocs/tabs.xml b/zookeeper-docs/src/documentation/content/xdocs/tabs.xml
deleted file mode 100644
index 90bbf99..0000000
--- a/zookeeper-docs/src/documentation/content/xdocs/tabs.xml
+++ /dev/null
@@ -1,36 +0,0 @@
-<?xml version="1.0"?>
-<!--
- Copyright 2002-2004 The Apache Software Foundation
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<!DOCTYPE tabs PUBLIC "-//APACHE//DTD Cocoon Documentation Tab V1.0//EN"
- "http://forrest.apache.org/dtd/tab-cocoon-v10.dtd">
-
-<tabs software="ZooKeeper"
- title="ZooKeeper"
- copyright="The Apache Software Foundation"
- xmlns:xlink="http://www.w3.org/1999/xlink">
-
- <!-- The rules are:
- @dir will always have /index.html added.
- @href is not modified unless it is root-relative and obviously specifies a
- directory (ends in '/'), in which case /index.html will be added
- -->
-
- <tab label="Project" href="http://zookeeper.apache.org/" />
- <tab label="Wiki" href="https://cwiki.apache.org/confluence/display/ZOOKEEPER/" />
- <tab label="ZooKeeper 3.5 Documentation" dir="" />
-
-</tabs>