http://git-wip-us.apache.org/repos/asf/zookeeper/blob/b024a3e2/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 new file mode 100644 index 0000000..16f7795 --- /dev/null +++ b/zookeeper-docs/src/documentation/content/xdocs/javaExample.xml @@ -0,0 +1,664 @@ +<?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/b024a3e2/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 new file mode 100644 index 0000000..f53536f --- /dev/null +++ b/zookeeper-docs/src/documentation/content/xdocs/recipes.xml @@ -0,0 +1,688 @@ +<?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 -- + src/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 -- + src/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/b024a3e2/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 new file mode 100644 index 0000000..614fa6c --- /dev/null +++ b/zookeeper-docs/src/documentation/content/xdocs/site.xml @@ -0,0 +1,97 @@ +<?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/b024a3e2/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 new file mode 100644 index 0000000..90bbf99 --- /dev/null +++ b/zookeeper-docs/src/documentation/content/xdocs/tabs.xml @@ -0,0 +1,36 @@ +<?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>
