diff options
| author | Tamas Penzes <tamaas@cloudera.com> | 2018-10-05 15:04:21 +0200 |
|---|---|---|
| committer | Andor Molnar <andor@apache.org> | 2018-10-05 15:04:21 +0200 |
| commit | 74c245b4c01bf282b121286260525dde97037206 (patch) | |
| tree | 9b0495a81bcabe82f093d344311c390b4049063a | |
| parent | 7b25a70787d1ffb6e6c4bf0389cfcb3734be0bb1 (diff) | |
| download | zookeeper-74c245b4c01bf282b121286260525dde97037206.tar.gz | |
ZOOKEEPER-3153: Create MarkDown files and build process for them for …
…branch 3.4
In this sub-task we have transformed the Forest XML documents into MarkDown (.md) files and provided a (maven based) solution to create HTML documentation from them.
PDF support is dropped since it is not really used and makes everything overcomplicated.
The generated HTML content looks similar to the one generated from Forest XMLs, but not identical with them.
Change-Id: Id35984eca5d37b9e3074eab939be5c9b4cc80257
Author: Tamas Penzes <tamaas@cloudera.com>
Reviewers: andor@apache.org
Closes #645 from tamaashu/ZOOKEEPER-3153-3.4
53 files changed, 9348 insertions, 0 deletions
diff --git a/pom.xml b/pom.xml new file mode 100755 index 000000000..e8745fd1c --- /dev/null +++ b/pom.xml @@ -0,0 +1,236 @@ +<?xml version="1.0" encoding="UTF-8"?> +<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> +<!-- +/** + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you 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. + */ +--> + <modelVersion>4.0.0</modelVersion> + <parent> + <groupId>org.apache</groupId> + <artifactId>apache</artifactId> + <version>18</version> + <relativePath/> + <!-- no parent resolution --> + </parent> + <groupId>org.apache.zookeeper</groupId> + <artifactId>zookeeper</artifactId> + <packaging>pom</packaging> + <version>3.4.14-SNAPSHOT</version> + <name>Apache ZooKeeper</name> + <description> + ZooKeeper is a centralized service for maintaining configuration information, naming, + providing distributed synchronization, and providing group services. All of these kinds + of services are used in some form or another by distributed applications. Each time they + are implemented there is a lot of work that goes into fixing the bugs and race conditions + that are inevitable. Because of the difficulty of implementing these kinds of services, + applications initially usually skimp on them ,which make them brittle in the presence of + change and difficult to manage. Even when done correctly, different implementations of + these services lead to management complexity when the applications are deployed. + </description> + <url>http://zookeeper.apache.org</url> + <inceptionYear>2008</inceptionYear> + <!-- Set here so we can consistently use the correct name, even on branches with + an ASF parent pom older than v15. Also uses the url from v18. + --> + <licenses> + <license> + <name>Apache License, Version 2.0</name> + <url>https://www.apache.org/licenses/LICENSE-2.0.txt</url> + <distribution>repo</distribution> + </license> + </licenses> + + <modules> + <module>zookeeper-docs</module> + </modules> + <scm> + <connection>scm:git:git://git.apache.org/zookeeper.git</connection> + <developerConnection>scm:git:https://git-wip-us.apache.org/repos/asf/zookeeper.git</developerConnection> + <url>https://git-wip-us.apache.org/repos/asf?p=zookeeper.git</url> + </scm> + <issueManagement> + <system>JIRA</system> + <url>http://issues.apache.org/jira/browse/ZOOKEEPER</url> + </issueManagement> + <ciManagement> + <system>hudson</system> + <url>http://hudson.zones.apache.org/hudson/view/ZooKeeper/job/ZooKeeper-TRUNK/</url> + </ciManagement> + <mailingLists> + <mailingList> + <name>User List</name> + <subscribe>user-subscribe@zookeeper.apache.org</subscribe> + <unsubscribe>user-unsubscribe@zookeeper.apache.org</unsubscribe> + <post>user@zookeeper.apache.org</post> + <archive>http://mail-archives.apache.org/mod_mbox/zookeeper-user/</archive> + </mailingList> + <mailingList> + <name>Developer List</name> + <subscribe>dev-subscribe@zookeeper.apache.org</subscribe> + <unsubscribe>dev-unsubscribe@zookeeper.apache.org</unsubscribe> + <post>dev@zookeeper.apache.org</post> + <archive>http://mail-archives.apache.org/mod_mbox/zookeeper-dev/</archive> + </mailingList> + <mailingList> + <name>Commits List</name> + <subscribe>commits-subscribe@zookeeper.apache.org</subscribe> + <unsubscribe>commits-unsubscribe@zookeeper.apache.org</unsubscribe> + <archive>http://mail-archives.apache.org/mod_mbox/zookeeper-commits/</archive> + </mailingList> + <mailingList> + <name>Issues List</name> + <subscribe>issues-subscribe@zookeeper.apache.org</subscribe> + <unsubscribe>issues-unsubscribe@zookeeper.apache.org</unsubscribe> + <archive>http://mail-archives.apache.org/mod_mbox/zookeeper-issues/</archive> + </mailingList> + <mailingList> + <name>Builds List</name> + <subscribe>builds-subscribe@zookeeper.apache.org</subscribe> + <unsubscribe>builds-unsubscribe@zookeeper.apache.org</unsubscribe> + <archive>http://mail-archives.apache.org/mod_mbox/zookeeper-builds/</archive> + </mailingList> + </mailingLists> + <developers> + <developer> + <id>tdunning</id> + <name>Ted Dunning </name> + <email>tdunning@apache.org</email> + <timezone>-8</timezone> + </developer> + <developer> + <id>camille</id> + <name>Camille Fournier</name> + <email>camille@apache.org</email> + <timezone>-5</timezone> + </developer> + <developer> + <id>phunt</id> + <name>Patrick Hunt</name> + <email>phunt@apache.org</email> + <timezone>-8</timezone> + </developer> + <developer> + <id>fpj</id> + <name>Flavio Junqueira</name> + <email>fpj@apache.org</email> + <timezone>+0</timezone> + </developer> + <developer> + <id>ivank</id> + <name>Ivan Kelly</name> + <email>ivank@apache.org</email> + <timezone>+2</timezone> + </developer> + <developer> + <id>mahadev</id> + <name>Mahadev Konar</name> + <email>mahadev@apache.org</email> + <timezone>-8</timezone> + </developer> + <developer> + <id>michim</id> + <name>Michi Mutsuzaki</name> + <email>michim@apache.org</email> + <timezone>-8</timezone> + </developer> + <developer> + <id>cnauroth</id> + <name>Chris Nauroth</name> + <email>cnauroth@apache.org</email> + <timezone>-8</timezone> + </developer> + <developer> + <id>breed</id> + <name>Benjamin Reed</name> + <email>breed@apache.org</email> + <timezone>-8</timezone> + </developer> + <developer> + <id>henry</id> + <name>Henry Robinson</name> + <email>henry@apache.org</email> + <timezone>-8</timezone> + </developer> + <developer> + <id>rgs</id> + <name>Raul Gutierrez Segales</name> + <email>rgs@apache.org</email> + <timezone>-8</timezone> + </developer> + <developer> + <id>rakeshr</id> + <name>Rakesh Radhakrishnan</name> + <email>rakeshr@apache.org</email> + <timezone>+5:30</timezone> + </developer> + <developer> + <id>hanm</id> + <name>Michael Han</name> + <email>hanm@apache.org</email> + <timezone>-8</timezone> + </developer> + <developer> + <id>gkesavan</id> + <name>Giridharan Kesavan</name> + <email>gkesavan@apache.org</email> + <timezone>-8</timezone> + </developer> + <developer> + <id>akornev</id> + <name>Andrew Kornev</name> + <email>akornev@apache.org</email> + </developer> + <developer> + <id>shralex</id> + <name>Alex Shraer</name> + <email>shralex@apache.org</email> + <timezone>-8</timezone> + </developer> + <developer> + <id>thawan</id> + <name>Thawan Kooburat</name> + <email>thawan@apache.org</email> + <timezone>-8</timezone> + </developer> + <developer> + <id>hdeng</id> + <name>Hongchao Deng</name> + <email>hdeng@apache.org</email> + <timezone>-8</timezone> + </developer> + <developer> + <id>arshad</id> + <name>Mohammad Arshad</name> + <email>arshad@apache.org</email> + <timezone>+5:30</timezone> + </developer> + <developer> + <id>afine</id> + <name>Abraham Fine</name> + <email>afine@apache.org</email> + <timezone>-8</timezone> + </developer> + <developer> + <id>andor</id> + <name>Andor Molnar</name> + <email>andor@apache.org</email> + <timezone>+1</timezone> + </developer> + </developers> + +</project> diff --git a/zookeeper-docs/pom.xml b/zookeeper-docs/pom.xml new file mode 100644 index 000000000..220e62724 --- /dev/null +++ b/zookeeper-docs/pom.xml @@ -0,0 +1,61 @@ +<?xml version="1.0"?> +<project xmlns="http://maven.apache.org/POM/4.0.0" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> + <!-- + /** + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you 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. + */ + --> + <modelVersion>4.0.0</modelVersion> + <parent> + <groupId>org.apache.zookeeper</groupId> + <artifactId>zookeeper</artifactId> + <version>3.4.14-SNAPSHOT</version> + <relativePath>..</relativePath> + </parent> + + <groupId>org.apache.zookeeper</groupId> + <artifactId>zookeeper-docs</artifactId> + <version>3.4.14-SNAPSHOT</version> + <name>Apache ZooKeeper - Documentation</name> + <description>Documentation</description> + + <build> + <plugins> + <plugin> + <groupId>com.ruleoftech</groupId> + <artifactId>markdown-page-generator-plugin</artifactId> + <version>0.10</version> + <executions> + <execution> + <phase>process-sources</phase> + <goals> + <goal>generate</goal> + </goals> + </execution> + </executions> + <configuration> + <headerHtmlFile>${project.basedir}/src/main/resources/markdown/html/header.html</headerHtmlFile> + <footerHtmlFile>${project.basedir}/src/main/resources/markdown/html/footer.html</footerHtmlFile> + <copyDirectories>images,skin</copyDirectories> + </configuration> + </plugin> + </plugins> + </build> + +</project>
\ No newline at end of file diff --git a/zookeeper-docs/src/main/resources/markdown/bookkeeperConfig.md b/zookeeper-docs/src/main/resources/markdown/bookkeeperConfig.md new file mode 100644 index 000000000..f153fa19e --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/bookkeeperConfig.md @@ -0,0 +1,79 @@ +<!-- +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. +//--> + +#BookKeeper Administrator's Guide +###Setup Guide +* [Deployment](#bk_deployment) + * [System requirements](#bk_sysReq) + * [Running bookies](#bk_runningBookies) + * [ZooKeeper Metadata](#bk_zkMetadata) + +<a name="bk_deployment"></a> + +##Deployment +This section contains information about deploying BookKeeper and +covers these topics:</p> + +* [System requirements](#bk_sysReq) +* [Running bookies](#bk_runningBookies) +* [ZooKeeper Metadata](#bk_zkMetadata) + +The first section tells you how many machines you need. The second explains how to bootstrap bookies +(BookKeeper storage servers). The third section explains how we use ZooKeeper and our requirements with +respect to ZooKeeper. + +<a name="bk_sysReq"></a> + +###System requirements +A typical BookKeeper installation comprises a set of bookies and a set of ZooKeeper replicas. The exact number of bookies +depends on the quorum mode, desired throughput, and number of clients using this installation simultaneously. The minimum number of +bookies is three for self-verifying (stores a message authentication code along with each entry) and four for generic (does not +store a message authentication codewith each entry), and there is no upper limit on the number of bookies. Increasing the number of +bookies, in fact, enables higher throughput. + +For performance, we require each server to have at least two disks. It is possible to run a bookie with a single disk, but +performance will be significantly lower in this case. Of course, it works with one disk, but performance is significantly lower. + +For ZooKeeper, there is no constraint with respect to the number of replicas. Having a single machine running ZooKeeper +in standalone mode is sufficient for BookKeeper. For resilience purposes, it might be a good idea to run ZooKeeper in quorum +mode with multiple servers. Please refer to the ZooKeeper documentation for detail on how to configure ZooKeeper with multiple +replicas + +<a name="bk_runningBookies"></a> + +###Running bookies +To run a bookie, we execute the following command: + + java -cp .:./zookeeper-<version>-bookkeeper.jar:./zookeeper-<version>.jar\ + :../log4j/apache-log4j-1.2.15/log4j-1.2.15.jar -Dlog4j.configuration=log4j.properties\ + org.apache.bookkeeper.proto.BookieServer 3181 127.0.0.1:2181 /path_to_log_device/\ + /path_to_ledger_device/ + +The parameters are: + +* Port number that the bookie listens on; +* Comma separated list of ZooKeeper servers with a hostname:port format; +* Path for Log Device (stores bookie write-ahead log); +* Path for Ledger Device (stores ledger entries); + +Ideally, `/path_to_log_device/` and `/path_to_ledger_device/` are each in a different device. + +<a name="bk_zkMetadata"></a> + +###ZooKeeper Metadata +For BookKeeper, we require a ZooKeeper installation to store metadata, and to pass the list +of ZooKeeper servers as parameter to the constructor of the BookKeeper class (`org.apache.bookkeeper.client,BookKeeper`). +To setup ZooKeeper, please check the [ZooKeeper documentation](index.html) diff --git a/zookeeper-docs/src/main/resources/markdown/bookkeeperOverview.md b/zookeeper-docs/src/main/resources/markdown/bookkeeperOverview.md new file mode 100644 index 000000000..d6f62c928 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/bookkeeperOverview.md @@ -0,0 +1,185 @@ +<!-- +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. +//--> + +#BookKeeper overview + +* [BookKeeper overview](#bk_Overview) + * [BookKeeper introduction](#bk_Intro) + * [In slightly more detail...](#bk_moreDetail) + * [Bookkeeper elements and concept](#bk_basicComponents) + * [Bookkeeper initial design](#bk_initialDesign) + * [Bookkeeper metadata management](#bk_metadata) + * [Closing out ledgers](#bk_closingOut) + +<a name="bk_Overview"></a> + +##BookKeeper overview + +<a name="bk_Intro"></a> +###BookKeeper introduction +BookKeeper is a replicated service to reliably log streams of records. In BookKeeper, +servers are "bookies", log streams are "ledgers", and each unit of a log (aka record) is a +"ledger entry". BookKeeper is designed to be reliable; bookies, the servers that store +ledgers, can crash, corrupt data, discard data, but as long as there are enough bookies +behaving correctly the service as a whole behaves correctly. + +The initial motivation for BookKeeper comes from the namenode of HDFS. Namenodes have to +log operations in a reliable fashion so that recovery is possible in the case of crashes. +We have found the applications for BookKeeper extend far beyond HDFS, however. Essentially, +any application that requires an append storage can replace their implementations with +BookKeeper. BookKeeper has the advantage of scaling throughput with the number of servers. + +At a high level, a bookkeeper client receives entries from a client application and stores it to +sets of bookies, and there are a few advantages in having such a service: + +* We can use hardware that is optimized for such a service. We currently believe that such a system has to be optimized only for disk I/O; +* We can have a pool of servers implementing such a log system, and shared among a number of servers; +* We can have a higher degree of replication with such a pool, which makes sense if the hardware necessary for it is cheaper compared to the one the application uses. + +<a name="bk_moreDetail"></a> + +###In slightly more detail... +BookKeeper implements highly available logs, and it has been designed with write-ahead logging in mind. Besides high availability +due to the replicated nature of the service, it provides high throughput due to striping. As we write entries in a subset of bookies of an +ensemble and rotate writes across available quorums, we are able to increase throughput with the number of servers for both reads and writes. +Scalability is a property that is possible to achieve in this case due to the use of quorums. Other replication techniques, such as +state-machine replication, do not enable such a property. + +An application first creates a ledger before writing to bookies through a local BookKeeper client instance. +Upon creating a ledger, a BookKeeper client writes metadata about the ledger to ZooKeeper. Each ledger currently +has a single writer. This writer has to execute a close ledger operation before any other client can read from it. +If the writer of a ledger does not close a ledger properly because, for example, it has crashed before having the +opportunity of closing the ledger, then the next client that tries to open a ledger executes a procedure to recover +it. As closing a ledger consists essentially of writing the last entry written to a ledger to ZooKeeper, the recovery +procedure simply finds the last entry written correctly and writes it to ZooKeeper. + +Note that currently this recovery procedure is executed automatically upon trying to open a ledger and no explicit action is necessary. +Although two clients may try to recover a ledger concurrently, only one will succeed, the first one that is able to create the close znode +for the ledger. + +<a name="bk_basicComponents"></a> + +###Bookkeeper elements and concepts +BookKeeper uses four basic elements: + +* **Ledger**: A ledger is a sequence of entries, and each entry is a sequence of bytes. Entries are +written sequentially to a ledger and at most once. Consequently, ledgers have an append-only semantics; +* **BookKeeper client**: A client runs along with a BookKeeper application, and it enables applications +to execute operations on ledgers, such as creating a ledger and writing to it; +* **Bookie**: A bookie is a BookKeeper storage server. Bookies store the content of ledgers. For any given +ledger L, we call an <em>ensemble</em> the group of bookies storing the content of L. For performance, we store on +each bookie of an ensemble only a fragment of a ledger. That is, we stripe when writing entries to a ledger such that +each entry is written to sub-group of bookies of the ensemble. +* **Metadata storage service**: BookKeeper requires a metadata storage service to store information related +to ledgers and available bookies. We currently use ZooKeeper for such a task. + +<a name="bk_initialDesign"></a> + +###Bookkeeper initial design +A set of bookies implements BookKeeper, and we use a quorum-based protocol to replicate data across the bookies. +There are basically two operations to an existing ledger: read and append. Here is the complete API list +(mode detail [here](bookkeeperProgrammer.html)): + +* Create ledger: creates a new empty ledger; +* Open ledger: opens an existing ledger for reading; +* Add entry: adds a record to a ledger either synchronously or asynchronously; +* Read entries: reads a sequence of entries from a ledger either synchronously or asynchronously + +There is only a single client that can write to a ledger. Once that ledger is closed or the client fails, +no more entries can be added. (We take advantage of this behavior to provide our strong guarantees.) +There will not be gaps in the ledger. Fingers get broken, people get roughed up or end up in prison when +books are manipulated, so there is no deleting or changing of entries. + + + +A simple use of BooKeeper is to implement a write-ahead transaction log. A server maintains an in-memory data structure +(with periodic snapshots for example) and logs changes to that structure before it applies the change. The application +server creates a ledger at startup and store the ledger id and password in a well known place (ZooKeeper maybe). When +it needs to make a change, the server adds an entry with the change information to a ledger and apply the change when +BookKeeper adds the entry successfully. The server can even use asyncAddEntry to queue up many changes for high change +throughput. BooKeeper meticulously logs the changes in order and call the completion functions in order. + +When the application server dies, a backup server will come online, get the last snapshot and then it will open the +ledger of the old server and read all the entries from the time the snapshot was taken. (Since it doesn't know the +last entry number it will use MAX_INTEGER). Once all the entries have been processed, it will close the ledger and +start a new one for its use. + +A client library takes care of communicating with bookies and managing entry numbers. An entry has the following fields: + +#####Entry fields +| Field | Type | Description | +|---------------|------|------------------------------------| +| Ledger number | long | The id of the ledger of this entry | +| Entry number | long | The id of this entry | +| last confirmed (<em>LC</em>) | long | id of the last recorded entry | +| data | byte[] | the entry data (supplied by application) | +| authentication code | byte[] | Message authentication code that includes all other fields of the entry | + +The client library generates a ledger entry. None of the fields are modified by the bookies and only the first three +fields are interpreted by the bookies. + +To add to a ledger, the client generates the entry above using the ledger number. The entry number will be one more +than the last entry generated. The <em>LC</em> field contains the last entry that has been successfully recorded by BookKeeper. +If the client writes entries one at a time, <em>LC</em> is the last entry id. But, if the client is using asyncAddEntry, there +may be many entries in flight. An entry is considered recorded when both of the following conditions are met: + +* the entry has been accepted by a quorum of bookies +* all entries with a lower entry id have been accepted by a quorum of bookies + +<em>LC</em> seems mysterious right now, but it is too early to explain how we use it; just smile and move on. + +Once all the other fields have been field in, the client generates an authentication code with all of the previous fields. +The entry is then sent to a quorum of bookies to be recorded. Any failures will result in the entry being sent to a new +quorum of bookies. + +To read, the client library initially contacts a bookie and starts requesting entries. If an entry is missing or +invalid (a bad MAC for example), the client will make a request to a different bookie. By using quorum writes, +as long as enough bookies are up we are guaranteed to eventually be able to read an entry. + +<a name="bk_metadata"></a> + +###Bookkeeper metadata management +There are some meta data that needs to be made available to BookKeeper clients: + +* The available bookies; +* The list of ledgers; +* The list of bookies that have been used for a given ledger; +* The last entry of a ledger; + +We maintain this information in ZooKeeper. Bookies use ephemeral nodes to indicate their availability. Clients +use znodes to track ledger creation and deletion and also to know the end of the ledger and the bookies that +were used to store the ledger. Bookies also watch the ledger list so that they can cleanup ledgers that get deleted. + +<a name="bk_closingOut"></a> + +###Closing out ledgers +The process of closing out the ledger and finding the last ledger is difficult due to the durability guarantees of BookKeeper: +* If an entry has been successfully recorded, it must be readable. +* If an entry is read once, it must always be available to be read. + +If the ledger was closed gracefully, ZooKeeper will have the last entry and everything will work well. But, if the +BookKeeper client that was writing the ledger dies, there is some recovery that needs to take place. + +The problematic entries are the ones at the end of the ledger. There can be entries in flight when a BookKeeper client +dies. If the entry only gets to one bookie, the entry should not be readable since the entry will disappear if that bookie +fails. If the entry is only on one bookie, that doesn't mean that the entry has not been recorded successfully; the other +bookies that recorded the entry might have failed. + +The trick to making everything work is to have a correct idea of a last entry. We do it in roughly three steps: + +* Find the entry with the highest last recorded entry, <em>LC</em>; +* Find the highest consecutively recorded entry, <em>LR</em>; +* Make sure that all entries between <em>LC</em> and <em>LR</em> are on a quorum of bookies; diff --git a/zookeeper-docs/src/main/resources/markdown/bookkeeperProgrammer.md b/zookeeper-docs/src/main/resources/markdown/bookkeeperProgrammer.md new file mode 100644 index 000000000..014429959 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/bookkeeperProgrammer.md @@ -0,0 +1,299 @@ +<!-- +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. +//--> + +#BookKeeper Getting Started Guide + +* [Programming with BookKeeper](#bk_GettingStarted) + * [Instantiating BookKeeper](#bk_instance) + * [Creating a ledger](#bk_createLedger) + * [Adding entries to a ledger](#bk_writeLedger) + * [Closing a ledger](#bk_closeLedger) + * [Opening a ledger](#bk_openLedger) + * [Reading from ledger](#bk_readLedger) + * [Deleting a ledger](#bk_deleteLedger) + +<a name="bk_GettingStarted"></a> + +##Programming with BookKeeper + +* [Instantiating BookKeeper](#bk_instance) +* [Creating a ledger](#bk_createLedger) +* [Adding entries to a ledger](#bk_writeLedger) +* [Closing a ledger](#bk_closeLedger) +* [Opening a ledger](#bk_openLedger) +* [Reading from ledger](#bk_readLedger) +* [Deleting a ledger](#bk_deleteLedger) + +<a name="bk_instance"></a> + +###Instantiating BookKeeper +The first step to use BookKeeper is to instantiate a BookKeeper object: + + org.apache.bookkeeper.BookKeeper + +There are three BookKeeper constructors: + + public BookKeeper(String servers) + throws KeeperException, IOException + +where: + +* `servers` is a comma-separated list of ZooKeeper servers. + + + public BookKeeper(ZooKeeper zk) + throws InterruptedException, KeeperException + +where: + +* `zk` is a ZooKeeper object. This constructor is useful when +the application also using ZooKeeper and wants to have a single instance of ZooKeeper. + + + public BookKeeper(ZooKeeper zk, ClientSocketChannelFactory channelFactory) + throws InterruptedException, KeeperException + +where: + +* `zk` is a ZooKeeper object. This constructor is useful when +the application also using ZooKeeper and wants to have a single instance of ZooKeeper. +* `channelFactory` is a netty channel object (`org.jboss.netty.channel.socket`). + +<a name="bk_createLedger"></a> + +###Creating a ledger + +Before writing entries to BookKeeper, it is necessary to create a ledger. +With the current BookKeeper API, it is possible to create a ledger both synchronously +or asynchronously. The following methods belong +to `org.apache.bookkeeper.client.BookKeeper`. + +**Synchronous call:** + + public LedgerHandle createLedger(int ensSize, int qSize, DigestType type, byte passwd[]) + throws KeeperException, InterruptedException, + IOException, BKException + +where: + +* `ensSize` is the number of bookies (ensemble size); +* `qSize` is the write quorum size; +* `type` is the type of digest used with entries: either MAC or CRC32. +* `passwd` is a password that authorizes the client to write to the +ledger being created. + +All further operations on a ledger are invoked through the `LedgerHandle` +object returned. + +As a convenience, we provide a `createLedger` with default parameters (3,2,VERIFIABLE), +and the only two input parameters it requires are a digest type and a password. + +**Asynchronous call:** + + public void asyncCreateLedger(int ensSize, + int qSize, + DigestType type, + byte passwd[], + CreateCallback cb, + Object ctx + ) + +The parameters are the same of the synchronous version, with the +exception of `cb` and `ctx`. `CreateCallback` is an interface in +`org.apache.bookkeeper.client.AsyncCallback`, and a class implementing +it has to implement a method called `createComplete` that has the following signature: + + void createComplete(int rc, LedgerHandle lh, Object ctx); + +where: + +* `rc` is a return code (please refer to `org.apache.bookeeper.client.BKException` for a list); +* `lh` is a `LedgerHandle` object to manipulate a ledger; +* `ctx` is a control object for accountability purposes. It can be essentially any object the application is happy with. + +The `ctx` object passed as a parameter to the call to create a ledger +is the one same returned in the callback. + +<a name="bk_writeLedger"></a> + +###Adding entries to a ledger + +Once we have a ledger handle `lh` obtained through a call to create a ledger, we +can start writing entries. As with creating ledgers, we can write both synchronously and +asynchronously. The following methods belong +to `org.apache.bookkeeper.client.LedgerHandle`. + +**Synchronous call:** + + public long addEntry(byte[] data) + throws InterruptedException + +where: + +* `data` is a byte array; + +A call to `addEntry` returns the status of the operation (please refer to `org.apache.bookeeper.client.BKDefs` for a list); + +**Asynchronous call:** + + public void asyncAddEntry(byte[] data, AddCallback cb, Object ctx) + +It also takes a byte array as the sequence of bytes to be stored as an entry. Additionaly, it takes +a callback object `cb` and a control object `ctx`. The callback object must implement +the `AddCallback` interface in `org.apache.bookkeeper.client.AsyncCallback`, and +a class implementing it has to implement a method called `addComplete` +that has the following signature: + + void addComplete(int rc, LedgerHandle lh, long entryId, Object ctx); + +where: + +* `rc` is a return code (please refer to `org.apache.bookeeper.client.BKDefs` for a list); +* `lh` is a `LedgerHandle` object to manipulate a ledger; +* `entryId` is the identifier of entry associated with this request; +* `ctx` is control object used for accountability purposes. It can be any object the application is happy with. + +<a name="bk_closeLedger"></a> + +###Closing a ledger + + +Once a client is done writing, it closes the ledger. The following methods belong +to `org.apache.bookkeeper.client.LedgerHandle`. + +**Synchronous close:** + + public void close() + throws InterruptedException + +It takes no input parameters. + +**Asynchronous close:** + + public void asyncClose(CloseCallback cb, Object ctx) + throws InterruptedException + +It takes a callback object `cb` and a control object `ctx`. The callback object must implement +the `CloseCallback` interface in `org.apache.bookkeeper.client.AsyncCallback`, and +a class implementing it has to implement a method called `closeComplete` +that has the following signature: + + void closeComplete(int rc, LedgerHandle lh, Object ctx) + +where: + +* `rc` is a return code (please refer to `org.apache.bookeeper.client.BKDefs` for a list); +* `lh` is a `LedgerHandle` object to manipulate a ledger; +* `ctx` is control object used for accountability purposes. + +<a name="bk_openLedger"></a> + +###Opening a ledger + +To read from a ledger, a client must open it first. The following methods belong +to `org.apache.bookkeeper.client.BookKeeper`. + +**Synchronous open:** + + public LedgerHandle openLedger(long lId, DigestType type, byte passwd[]) + throws InterruptedException, BKException + +* `ledgerId` is the ledger identifier; +* `type` is the type of digest used with entries: either MAC or CRC32. +* `passwd` is a password to access the ledger (used only in the case of `VERIFIABLE` ledgers); + +**Asynchronous open:** + + public void asyncOpenLedger(long lId, DigestType type, byte passwd[], OpenCallback cb, Object ctx) + +It also takes a a ledger identifier and a password. Additionaly, it takes a callback object +`cb` and a control object `ctx`. The callback object must implement +the `OpenCallback` interface in `org.apache.bookkeeper.client.AsyncCallback`, and +a class implementing it has to implement a method called `openComplete` +that has the following signature: + + public void openComplete(int rc, LedgerHandle lh, Object ctx) + +where: + +* `rc` is a return code (please refer to `org.apache.bookeeper.client.BKDefs` for a list); +* `lh` is a `LedgerHandle` object to manipulate a ledger; +* `ctx` is control object used for accountability purposes. + +<a name="bk_readLedger"></a> + +###Reading from ledger + +Read calls may request one or more consecutive entries. The following methods belong +to `org.apache.bookkeeper.client.LedgerHandle`. + +**Synchronous read:** + + public Enumeration<LedgerEntry> readEntries(long firstEntry, long lastEntry) + throws InterruptedException, BKException + +* `firstEntry` is the identifier of the first entry in the sequence of entries to read; +* `lastEntry` is the identifier of the last entry in the sequence of entries to read. + +**Asynchronous read:** + + public void asyncReadEntries(long firstEntry, long lastEntry, ReadCallback cb, Object ctx) + throws BKException, InterruptedException + +It also takes a first and a last entry identifiers. Additionaly, it takes a callback object +`cb` and a control object `ctx`. The callback object must implement +the `ReadCallback` interface in `org.apache.bookkeeper.client.AsyncCallback`, and +a class implementing it has to implement a method called `readComplete` +that has the following signature: + + void readComplete(int rc, LedgerHandle lh, Enumeration<LedgerEntry> seq, Object ctx) + +where: + +* `rc` is a return code (please refer to `org.apache.bookeeper.client.BKDefs` for a list); +* `lh` is a `LedgerHandle` object to manipulate a ledger; +* `seq` is a `Enumeration<LedgerEntry> ` object to containing the list of entries requested; +* `ctx` is control object used for accountability purposes. + +<a name="bk_deleteLedger"></a> + +###Deleting a ledger + +Once a client is done with a ledger and is sure that nobody will ever need to read from it again, they can delete the ledger. +The following methods belong to `org.apache.bookkeeper.client.BookKeeper`. + +**Synchronous delete:** + + public void deleteLedger(long lId) throws InterruptedException, BKException + +* `lId` is the ledger identifier; + +**Asynchronous delete:** + + public void asyncDeleteLedger(long lId, DeleteCallback cb, Object ctx) + +It takes a ledger identifier. Additionally, it takes a callback object +`cb` and a control object `ctx`. The callback object must implement +the `DeleteCallback` interface in `org.apache.bookkeeper.client.AsyncCallback`, and +a class implementing it has to implement a method called `deleteComplete` +that has the following signature: + + void deleteComplete(int rc, Object ctx) + +where: + +* `rc` is a return code (please refer to `org.apache.bookeeper.client.BKDefs` for a list); +* `ctx` is control object used for accountability purposes. diff --git a/zookeeper-docs/src/main/resources/markdown/bookkeeperStarted.md b/zookeeper-docs/src/main/resources/markdown/bookkeeperStarted.md new file mode 100644 index 000000000..1cbb33b06 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/bookkeeperStarted.md @@ -0,0 +1,125 @@ +<!-- +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. +//--> + +#BookKeeper Getting Started Guide + +* [Getting Started: Setting up BookKeeper to write logs.](#bk_GettingStarted) + * [Pre-requisites](#bk_Prerequisites) + * [Download](#bk_Download) + * [LocalBookKeeper](#bk_localBK) + * [Setting up bookies](#bk_setupBookies) + * [Setting up ZooKeeper](#bk_setupZK) + * [Example](#bk_example) + +<a name="bk_GettingStarted"></a> + +##Getting Started: Setting up BookKeeper to write logs. +This document contains information to get you started quickly with +BookKeeper. It is aimed primarily at developers willing to try it out, and +contains simple installation instructions for a simple BookKeeper installation +and a simple programming example. For further programming detail, please refer to +[BookKeeper Programmer's Guide](bookkeeperProgrammer.html). + +<a name="bk_Prerequisites"></a> + +###Pre-requisites +See [System Requirements](bookkeeperConfig.html#bk_sysReq) in the Admin guide. + +<a name="bk_Download"></a> + +###Download +BookKeeper is distributed along with ZooKeeper. To get a ZooKeeper distribution, +download a recent [stable](http://zookeeper.apache.org/releases.html) +release from one of the Apache Download Mirrors. + +<a name="bk_localBK"></a> + +###LocalBookKeeper +Under `org.apache.bookkeeper.util`, you'll find a java program +called LocalBookKeeper.java that sets you up to run BookKeeper on a +single machine. This is far from ideal from a performance perspective, +but the program is useful for both test and educational purposes. + +<a name="bk_setupBookies"></a> + +###Setting up bookies +If you're bold and you want more than just running things locally, then +you'll need to run bookies in different servers. You'll need at least three bookies +to start with. + +For each bookie, we need to execute a command like the following: + + java -cp .:./zookeeper-<version>-bookkeeper.jar:./zookeeper-<version>.jar\ + :lib/slf4j-api-1.6.1.jar:lib/slf4j-log4j12-1.6.1.jar:lib/log4j-1.2.15.jar -Dlog4j.configuration=log4j.properties\ + org.apache.bookkeeper.proto.BookieServer 3181 127.0.0.1:2181 /path_to_log_device/\ + /path_to_ledger_device/ + + +"/path_to_log_device/" and "/path_to_ledger_device/" are different paths. Also, port 3181 +is the port that a bookie listens on for connection requests from clients. 127.0.0.1:2181 is the hostname:port +for the ZooKeeper server. In this example, the standalone ZooKeeper server is running locally on port 2181. +If we had multiple ZooKeeper servers, this parameter would be a comma separated list of all the hostname:port +values corresponding to them. + +<a name="bk_setupZK"></a> + +###Setting up ZooKeeper +ZooKeeper stores metadata on behalf of BookKeeper clients and bookies. To get a minimal +ZooKeeper installation to work with BookKeeper, we can set up one server running in +standalone mode. Once we have the server running, we need to create a few znodes: + +1. `/ledgers` +1. `/ledgers/available` +1. For each bookie, we add one znode such that the name of the znode is the + concatenation of the machine name and the port number that the bookie is + listening on. For example, if a bookie is running on bookie.foo.com an is listening + on port 3181, we add a znode `/ledgers/available/bookie.foo.com:3181`. + +<a name="bk_example"></a> + +###Example +In the following excerpt of code, we: + +1. Create a ledger; +1. Write to the ledger; +1. Close the ledger; +1. Open the same ledger for reading; +1. Read from the ledger; +1. Close the ledger again; + + + LedgerHandle lh = bkc.createLedger(ledgerPassword); + ledgerId = lh.getId(); + ByteBuffer entry = ByteBuffer.allocate(4); + + for(int i = 0; i < 10; i++){ + entry.putInt(i); + entry.position(0); + entries.add(entry.array()); + lh.addEntry(entry.array()); + } + lh.close(); + lh = bkc.openLedger(ledgerId, ledgerPassword); + + Enumeration<LedgerEntry> ls = lh.readEntries(0, 9); + int i = 0; + while(ls.hasMoreElements()){ + ByteBuffer origbb = ByteBuffer.wrap(entries.get(i++)); + Integer origEntry = origbb.getInt(); + ByteBuffer result = ByteBuffer.wrap(ls.nextElement().getEntry()); + Integer retrEntry = result.getInt(); + } + lh.close(); diff --git a/zookeeper-docs/src/main/resources/markdown/bookkeeperStream.md b/zookeeper-docs/src/main/resources/markdown/bookkeeperStream.md new file mode 100644 index 000000000..e1e6a3870 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/bookkeeperStream.md @@ -0,0 +1,142 @@ +<!-- +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. +//--> + +#Streaming with BookKeeper + +* [Summary](#bk_StreamSummary) +* [Writing a stream of bytes](#bk_LedgerOutputStream) +* [Reading a stream of bytes](#bk_LedgerInputStream) + +<a name="bk_StreamSummary"></a> + +##Summary + +When using the BookKeeper API, an application has to split the data to write into entries, each +entry being a byte array. This is natural for many applications. For example, when using BookKeeper +for write-ahead logging, an application typically wants to write the modifications corresponding +to a command or a transaction. Some other applications, however, might not have a natural boundary +for entries, and may prefer to write and read streams of bytes. This is exactly the purpose of the +stream API we have implemented on top of BookKeeper. + +The stream API is implemented in the package `Streaming`, and it contains two main classes: +`LedgerOutputStream` and `LedgerInputStream`. The class names are indicative of what they do. + +<a name="bk_LedgerOutputStream"></a> + +##Writing a stream of bytes + +Class `LedgerOutputStream` implements two constructors and five public methods: + + public LedgerOutputStream(LedgerHandle lh) + +where: `lh` is a ledger handle for a previously created and open ledger. + + public LedgerOutputStream(LedgerHandle lh, int size) + +where: + +* `lh` is a ledger handle for a previously created and open ledger. +* `size` is the size of the byte buffer to store written bytes before flushing. + +**Closing a stream.** This call closes the stream by flushing the write buffer. + + public void close() + +which has no parameters. + +**Flushing a stream.** This call essentially flushes the write buffer. + + public synchronized void flush() + +which has no parameters. + +**Writing bytes.** There are three calls for writing bytes to a stream. + + public synchronized void write(byte[] b) + +where: + +* `b` is an array of bytes to write. + + + public synchronized void write(byte[] b, int off, int len) + +where: + +* `b` is an array of bytes to write. +* `off` is a buffer offset. +* `len` is the length to write. + + + public synchronized void write(int b) + +where: + +* `b` contains a byte to write. The method writes the least significant byte of the integer four bytes. + +<a name="bk_LedgerInputStream"></a> + +##Reading a stream of bytes + +Class `LedgerOutputStream` implements two constructors and four public methods: + + public LedgerInputStream(LedgerHandle lh) + throws BKException, InterruptedException + +where: + +* `lh` is a ledger handle for a previously created and open ledger. + + + public LedgerInputStream(LedgerHandle lh, int size) + throws BKException, InterruptedException + +where: + +* `lh` is a ledger handle for a previously created and open ledger. +* `size` is the size of the byte buffer to store bytes that the application will eventually read. + +**Closing.** There is one call to close an input stream, but the call +is currently empty and the application is responsible for closing the ledger handle. + + public void close() + +which has no parameters. + +**Reading.** There are three calls to read from the stream. + + public synchronized int read() + throws IOException + +which has no parameters. + + + public synchronized int read(byte[] b) + throws IOException + +where: + +* `b` is a byte array to write to. + + + public synchronized int read(byte[] b, int off, int len) + throws IOException + +where: + +* `b` is a byte array to write to. +* `off` is an offset for byte array `b`. +* `len` is the length in bytes to write to `b`. diff --git a/zookeeper-docs/src/main/resources/markdown/html/footer.html b/zookeeper-docs/src/main/resources/markdown/html/footer.html new file mode 100644 index 000000000..71d0c805f --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/html/footer.html @@ -0,0 +1,18 @@ +</div> +<div class="clearboth"> </div> +</div> +<div id="footer"> + <div class="lastmodified"> + <script type="text/javascript"> + <!-- + document.write("Last Published: " + document.lastModified); + // --> + </script> + </div> + <div class="copyright"> + Copyright © <a href="http://www.apache.org/licenses/">The Apache Software Foundation.</a> + </div> + <div id="logos"></div> +</div> +</body> +</html>
\ No newline at end of file diff --git a/zookeeper-docs/src/main/resources/markdown/html/header.html b/zookeeper-docs/src/main/resources/markdown/html/header.html new file mode 100644 index 000000000..4a3124149 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/html/header.html @@ -0,0 +1,140 @@ + +<!DOCTYPE html> +<html> +<head> + <META http-equiv="Content-Type" content="text/html; charset=UTF-8"> + <title>ZooKeeper: Because Coordinating Distributed Systems is a Zoo</title> + <link type="text/css" href="skin/basic.css" rel="stylesheet"> + <link media="screen" type="text/css" href="skin/screen.css" rel="stylesheet"> + <link media="print" type="text/css" href="skin/print.css" rel="stylesheet"> + <link type="text/css" href="skin/profile.css" rel="stylesheet"> + <script src="skin/getBlank.js" language="javascript" type="text/javascript"></script> + <script src="skin/getMenu.js" language="javascript" type="text/javascript"></script> + <script src="skin/init.js" language="javascript" type="text/javascript"></script> + <link rel="shortcut icon" href="images/favicon.ico"> +</head> +<body onload="init();"> +<div id="top"> + <div class="breadtrail"> + <a href="http://www.apache.org/">Apache</a> > <a href="http://zookeeper.apache.org/">ZooKeeper</a> + </div> + <div class="header"> + <div class="grouplogo"> + <a href="http://hadoop.apache.org/"><img class="logoImage" alt="Hadoop" src="images/hadoop-logo.jpg" title="Apache Hadoop"></a> + </div> + <div class="projectlogo"> + <a href="http://zookeeper.apache.org/"><img class="logoImage" alt="ZooKeeper" src="images/zookeeper_small.gif" title="ZooKeeper: distributed coordination"></a> + </div> + <div class="searchbox"> + <form action="http://www.google.com/search" method="get"> + <input value="zookeeper.apache.org" name="sitesearch" type="hidden"><input onFocus="getBlank (this, 'Search the site with google');" size="25" name="q" id="query" type="text" value="Search the site with google"> + <input name="Search" value="Search" type="submit"> + </form> + </div> + <ul id="tabs"> + <li> + <a class="unselected" href="http://zookeeper.apache.org/">Project</a> + </li> + <li> + <a class="unselected" href="https://cwiki.apache.org/confluence/display/ZOOKEEPER/">Wiki</a> + </li> + <li class="current"> + <a class="selected" href="index.html">ZooKeeper 3.4 Documentation</a> + </li> + </ul> + </div> +</div> +<div id="main"> + <div id="publishedStrip"> + <div id="level2tabs"></div> + <script type="text/javascript"><!-- +document.write("Last Published: " + document.lastModified); +// --></script> + </div> + <div class="breadtrail"> + + </div> + <div id="menu"> + <div onclick="SwitchMenu('menu_1', 'skin/')" id="menu_1Title" class="menutitle">Overview</div> + <div id="menu_1" class="menuitemgroup"> + <div class="menuitem"> + <a href="index.html">Welcome</a> + </div> + <div class="menuitem"> + <a href="zookeeperOver.html">Overview</a> + </div> + <div class="menuitem"> + <a href="zookeeperStarted.html">Getting Started</a> + </div> + <div class="menuitem"> + <a href="releasenotes.html">Release Notes</a> + </div> + </div> + <div onclick="SwitchMenu('menu_2', 'skin/')" id="menu_2Title" class="menutitle">Developer</div> + <div id="menu_2" class="menuitemgroup"> + <div class="menuitem"> + <a href="api/index.html">API Docs</a> + </div> + <div class="menuitem"> + <a href="zookeeperProgrammers.html">Programmer's Guide</a> + </div> + <div class="menuitem"> + <a href="javaExample.html">Java Example</a> + </div> + <div class="menuitem"> + <a href="zookeeperTutorial.html">Barrier and Queue Tutorial</a> + </div> + <div class="menuitem"> + <a href="recipes.html">Recipes</a> + </div> + </div> + <div onclick="SwitchMenu('menu_3', 'skin/')" id="menu_3Title" class="menutitle">Bookkeeper</div> + <div id="menu_3" class="menuitemgroup"> + <div class="menuitem"> + <a href="bookkeeperStarted.html">Getting started</a> + </div> + <div class="menuitem"> + <a href="bookkeeperOverview.html">Overview</a> + </div> + <div class="menuitem"> + <a href="bookkeeperConfig.html">Setup guide</a> + </div> + <div class="menuitem"> + <a href="bookkeeperProgrammer.html">Programmer's guide</a> + </div> + </div> + <div onclick="SwitchMenu('menu_4', 'skin/')" id="menu_4Title" class="menutitle">Admin & Ops</div> + <div id="menu_4" class="menuitemgroup"> + <div class="menuitem"> + <a href="zookeeperAdmin.html">Administrator's Guide</a> + </div> + <div class="menuitem"> + <a href="zookeeperQuotas.html">Quota Guide</a> + </div> + <div class="menuitem"> + <a href="zookeeperJMX.html">JMX</a> + </div> + <div class="menuitem"> + <a href="zookeeperObservers.html">Observers Guide</a> + </div> + </div> + <div onclick="SwitchMenu('menu_5', 'skin/')" id="menu_5Title" class="menutitle">Contributor</div> + <div id="menu_5" class="menuitemgroup"> + <div class="menuitem"> + <a href="zookeeperInternals.html">ZooKeeper Internals</a> + </div> + </div> + <div onclick="SwitchMenu('menu_6', 'skin/')" id="menu_6Title" class="menutitle">Miscellaneous</div> + <div id="menu_6" class="menuitemgroup"> + <div class="menuitem"> + <a href="https://cwiki.apache.org/confluence/display/ZOOKEEPER">Wiki</a> + </div> + <div class="menuitem"> + <a href="https://cwiki.apache.org/confluence/display/ZOOKEEPER/FAQ">FAQ</a> + </div> + <div class="menuitem"> + <a href="http://zookeeper.apache.org/mailing_lists.html">Mailing Lists</a> + </div> + </div> + </div> + <div id="content"> diff --git a/zookeeper-docs/src/main/resources/markdown/images/2pc.jpg b/zookeeper-docs/src/main/resources/markdown/images/2pc.jpg Binary files differnew file mode 100755 index 000000000..fe4488fd9 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/images/2pc.jpg diff --git a/zookeeper-docs/src/main/resources/markdown/images/bk-overview.jpg b/zookeeper-docs/src/main/resources/markdown/images/bk-overview.jpg Binary files differnew file mode 100644 index 000000000..6e12fb4f0 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/images/bk-overview.jpg diff --git a/zookeeper-docs/src/main/resources/markdown/images/favicon.ico b/zookeeper-docs/src/main/resources/markdown/images/favicon.ico Binary files differnew file mode 100644 index 000000000..161bcf784 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/images/favicon.ico diff --git a/zookeeper-docs/src/main/resources/markdown/images/hadoop-logo.jpg b/zookeeper-docs/src/main/resources/markdown/images/hadoop-logo.jpg Binary files differnew file mode 100644 index 000000000..809525d9f --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/images/hadoop-logo.jpg diff --git a/zookeeper-docs/src/main/resources/markdown/images/state_dia.dia b/zookeeper-docs/src/main/resources/markdown/images/state_dia.dia Binary files differnew file mode 100755 index 000000000..4a58a0085 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/images/state_dia.dia diff --git a/zookeeper-docs/src/main/resources/markdown/images/state_dia.jpg b/zookeeper-docs/src/main/resources/markdown/images/state_dia.jpg Binary files differnew file mode 100755 index 000000000..b6f4a8b06 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/images/state_dia.jpg diff --git a/zookeeper-docs/src/main/resources/markdown/images/zkarch.jpg b/zookeeper-docs/src/main/resources/markdown/images/zkarch.jpg Binary files differnew file mode 100644 index 000000000..a0e5fccba --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/images/zkarch.jpg diff --git a/zookeeper-docs/src/main/resources/markdown/images/zkcomponents.jpg b/zookeeper-docs/src/main/resources/markdown/images/zkcomponents.jpg Binary files differnew file mode 100644 index 000000000..769057857 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/images/zkcomponents.jpg diff --git a/zookeeper-docs/src/main/resources/markdown/images/zknamespace.jpg b/zookeeper-docs/src/main/resources/markdown/images/zknamespace.jpg Binary files differnew file mode 100644 index 000000000..05534bc66 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/images/zknamespace.jpg diff --git a/zookeeper-docs/src/main/resources/markdown/images/zkperfRW-3.2.jpg b/zookeeper-docs/src/main/resources/markdown/images/zkperfRW-3.2.jpg Binary files differnew file mode 100644 index 000000000..594b50bb5 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/images/zkperfRW-3.2.jpg diff --git a/zookeeper-docs/src/main/resources/markdown/images/zkperfRW.jpg b/zookeeper-docs/src/main/resources/markdown/images/zkperfRW.jpg Binary files differnew file mode 100644 index 000000000..ad3019f41 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/images/zkperfRW.jpg diff --git a/zookeeper-docs/src/main/resources/markdown/images/zkperfreliability.jpg b/zookeeper-docs/src/main/resources/markdown/images/zkperfreliability.jpg Binary files differnew file mode 100644 index 000000000..232bba804 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/images/zkperfreliability.jpg diff --git a/zookeeper-docs/src/main/resources/markdown/images/zkservice.jpg b/zookeeper-docs/src/main/resources/markdown/images/zkservice.jpg Binary files differnew file mode 100644 index 000000000..1ec91543f --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/images/zkservice.jpg diff --git a/zookeeper-docs/src/main/resources/markdown/images/zookeeper_small.gif b/zookeeper-docs/src/main/resources/markdown/images/zookeeper_small.gif Binary files differnew file mode 100644 index 000000000..4e8014f8f --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/images/zookeeper_small.gif diff --git a/zookeeper-docs/src/main/resources/markdown/index.md b/zookeeper-docs/src/main/resources/markdown/index.md new file mode 100644 index 000000000..904817179 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/index.md @@ -0,0 +1,62 @@ +<!-- +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. +//--> + +## ZooKeeper: Because Coordinating Distributed Systems is a Zoo + +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. + +The following documents describe concepts and procedures to get +you started using ZooKeeper. If you have more questions, please +ask the [mailing list](http://zookeeper.apache.org/mailing_lists.html) or browse the +archives. + ++ **ZooKeeper Overview** + Technical Overview Documents for Client Developers, Adminstrators, and Contributors + + [Overview](zookeeperOver.html) - a bird's eye view of ZooKeeper, including design concepts and architecture + + [Getting Started](zookeeperStarted.html) - a tutorial-style guide for developers to install, run, and program to ZooKeeper + + [Release Notes](releasenotes.html) - new developer and user facing features, improvements, and incompatibilities ++ **Developers** + Documents for Developers using the ZooKeeper Client API + + [API Docs](index.html) - the technical reference to ZooKeeper Client APIs + + [Programmer's Guide](zookeeperProgrammers.html) - a client application developer's guide to ZooKeeper + + [ZooKeeper Java Example](javaExample.html) - a simple Zookeeper client appplication, written in Java + + [Barrier and Queue Tutorial](zookeeperTutorial.html) - sample implementations of barriers and queues + + [ZooKeeper Recipes](recipes.html) - higher level solutions to common problems in distributed applications ++ **Administrators & Operators** + Documents for Administrators and Operations Engineers of ZooKeeper Deployments + + [Administrator's Guide](zookeeperAdmin.html) - a guide for system administrators and anyone else who might deploy ZooKeeper + + [Quota Guide](zookeeperQuotas.html) - a guide for system administrators on Quotas in ZooKeeper. + + [JMX](zookeeperJMX.html) - how to enable JMX in ZooKeeper + + [Hierarchical quorums](zookeeperHierarchicalQuorums.html) + + [Observers](zookeeperObservers.html) - non-voting ensemble members that easily improve ZooKeeper's scalability ++ **Contributors** + Documents for Developers Contributing to the ZooKeeper Open Source Project + + [ZooKeeper Internals](zookeeperInternals.html) - assorted topics on the inner workings of ZooKeeper ++ **Miscellaneous ZooKeeper Documentation** + + [Wiki](https://cwiki.apache.org/confluence/display/ZOOKEEPER) + + [FAQ](https://cwiki.apache.org/confluence/display/ZOOKEEPER/FAQ) ++ **BookKeeper Documentation** + BookKeeper is a highly-available system that implements high-performance write-ahead logging. It uses ZooKeeper for metadata, which is the main reason for being a ZooKeeper contrib. + + [henn, what's it again?](bookkeeperOverview.html) + + [Ok, now how do I try it out](bookkeeperStarted.html) + + [Awesome, but how do I integrate it with my app?](bookkeeperProgrammer.html) + + [Can I stream bytes instead of entries?](bookkeeperStream.html) diff --git a/zookeeper-docs/src/main/resources/markdown/javaExample.md b/zookeeper-docs/src/main/resources/markdown/javaExample.md new file mode 100644 index 000000000..b33963c70 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/javaExample.md @@ -0,0 +1,627 @@ +<!-- +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. +//--> + +# ZooKeeper Java Example + +* [A Simple Watch Client](#ch_Introduction) + * [Requirements](#sc_requirements) + * [Program Design](#sc_design) +* [The Executor Class](#sc_executor) +* [The DataMonitor Class](#sc_DataMonitor) +* [Complete Source Listings](#sc_completeSourceCode) + +<a name="ch_Introduction"></a> + +## A Simple Watch Client + +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. + +<a name="sc_requirements"></a> + +### Requirements + +The client has four requirements: + +* It takes as parameters: + * the address of the ZooKeeper service + * the name of a znode - the one to be watched + * the name of a file to write the output to + * an executable with arguments. +* It fetches the data associated with the znode and starts the executable. +* If the znode changes, the client refetches the contents and restarts the executable. +* If the znode disappears, the client kills the executable. + +<a name="sc_design"></a> + +### Program Design + +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 **Executor** +maintains the ZooKeeper connection, and the class called the **DataMonitor** 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. + +<a name="sc_executor"></a> + +## The Executor Class + +The Executor object is the primary container of the sample application. It contains +both the **ZooKeeper** object, **DataMonitor**, as described above in +[Program Design](#sc_design). + + + // 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) { + } + } + + +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: + + public class Executor implements Watcher, Runnable, DataMonitor.DataMonitorListener { + ... + + +The **Watcher** interface is defined by the ZooKeeper Java API. +ZooKeeper uses it to communicate back to its container. It supports only one method, `process()`, 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.) + + + public void process(WatchedEvent event) { + dm.process(event); + } + + +The **DataMonitorListener** +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: + + + 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); + } + + +This interface is defined in the DataMonitor class and implemented in the Executor class. +When `Executor.exists()` 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 _exist_. + +When `Executor.closing()` +is invoked, the Executor decides whether or not to shut itself down in response to the ZooKeeper connection permanently disappearing. + +As you might have guessed, DataMonitor is the object that invokes +these methods, in response to changes in ZooKeeper's state. + +Here are Executor's implementation of +`DataMonitorListener.exists()` and `DataMonitorListener.closing`: + + + 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(); + } + } + + +<a name="sc_DataMonitor"></a> + +## The DataMonitor Class + +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: + + + 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 + + +The call to `ZooKeeper.exists()` checks for the existence of the znode, +sets a watch, and passes a reference to itself (`this`) +as the completion callback object. In this sense, it kicks things off, since the +real processing happens when the watch is triggered. + +######Note + +>Don't confuse the completion callback with the watch callback. The `ZooKeeper.exists()` +completion callback, which happens to be the method `StatCallback.processResult()` implemented +in the DataMonitor object, is invoked when the asynchronous _setting of the watch_ operation +(by `ZooKeeper.exists()`) completes on the server. + +>The triggering of the watch, on the other hand, sends an event to the _Executor_ object, since +the Executor registered as the Watcher of the ZooKeeper object. + +>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. + +When the `ZooKeeper.exists()` operation completes on the server, the ZooKeeper API invokes this completion callback on +the client: + + + 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);</emphasis> + prevData = b; + } + } + + +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 `ZooKeeper.getData()`, the watch event set by +the `ZooKeeper.exists()` triggers a callback; +if there is a communication error, a connection watch event fires when +the connection comes back up. + +Finally, notice how DataMonitor processes watch events: + + + 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); + } + } + + +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 [ZooKeeper Watches](zookeeperProgrammers.html#ch_zkWatches) +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`ZooKeeper.exists()` to find out what has changed. + +<a name="sc_completeSourceCode"></a> + +## Complete Source Listings + +### Executor.java + + + /** + * 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(); + } + } + } + } + + +### DataMonitor.java + + + /** + * 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; + } + } + } + diff --git a/zookeeper-docs/src/main/resources/markdown/recipes.md b/zookeeper-docs/src/main/resources/markdown/recipes.md new file mode 100644 index 000000000..7d160e26c --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/recipes.md @@ -0,0 +1,387 @@ +<!-- +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. +//--> + +# ZooKeeper Recipes and Solutions + +* [A Guide to Creating Higher-level Constructs with ZooKeeper](#ch_recipes) + * [Important Note About Error Handling](#sc_recipes_errorHandlingNote) + * [Out of the Box Applications: Name Service, Configuration, Group Membership](#sc_outOfTheBox) + * [Barriers](#sc_recipes_eventHandles) + * [Double Barriers](#sc_doubleBarriers) + * [Queues](#sc_recipes_Queues) + * [Priority Queues](#sc_recipes_priorityQueues) + * [Locks](#sc_recipes_Locks) + * [Recoverable Errors and the GUID](#sc_recipes_GuidNote) + * [Shared Locks](#Shared+Locks) + * [Revocable Shared Locks](#sc_revocableSharedLocks) + * [Two-phased Commit](#sc_recipes_twoPhasedCommit) + * [Leader Election](#sc_leaderElection) + +<a name="ch_recipes"></a> + +## A Guide to Creating Higher-level Constructs with ZooKeeper + +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. + +One of the most interesting things about ZooKeeper is that even +though ZooKeeper uses _asynchronous_ notifications, you +can use it to build _synchronous_ 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. + +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. + +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. + +<a name="sc_outOfTheBox"></a> + +### Out of the Box Applications: Name Service, Configuration, Group Membership + +Name service and configuration are two of the primary applications +of ZooKeeper. These two functions are provided directly by the ZooKeeper +API. + +Another function directly provided by ZooKeeper is _group +membership_. 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. + +<a name="sc_recipes_eventHandles"></a> + +### Barriers + +Distributed systems use _barriers_ +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: + +1. Client calls the ZooKeeper API's **exists()** function on the barrier node, with + _watch_ set to true. +1. If **exists()** returns false, the + barrier is gone and the client proceeds +1. Else, if **exists()** returns true, + the clients wait for a watch event from ZooKeeper for the barrier + node. +1. When the watch event is triggered, the client reissues the + **exists( )** call, again waiting until + the barrier node is removed. + +<a name="sc_doubleBarriers"></a> + +#### Double Barriers + +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. + +The pseudo code in this recipe represents the barrier node as +_b_. Every client process _p_ +registers with the barrier node on entry and unregisters when it is +ready to leave. A node registers with the barrier node via the **Enter** procedure below, it waits until +_x_ client process register before proceeding with +the computation. (The _x_ here is up to you to +determine for your system.) + +| **Enter** | **Leave** | +|-----------------------------------|-------------------------------| +| 1. Create a name __n_ = _b_+“/”+_p__ | 1. **L = getChildren(b, false)** | +| 2. Set watch: **exists(_b_ + ‘‘/ready’’, true)** | 2. if no children, exit | +| 3. Create child: **create(_n_, EPHEMERAL)** | 3. if _p_ is only process node in L, delete(n) and exit | +| 4. **L = getChildren(b, false)** | 4. if _p_ is the lowest process node in L, wait on highest process node in L | +| 5. if fewer children in L than_x_, wait for watch event | 5. else **delete(_n_)**if still exists and wait on lowest process node in L | +| 6. else **create(b + ‘‘/ready’’, REGULAR)** | 6. goto 1 | + +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. + +On exit, you can't use a flag such as _ready_ +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. + +Processes exit when there are no process nodes left as children of +_b_. 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. + +<a name="sc_recipes_Queues"></a> + +### Queues + +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 +_sequence_ and _ephemeral_ flags in +the create() call set to true. Because the _sequence_ +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 **getChildren( )** function, with +_watch_ set to true on the queue node, and begins +processing nodes with the lowest number. The client does not need to issue +another **getChildren( )** until it exhausts +the list obtained from the first **getChildren( +)** call. If there are are no children in the queue node, the +reader waits for a watch notification to check the queue again. + +######Note +>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. + +<a name="sc_recipes_priorityQueues"></a> + +#### Priority Queues + +To implement a priority queue, you need only make two simple +changes to the generic [queue +recipe](#sc_recipes_Queues) . 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. + +<a name="sc_recipes_Locks"></a> + +### Locks + +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. + +######Note +>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. + +Clients wishing to obtain a lock do the following: + +1. Call **create( )** with a pathname + of "_locknode_/guid-lock-" and the _sequence_ and + _ephemeral_ flags set. The _guid_ + is needed in case the create() result is missed. See the note below. +1. Call **getChildren( )** on the lock + node _without_ setting the watch flag (this is + important to avoid the herd effect). +1. If the pathname created in step **1** has the lowest sequence number suffix, the + client has the lock and the client exits the protocol. +1. The client calls **exists( )** with + the watch flag set on the path in the lock directory with the next + lowest sequence number. +1. if **exists( )** returns false, go + to step **2**. Otherwise, wait for a + notification for the pathname from the previous step before going to + step **2**. + +The unlock protocol is very simple: clients wishing to release a +lock simply delete the node they created in step 1. + +Here are a few things to notice: + +* 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. + +* There is no polling or timeouts. + +* Because of the way you implement locking, it is easy to see the + amount of lock contention, break locks, debug locking problems, + etc. + +<a name="Shared+Locks"></a> + +#### Shared Locks + +You can implement shared locks by with a few changes to the lock +protocol: + +| **Obtaining a read lock:** | **Obtaining a write lock:** | +|----------------------------|-----------------------------| +| 1. Call **create( )** to create a node with pathname "*guid-/read-*". This is the lock node use later in the protocol. Make sure to set both the _sequence_ and _ephemeral_ flags. | 1. Call **create( )** to create a node with pathname "*guid-/write-*". This is the lock node spoken of later in the protocol. Make sure to set both _sequence_ and _ephemeral_ flags. | +| 2. Call **getChildren( )** on the lock node _without_ setting the _watch_ flag - this is important, as it avoids the herd effect. | 2. Call **getChildren( )** on the lock node _without_ setting the _watch_ flag - this is important, as it avoids the herd effect. | +| 3. If there are no children with a pathname starting with "*write-*" and having a lower sequence number than the node created in step **1**, the client has the lock and can exit the protocol. | 3. If there are no children with a lower sequence number than the node created in step **1**, the client has the lock and the client exits the protocol. | +| 4. Otherwise, call **exists( )**, with _watch_ flag, set on the node in lock directory with pathname staring with "*write-*" having the next lowest sequence number. | 4. Call **exists( ),** with _watch_ flag set, on the node with the pathname that has the next lowest sequence number. | +| 5. If **exists( )** returns _false_, goto step **2**. | 5. If **exists( )** returns _false_, goto step **2**. Otherwise, wait for a notification for the pathname from the previous step before going to step **2**. | +| 6. Otherwise, wait for a notification for the pathname from the previous step before going to step **2** | | + +Notes: + +* 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 "*write-*" 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. + +* See the [note for Locks](#sc_recipes_GuidNote) on how to use the guid in the node. + +<a name="sc_revocableSharedLocks"></a> + +#### Revocable Shared Locks + +With minor modifications to the Shared Lock protocol, you make +shared locks revocable by modifying the shared lock protocol: + +In step **1**, of both obtain reader +and writer lock protocols, call **getData( +)** with _watch_ set, immediately after the +call to **create( )**. If the client +subsequently receives notification for the node it created in step +**1**, it does another **getData( )** on that node, with +_watch_ 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 **setData()** on the lock node, writing "unlock" to that node. + +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 _Revocable Shared Locks with Freaking +Laser Beams_ 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. + +<a name="sc_recipes_twoPhasedCommit"></a> + +### Two-phased Commit + +A two-phase commit protocol is an algorithm that lets all clients in +a distributed system agree either to commit a transaction or abort. + +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". + +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. + +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. + +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. + +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. + +<a name="sc_leaderElection"></a> + +### Leader Election + +A simple way of doing leader election with ZooKeeper is to use the +**SEQUENCE|EPHEMERAL** 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. + +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. + +Here's the pseudo code: + +Let ELECTION be a path of choice of the application. To volunteer to +be a leader: + +1. Create znode z with path "ELECTION/guid-n_" with both SEQUENCE and + EPHEMERAL flags; +1. Let C be the children of "ELECTION", and i be the sequence + number of z; +1. 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; + +Upon receiving a notification of znode deletion: + +1. Let C be the new set of children of ELECTION; +1. If z is the smallest node in C, then execute leader + procedure; +1. 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; + +Notes: + +* 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. diff --git a/zookeeper-docs/src/main/resources/markdown/skin/basic.css b/zookeeper-docs/src/main/resources/markdown/skin/basic.css new file mode 100644 index 000000000..01c383da8 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/skin/basic.css @@ -0,0 +1,167 @@ +/* +* Licensed to the Apache Software Foundation (ASF) under one or more +* contributor license agreements. See the NOTICE file distributed with +* this work for additional information regarding copyright ownership. +* The ASF licenses this file to You 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. +*/ +/** + * General + */ + +img { border: 0; } + +#content table { + border: 0; + width: 100%; +} +/*Hack to get IE to render the table at 100%*/ +* html #content table { margin-left: -3px; } + +#content th, +#content td { + margin: 0; + padding: 0; + vertical-align: top; +} + +.clearboth { + clear: both; +} + +.note, .warning, .fixme { + clear:right; + border: solid black 1px; + margin: 1em 3em; +} + +.note .label { + background: #369; + color: white; + font-weight: bold; + padding: 5px 10px; +} +.note .content { + background: #F0F0FF; + color: black; + line-height: 120%; + font-size: 90%; + padding: 5px 10px; +} +.warning .label { + background: #C00; + color: white; + font-weight: bold; + padding: 5px 10px; +} +.warning .content { + background: #FFF0F0; + color: black; + line-height: 120%; + font-size: 90%; + padding: 5px 10px; +} +.fixme .label { + background: #C6C600; + color: black; + font-weight: bold; + padding: 5px 10px; +} +.fixme .content { + padding: 5px 10px; +} + +/** + * Typography + */ + +body { + font-family: verdana, "Trebuchet MS", arial, helvetica, sans-serif; + font-size: 100%; +} + +#content { + font-family: Georgia, Palatino, Times, serif; + font-size: 95%; +} +#tabs { + font-size: 70%; +} +#menu { + font-size: 80%; +} +#footer { + font-size: 70%; +} + +h1, h2, h3, h4, h5, h6 { + font-family: "Trebuchet MS", verdana, arial, helvetica, sans-serif; + font-weight: bold; + margin-top: 1em; + margin-bottom: .5em; +} + +h1 { + margin-top: 0; + margin-bottom: 1em; + font-size: 1.4em; +} +#content h1 { + font-size: 160%; + margin-bottom: .5em; +} +#menu h1 { + margin: 0; + padding: 10px; + background: #336699; + color: white; +} +h2 { font-size: 120%; } +h3 { font-size: 100%; } +h4 { font-size: 90%; } +h5 { font-size: 80%; } +h6 { font-size: 75%; } + +p { + line-height: 120%; + text-align: left; + margin-top: .5em; + margin-bottom: 1em; +} + +#content li, +#content th, +#content td, +#content li ul, +#content li ol{ + margin-top: .5em; + margin-bottom: .5em; +} + + +#content li li, +#minitoc-area li{ + margin-top: 0em; + margin-bottom: 0em; +} + +#content .attribution { + text-align: right; + font-style: italic; + font-size: 85%; + margin-top: 1em; +} + +.codefrag { + font-family: "Courier New", Courier, monospace; + font-size: 110%; +}
\ No newline at end of file diff --git a/zookeeper-docs/src/main/resources/markdown/skin/chapter.gif b/zookeeper-docs/src/main/resources/markdown/skin/chapter.gif Binary files differnew file mode 100644 index 000000000..d3d8245d0 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/skin/chapter.gif diff --git a/zookeeper-docs/src/main/resources/markdown/skin/chapter_open.gif b/zookeeper-docs/src/main/resources/markdown/skin/chapter_open.gif Binary files differnew file mode 100644 index 000000000..eecce18b5 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/skin/chapter_open.gif diff --git a/zookeeper-docs/src/main/resources/markdown/skin/current.gif b/zookeeper-docs/src/main/resources/markdown/skin/current.gif Binary files differnew file mode 100644 index 000000000..fd82c0820 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/skin/current.gif diff --git a/zookeeper-docs/src/main/resources/markdown/skin/getBlank.js b/zookeeper-docs/src/main/resources/markdown/skin/getBlank.js new file mode 100644 index 000000000..d9978c0b3 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/skin/getBlank.js @@ -0,0 +1,40 @@ +/* +* Licensed to the Apache Software Foundation (ASF) under one or more +* contributor license agreements. See the NOTICE file distributed with +* this work for additional information regarding copyright ownership. +* The ASF licenses this file to You 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. +*/ +/** + * getBlank script - when included in a html file and called from a form text field, will set the value of this field to "" + * if the text value is still the standard value. + * getPrompt script - when included in a html file and called from a form text field, will set the value of this field to the prompt + * if the text value is empty. + * + * Typical usage: + * <script type="text/javascript" language="JavaScript" src="getBlank.js"></script> + * <input type="text" id="query" value="Search the site:" onFocus="getBlank (this, 'Search the site:');" onBlur="getBlank (this, 'Search the site:');"/> + */ +<!-- +function getBlank (form, stdValue){ +if (form.value == stdValue){ + form.value = ''; + } +return true; +} +function getPrompt (form, stdValue){ +if (form.value == ''){ + form.value = stdValue; + } +return true; +} +//--> diff --git a/zookeeper-docs/src/main/resources/markdown/skin/getMenu.js b/zookeeper-docs/src/main/resources/markdown/skin/getMenu.js new file mode 100644 index 000000000..6878b2653 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/skin/getMenu.js @@ -0,0 +1,45 @@ +/* +* Licensed to the Apache Software Foundation (ASF) under one or more +* contributor license agreements. See the NOTICE file distributed with +* this work for additional information regarding copyright ownership. +* The ASF licenses this file to You 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. +*/ +/** + * This script, when included in a html file, can be used to make collapsible menus + * + * Typical usage: + * <script type="text/javascript" language="JavaScript" src="menu.js"></script> + */ + +if (document.getElementById){ + document.write('<style type="text/css">.menuitemgroup{display: none;}</style>') +} + + +function SwitchMenu(obj, thePath) +{ +var open = 'url("'+thePath + 'chapter_open.gif")'; +var close = 'url("'+thePath + 'chapter.gif")'; + if(document.getElementById) { + var el = document.getElementById(obj); + var title = document.getElementById(obj+'Title'); + + if(el.style.display != "block"){ + title.style.backgroundImage = open; + el.style.display = "block"; + }else{ + title.style.backgroundImage = close; + el.style.display = "none"; + } + }// end - if(document.getElementById) +}//end - function SwitchMenu(obj) diff --git a/zookeeper-docs/src/main/resources/markdown/skin/header_white_line.gif b/zookeeper-docs/src/main/resources/markdown/skin/header_white_line.gif Binary files differnew file mode 100644 index 000000000..369cae8dc --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/skin/header_white_line.gif diff --git a/zookeeper-docs/src/main/resources/markdown/skin/init.js b/zookeeper-docs/src/main/resources/markdown/skin/init.js new file mode 100644 index 000000000..f94eda1a6 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/skin/init.js @@ -0,0 +1,57 @@ +/* +* Licensed to the Apache Software Foundation (ASF) under one or more +* contributor license agreements. See the NOTICE file distributed with +* this work for additional information regarding copyright ownership. +* The ASF licenses this file to You 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. +*/ +/** + * This script, when included in a html file, can be used to make collapsible menus + * + * Typical usage: + * <script type="text/javascript" language="JavaScript" src="menu.js"></script> + */ + +function getFileName(url){ + var fileName = url.substring(url.lastIndexOf('/')+1); + return fileName; +} + +function init(){ + var url = window .location.pathname; + var fileName = getFileName(url); + + var menuItemGroup = document.getElementById("menu").children; + + for (i = 0; i < menuItemGroup.length; i++) { + if("menutitle" === menuItemGroup[i].className){ + continue; + } + var menuItem = menuItemGroup[i].children; + if(menuItem.length>0){ + for (j = 0; j < menuItem.length; j++) { + if(menuItem[j].firstElementChild != null){ + var linkItem = menuItem[j].firstElementChild; + if('a' === linkItem.localName){ + var linkFile = getFileName(linkItem.href); + if(fileName === linkFile && linkItem.href.lastIndexOf("api/index.html")<0){ + linkItem.className = "selected"; + linkItem.parentNode.parentNode.className = "selectedmenuitemgroup"; + var title = document.getElementById(linkItem.parentNode.parentNode.id+"Title"); + title.className="menutitle selected"; + } + } + } + } + } + } +} diff --git a/zookeeper-docs/src/main/resources/markdown/skin/instruction_arrow.png b/zookeeper-docs/src/main/resources/markdown/skin/instruction_arrow.png Binary files differnew file mode 100644 index 000000000..0fbc72452 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/skin/instruction_arrow.png diff --git a/zookeeper-docs/src/main/resources/markdown/skin/menu.js b/zookeeper-docs/src/main/resources/markdown/skin/menu.js new file mode 100644 index 000000000..06ea471dc --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/skin/menu.js @@ -0,0 +1,48 @@ +/* +* Licensed to the Apache Software Foundation (ASF) under one or more +* contributor license agreements. See the NOTICE file distributed with +* this work for additional information regarding copyright ownership. +* The ASF licenses this file to You 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. +*/ +/** + * This script, when included in a html file, can be used to make collapsible menus + * + * Typical usage: + * <script type="text/javascript" language="JavaScript" src="menu.js"></script> + */ + +if (document.getElementById){ + document.write('<style type="text/css">.menuitemgroup{display: none;}</style>') +} + +function SwitchMenu(obj) +{ + if(document.getElementById) { + var el = document.getElementById(obj); + var title = document.getElementById(obj+'Title'); + + if(obj.indexOf("_selected_")==0&&el.style.display == ""){ + el.style.display = "block"; + title.className = "pagegroupselected"; + } + + if(el.style.display != "block"){ + el.style.display = "block"; + title.className = "pagegroupopen"; + } + else{ + el.style.display = "none"; + title.className = "pagegroup"; + } + }// end - if(document.getElementById) +}//end - function SwitchMenu(obj) diff --git a/zookeeper-docs/src/main/resources/markdown/skin/page.gif b/zookeeper-docs/src/main/resources/markdown/skin/page.gif Binary files differnew file mode 100644 index 000000000..a144d3295 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/skin/page.gif diff --git a/zookeeper-docs/src/main/resources/markdown/skin/print.css b/zookeeper-docs/src/main/resources/markdown/skin/print.css new file mode 100644 index 000000000..aaa99319a --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/skin/print.css @@ -0,0 +1,54 @@ +/* +* Licensed to the Apache Software Foundation (ASF) under one or more +* contributor license agreements. See the NOTICE file distributed with +* this work for additional information regarding copyright ownership. +* The ASF licenses this file to You 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. +*/ +body { + font-family: Georgia, Palatino, serif; + font-size: 12pt; + background: white; +} + +#tabs, +#menu, +#content .toc { + display: none; +} + +#content { + width: auto; + padding: 0; + float: none !important; + color: black; + background: inherit; +} + +a:link, a:visited { + color: #336699; + background: inherit; + text-decoration: underline; +} + +#top .logo { + padding: 0; + margin: 0 0 2em 0; +} + +#footer { + margin-top: 4em; +} + +acronym { + border: 0; +}
\ No newline at end of file diff --git a/zookeeper-docs/src/main/resources/markdown/skin/printer.gif b/zookeeper-docs/src/main/resources/markdown/skin/printer.gif Binary files differnew file mode 100644 index 000000000..a8d0d419c --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/skin/printer.gif diff --git a/zookeeper-docs/src/main/resources/markdown/skin/profile.css b/zookeeper-docs/src/main/resources/markdown/skin/profile.css new file mode 100644 index 000000000..190e74f32 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/skin/profile.css @@ -0,0 +1,159 @@ + + +/* ==================== aural ============================ */ + +@media aural { + h1, h2, h3, h4, h5, h6 { voice-family: paul, male; stress: 20; richness: 90 } + h1 { pitch: x-low; pitch-range: 90 } + h2 { pitch: x-low; pitch-range: 80 } + h3 { pitch: low; pitch-range: 70 } + h4 { pitch: medium; pitch-range: 60 } + h5 { pitch: medium; pitch-range: 50 } + h6 { pitch: medium; pitch-range: 40 } + li, dt, dd { pitch: medium; richness: 60 } + dt { stress: 80 } + pre, code, tt { pitch: medium; pitch-range: 0; stress: 0; richness: 80 } + em { pitch: medium; pitch-range: 60; stress: 60; richness: 50 } + strong { pitch: medium; pitch-range: 60; stress: 90; richness: 90 } + dfn { pitch: high; pitch-range: 60; stress: 60 } + s, strike { richness: 0 } + i { pitch: medium; pitch-range: 60; stress: 60; richness: 50 } + b { pitch: medium; pitch-range: 60; stress: 90; richness: 90 } + u { richness: 0 } + + :link { voice-family: harry, male } + :visited { voice-family: betty, female } + :active { voice-family: betty, female; pitch-range: 80; pitch: x-high } +} + +#top { background-color: #FFFFFF;} + +#top .header .current { background-color: #4C6C8F;} +#top .header .current a:link { color: #ffffff; } +#top .header .current a:visited { color: #ffffff; } +#top .header .current a:hover { color: #ffffff; } + +#tabs li { background-color: #E5E4D9 ;} +#tabs li a:link { color: #000000; } +#tabs li a:visited { color: #000000; } +#tabs li a:hover { color: #000000; } + +#level2tabs a.selected { background-color: #4C6C8F ;} +#level2tabs a:link { color: #ffffff; } +#level2tabs a:visited { color: #ffffff; } +#level2tabs a:hover { color: #ffffff; } + +#level2tabs { background-color: #E5E4D9;} +#level2tabs a.unselected:link { color: #000000; } +#level2tabs a.unselected:visited { color: #000000; } +#level2tabs a.unselected:hover { color: #000000; } + +.heading { background-color: #E5E4D9;} + +.boxed { background-color: #E5E4D9;} +.underlined_5 {border-bottom: solid 5px #E5E4D9;} +.underlined_10 {border-bottom: solid 10px #E5E4D9;} +table caption { +background-color: #E5E4D9; +color: #000000; +} + +#feedback { +color: #FFFFFF; +background: #4C6C8F; +text-align: center; +} +#feedback #feedbackto { +color: #FFFFFF; +} + +#publishedStrip { +color: #FFFFFF; +background: #4C6C8F; +} + +#publishedStrip { +color: #000000; +background: #E5E4D9; +} + +#menu a.selected { background-color: #CFDCED; + border-color: #999999; + color: #000000;} +#menu a.selected:visited { color: #000000;} + +#menu { border-color: #999999;} +#menu .menupageitemgroup { border-color: #999999;} + +#menu { background-color: #4C6C8F;} +#menu { color: #ffffff;} +#menu a:link { color: #ffffff;} +#menu a:visited { color: #ffffff;} +#menu a:hover { +background-color: #4C6C8F; +color: #ffffff;} + +#menu h1 { +color: #000000; +background-color: #cfdced; +} + +#top .searchbox { +background-color: #E5E4D9 ; +color: #000000; +} + +#menu .menupageitemgroup { +background-color: #E5E4D9; +} +#menu .menupageitem { +color: #000000; +} +#menu .menupageitem a:link { color: #000000;} +#menu .menupageitem a:visited { color: #000000;} +#menu .menupageitem a:hover { +background-color: #E5E4D9; +color: #000000; +} + +body{ +background-color: #ffffff; +color: #000000; +} +a:link { color:#0000ff} +a:visited { color:#009999} +a:hover { color:#6587ff} + + +.ForrestTable { background-color: #ccc;} + +.ForrestTable td { background-color: #ffffff;} + +.highlight { background-color: #ffff00;} + +.fixme { border-color: #c60;} + +.note { border-color: #069;} + +.warning { border-color: #900;} + +#footer { background-color: #E5E4D9;} +/* extra-css */ + + p.quote { + margin-left: 2em; + padding: .5em; + background-color: #f0f0f0; + font-family: monospace; + } + + pre { + margin-left: 0em; + padding: 0.5em; + background-color: #f0f0f0; + font-family: monospace; + } + + + +
\ No newline at end of file diff --git a/zookeeper-docs/src/main/resources/markdown/skin/prototype.js b/zookeeper-docs/src/main/resources/markdown/skin/prototype.js new file mode 100644 index 000000000..ed7d920cb --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/skin/prototype.js @@ -0,0 +1,1257 @@ +/* Prototype JavaScript framework, version 1.4.0_pre4 + * (c) 2005 Sam Stephenson <sam@conio.net> + * + * THIS FILE IS AUTOMATICALLY GENERATED. When sending patches, please diff + * against the source tree, available from the Prototype darcs repository. + * + * Prototype is freely distributable under the terms of an MIT-style license. + * + * For details, see the Prototype web site: http://prototype.conio.net/ + * +/*--------------------------------------------------------------------------*/ + +var Prototype = { + Version: '1.4.0_pre4', + + emptyFunction: function() {}, + K: function(x) {return x} +} + +var Class = { + create: function() { + return function() { + this.initialize.apply(this, arguments); + } + } +} + +var Abstract = new Object(); + +Object.extend = function(destination, source) { + for (property in source) { + destination[property] = source[property]; + } + return destination; +} + +Function.prototype.bind = function(object) { + var __method = this; + return function() { + return __method.apply(object, arguments); + } +} + +Function.prototype.bindAsEventListener = function(object) { + var __method = this; + return function(event) { + return __method.call(object, event || window.event); + } +} + +Number.prototype.toColorPart = function() { + var digits = this.toString(16); + if (this < 16) return '0' + digits; + return digits; +} + +var Try = { + these: function() { + var returnValue; + + for (var i = 0; i < arguments.length; i++) { + var lambda = arguments[i]; + try { + returnValue = lambda(); + break; + } catch (e) {} + } + + return returnValue; + } +} + +/*--------------------------------------------------------------------------*/ + +var PeriodicalExecuter = Class.create(); +PeriodicalExecuter.prototype = { + initialize: function(callback, frequency) { + this.callback = callback; + this.frequency = frequency; + this.currentlyExecuting = false; + + this.registerCallback(); + }, + + registerCallback: function() { + setInterval(this.onTimerEvent.bind(this), this.frequency * 1000); + }, + + onTimerEvent: function() { + if (!this.currentlyExecuting) { + try { + this.currentlyExecuting = true; + this.callback(); + } finally { + this.currentlyExecuting = false; + } + } + } +} + +/*--------------------------------------------------------------------------*/ + +function $() { + var elements = new Array(); + + for (var i = 0; i < arguments.length; i++) { + var element = arguments[i]; + if (typeof element == 'string') + element = document.getElementById(element); + + if (arguments.length == 1) + return element; + + elements.push(element); + } + + return elements; +} + +if (!Array.prototype.push) { + Array.prototype.push = function() { + var startLength = this.length; + for (var i = 0; i < arguments.length; i++) + this[startLength + i] = arguments[i]; + return this.length; + } +} + +if (!Function.prototype.apply) { + // Based on code from http://www.youngpup.net/ + Function.prototype.apply = function(object, parameters) { + var parameterStrings = new Array(); + if (!object) object = window; + if (!parameters) parameters = new Array(); + + for (var i = 0; i < parameters.length; i++) + parameterStrings[i] = 'parameters[' + i + ']'; + + object.__apply__ = this; + var result = eval('object.__apply__(' + + parameterStrings.join(', ') + ')'); + object.__apply__ = null; + + return result; + } +} + +Object.extend(String.prototype, { + stripTags: function() { + return this.replace(/<\/?[^>]+>/gi, ''); + }, + + escapeHTML: function() { + var div = document.createElement('div'); + var text = document.createTextNode(this); + div.appendChild(text); + return div.innerHTML; + }, + + unescapeHTML: function() { + var div = document.createElement('div'); + div.innerHTML = this.stripTags(); + return div.childNodes[0].nodeValue; + }, + + parseQuery: function() { + var str = this; + if (str.substring(0,1) == '?') { + str = this.substring(1); + } + var result = {}; + var pairs = str.split('&'); + for (var i = 0; i < pairs.length; i++) { + var pair = pairs[i].split('='); + result[pair[0]] = pair[1]; + } + return result; + } +}); + + +var _break = new Object(); +var _continue = new Object(); + +var Enumerable = { + each: function(iterator) { + var index = 0; + try { + this._each(function(value) { + try { + iterator(value, index++); + } catch (e) { + if (e != _continue) throw e; + } + }); + } catch (e) { + if (e != _break) throw e; + } + }, + + all: function(iterator) { + var result = true; + this.each(function(value, index) { + if (!(result &= (iterator || Prototype.K)(value, index))) + throw _break; + }); + return result; + }, + + any: function(iterator) { + var result = true; + this.each(function(value, index) { + if (result &= (iterator || Prototype.K)(value, index)) + throw _break; + }); + return result; + }, + + collect: function(iterator) { + var results = []; + this.each(function(value, index) { + results.push(iterator(value, index)); + }); + return results; + }, + + detect: function (iterator) { + var result; + this.each(function(value, index) { + if (iterator(value, index)) { + result = value; + throw _break; + } + }); + return result; + }, + + findAll: function(iterator) { + var results = []; + this.each(function(value, index) { + if (iterator(value, index)) + results.push(value); + }); + return results; + }, + + grep: function(pattern, iterator) { + var results = []; + this.each(function(value, index) { + var stringValue = value.toString(); + if (stringValue.match(pattern)) + results.push((iterator || Prototype.K)(value, index)); + }) + return results; + }, + + include: function(object) { + var found = false; + this.each(function(value) { + if (value == object) { + found = true; + throw _break; + } + }); + return found; + }, + + inject: function(memo, iterator) { + this.each(function(value, index) { + memo = iterator(memo, value, index); + }); + return memo; + }, + + invoke: function(method) { + var args = $A(arguments).slice(1); + return this.collect(function(value) { + return value[method].apply(value, args); + }); + }, + + max: function(iterator) { + var result; + this.each(function(value, index) { + value = (iterator || Prototype.K)(value, index); + if (value >= (result || value)) + result = value; + }); + return result; + }, + + min: function(iterator) { + var result; + this.each(function(value, index) { + value = (iterator || Prototype.K)(value, index); + if (value <= (result || value)) + result = value; + }); + return result; + }, + + partition: function(iterator) { + var trues = [], falses = []; + this.each(function(value, index) { + ((iterator || Prototype.K)(value, index) ? + trues : falses).push(value); + }); + return [trues, falses]; + }, + + pluck: function(property) { + var results = []; + this.each(function(value, index) { + results.push(value[property]); + }); + return results; + }, + + reject: function(iterator) { + var results = []; + this.each(function(value, index) { + if (!iterator(value, index)) + results.push(value); + }); + return results; + }, + + sortBy: function(iterator) { + return this.collect(function(value, index) { + return {value: value, criteria: iterator(value, index)}; + }).sort(function(left, right) { + var a = left.criteria, b = right.criteria; + return a < b ? -1 : a > b ? 1 : 0; + }).pluck('value'); + }, + + toArray: function() { + return this.collect(Prototype.K); + }, + + zip: function() { + var iterator = Prototype.K, args = $A(arguments); + if (typeof args.last() == 'function') + iterator = args.pop(); + + var collections = [this].concat(args).map($A); + return this.map(function(value, index) { + iterator(value = collections.pluck(index)); + return value; + }); + } +} + +Object.extend(Enumerable, { + map: Enumerable.collect, + find: Enumerable.detect, + select: Enumerable.findAll, + member: Enumerable.include, + entries: Enumerable.toArray +}); + +$A = Array.from = function(iterable) { + var results = []; + for (var i = 0; i < iterable.length; i++) + results.push(iterable[i]); + return results; +} + +Object.extend(Array.prototype, { + _each: function(iterator) { + for (var i = 0; i < this.length; i++) + iterator(this[i]); + }, + + first: function() { + return this[0]; + }, + + last: function() { + return this[this.length - 1]; + } +}); + +Object.extend(Array.prototype, Enumerable); + + +var Ajax = { + getTransport: function() { + return Try.these( + function() {return new ActiveXObject('Msxml2.XMLHTTP')}, + function() {return new ActiveXObject('Microsoft.XMLHTTP')}, + function() {return new XMLHttpRequest()} + ) || false; + } +} + +Ajax.Base = function() {}; +Ajax.Base.prototype = { + setOptions: function(options) { + this.options = { + method: 'post', + asynchronous: true, + parameters: '' + } + Object.extend(this.options, options || {}); + }, + + responseIsSuccess: function() { + return this.transport.status == undefined + || this.transport.status == 0 + || (this.transport.status >= 200 && this.transport.status < 300); + }, + + responseIsFailure: function() { + return !this.responseIsSuccess(); + } +} + +Ajax.Request = Class.create(); +Ajax.Request.Events = + ['Uninitialized', 'Loading', 'Loaded', 'Interactive', 'Complete']; + +Ajax.Request.prototype = Object.extend(new Ajax.Base(), { + initialize: function(url, options) { + this.transport = Ajax.getTransport(); + this.setOptions(options); + this.request(url); + }, + + request: function(url) { + var parameters = this.options.parameters || ''; + if (parameters.length > 0) parameters += '&_='; + + try { + if (this.options.method == 'get') + url += '?' + parameters; + + this.transport.open(this.options.method, url, + this.options.asynchronous); + + if (this.options.asynchronous) { + this.transport.onreadystatechange = this.onStateChange.bind(this); + setTimeout((function() {this.respondToReadyState(1)}).bind(this), 10); + } + + this.setRequestHeaders(); + + var body = this.options.postBody ? this.options.postBody : parameters; + this.transport.send(this.options.method == 'post' ? body : null); + + } catch (e) { + } + }, + + setRequestHeaders: function() { + var requestHeaders = + ['X-Requested-With', 'XMLHttpRequest', + 'X-Prototype-Version', Prototype.Version]; + + if (this.options.method == 'post') { + requestHeaders.push('Content-type', + 'application/x-www-form-urlencoded'); + + /* Force "Connection: close" for Mozilla browsers to work around + * a bug where XMLHttpReqeuest sends an incorrect Content-length + * header. See Mozilla Bugzilla #246651. + */ + if (this.transport.overrideMimeType) + requestHeaders.push('Connection', 'close'); + } + + if (this.options.requestHeaders) + requestHeaders.push.apply(requestHeaders, this.options.requestHeaders); + + for (var i = 0; i < requestHeaders.length; i += 2) + this.transport.setRequestHeader(requestHeaders[i], requestHeaders[i+1]); + }, + + onStateChange: function() { + var readyState = this.transport.readyState; + if (readyState != 1) + this.respondToReadyState(this.transport.readyState); + }, + + respondToReadyState: function(readyState) { + var event = Ajax.Request.Events[readyState]; + + if (event == 'Complete') + (this.options['on' + this.transport.status] + || this.options['on' + (this.responseIsSuccess() ? 'Success' : 'Failure')] + || Prototype.emptyFunction)(this.transport); + + (this.options['on' + event] || Prototype.emptyFunction)(this.transport); + + /* Avoid memory leak in MSIE: clean up the oncomplete event handler */ + if (event == 'Complete') + this.transport.onreadystatechange = Prototype.emptyFunction; + } +}); + +Ajax.Updater = Class.create(); +Ajax.Updater.ScriptFragment = '(?:<script.*?>)((\n|.)*?)(?:<\/script>)'; + +Object.extend(Object.extend(Ajax.Updater.prototype, Ajax.Request.prototype), { + initialize: function(container, url, options) { + this.containers = { + success: container.success ? $(container.success) : $(container), + failure: container.failure ? $(container.failure) : + (container.success ? null : $(container)) + } + + this.transport = Ajax.getTransport(); + this.setOptions(options); + + var onComplete = this.options.onComplete || Prototype.emptyFunction; + this.options.onComplete = (function() { + this.updateContent(); + onComplete(this.transport); + }).bind(this); + + this.request(url); + }, + + updateContent: function() { + var receiver = this.responseIsSuccess() ? + this.containers.success : this.containers.failure; + + var match = new RegExp(Ajax.Updater.ScriptFragment, 'img'); + var response = this.transport.responseText.replace(match, ''); + var scripts = this.transport.responseText.match(match); + + if (receiver) { + if (this.options.insertion) { + new this.options.insertion(receiver, response); + } else { + receiver.innerHTML = response; + } + } + + if (this.responseIsSuccess()) { + if (this.onComplete) + setTimeout((function() {this.onComplete( + this.transport)}).bind(this), 10); + } + + if (this.options.evalScripts && scripts) { + match = new RegExp(Ajax.Updater.ScriptFragment, 'im'); + setTimeout((function() { + for (var i = 0; i < scripts.length; i++) + eval(scripts[i].match(match)[1]); + }).bind(this), 10); + } + } +}); + +Ajax.PeriodicalUpdater = Class.create(); +Ajax.PeriodicalUpdater.prototype = Object.extend(new Ajax.Base(), { + initialize: function(container, url, options) { + this.setOptions(options); + this.onComplete = this.options.onComplete; + + this.frequency = (this.options.frequency || 2); + this.decay = 1; + + this.updater = {}; + this.container = container; + this.url = url; + + this.start(); + }, + + start: function() { + this.options.onComplete = this.updateComplete.bind(this); + this.onTimerEvent(); + }, + + stop: function() { + this.updater.onComplete = undefined; + clearTimeout(this.timer); + (this.onComplete || Ajax.emptyFunction).apply(this, arguments); + }, + + updateComplete: function(request) { + if (this.options.decay) { + this.decay = (request.responseText == this.lastText ? + this.decay * this.options.decay : 1); + + this.lastText = request.responseText; + } + this.timer = setTimeout(this.onTimerEvent.bind(this), + this.decay * this.frequency * 1000); + }, + + onTimerEvent: function() { + this.updater = new Ajax.Updater(this.container, this.url, this.options); + } +}); + +document.getElementsByClassName = function(className) { + var children = document.getElementsByTagName('*') || document.all; + var elements = new Array(); + + for (var i = 0; i < children.length; i++) { + var child = children[i]; + var classNames = child.className.split(' '); + for (var j = 0; j < classNames.length; j++) { + if (classNames[j] == className) { + elements.push(child); + break; + } + } + } + + return elements; +} + +/*--------------------------------------------------------------------------*/ + +if (!window.Element) { + var Element = new Object(); +} + +Object.extend(Element, { + toggle: function() { + for (var i = 0; i < arguments.length; i++) { + var element = $(arguments[i]); + element.style.display = + (element.style.display == 'none' ? '' : 'none'); + } + }, + + hide: function() { + for (var i = 0; i < arguments.length; i++) { + var element = $(arguments[i]); + element.style.display = 'none'; + } + }, + + show: function() { + for (var i = 0; i < arguments.length; i++) { + var element = $(arguments[i]); + element.style.display = ''; + } + }, + + remove: function(element) { + element = $(element); + element.parentNode.removeChild(element); + }, + + getHeight: function(element) { + element = $(element); + return element.offsetHeight; + }, + + hasClassName: function(element, className) { + element = $(element); + if (!element) + return; + var a = element.className.split(' '); + for (var i = 0; i < a.length; i++) { + if (a[i] == className) + return true; + } + return false; + }, + + addClassName: function(element, className) { + element = $(element); + Element.removeClassName(element, className); + element.className += ' ' + className; + }, + + removeClassName: function(element, className) { + element = $(element); + if (!element) + return; + var newClassName = ''; + var a = element.className.split(' '); + for (var i = 0; i < a.length; i++) { + if (a[i] != className) { + if (i > 0) + newClassName += ' '; + newClassName += a[i]; + } + } + element.className = newClassName; + }, + + // removes whitespace-only text node children + cleanWhitespace: function(element) { + var element = $(element); + for (var i = 0; i < element.childNodes.length; i++) { + var node = element.childNodes[i]; + if (node.nodeType == 3 && !/\S/.test(node.nodeValue)) + Element.remove(node); + } + } +}); + +var Toggle = new Object(); +Toggle.display = Element.toggle; + +/*--------------------------------------------------------------------------*/ + +Abstract.Insertion = function(adjacency) { + this.adjacency = adjacency; +} + +Abstract.Insertion.prototype = { + initialize: function(element, content) { + this.element = $(element); + this.content = content; + + if (this.adjacency && this.element.insertAdjacentHTML) { + this.element.insertAdjacentHTML(this.adjacency, this.content); + } else { + this.range = this.element.ownerDocument.createRange(); + if (this.initializeRange) this.initializeRange(); + this.fragment = this.range.createContextualFragment(this.content); + this.insertContent(); + } + } +} + +var Insertion = new Object(); + +Insertion.Before = Class.create(); +Insertion.Before.prototype = Object.extend(new Abstract.Insertion('beforeBegin'), { + initializeRange: function() { + this.range.setStartBefore(this.element); + }, + + insertContent: function() { + this.element.parentNode.insertBefore(this.fragment, this.element); + } +}); + +Insertion.Top = Class.create(); +Insertion.Top.prototype = Object.extend(new Abstract.Insertion('afterBegin'), { + initializeRange: function() { + this.range.selectNodeContents(this.element); + this.range.collapse(true); + }, + + insertContent: function() { + this.element.insertBefore(this.fragment, this.element.firstChild); + } +}); + +Insertion.Bottom = Class.create(); +Insertion.Bottom.prototype = Object.extend(new Abstract.Insertion('beforeEnd'), { + initializeRange: function() { + this.range.selectNodeContents(this.element); + this.range.collapse(this.element); + }, + + insertContent: function() { + this.element.appendChild(this.fragment); + } +}); + +Insertion.After = Class.create(); +Insertion.After.prototype = Object.extend(new Abstract.Insertion('afterEnd'), { + initializeRange: function() { + this.range.setStartAfter(this.element); + }, + + insertContent: function() { + this.element.parentNode.insertBefore(this.fragment, + this.element.nextSibling); + } +}); + +var Field = { + clear: function() { + for (var i = 0; i < arguments.length; i++) + $(arguments[i]).value = ''; + }, + + focus: function(element) { + $(element).focus(); + }, + + present: function() { + for (var i = 0; i < arguments.length; i++) + if ($(arguments[i]).value == '') return false; + return true; + }, + + select: function(element) { + $(element).select(); + }, + + activate: function(element) { + $(element).focus(); + $(element).select(); + } +} + +/*--------------------------------------------------------------------------*/ + +var Form = { + serialize: function(form) { + var elements = Form.getElements($(form)); + var queryComponents = new Array(); + + for (var i = 0; i < elements.length; i++) { + var queryComponent = Form.Element.serialize(elements[i]); + if (queryComponent) + queryComponents.push(queryComponent); + } + + return queryComponents.join('&'); + }, + + getElements: function(form) { + var form = $(form); + var elements = new Array(); + + for (tagName in Form.Element.Serializers) { + var tagElements = form.getElementsByTagName(tagName); + for (var j = 0; j < tagElements.length; j++) + elements.push(tagElements[j]); + } + return elements; + }, + + getInputs: function(form, typeName, name) { + var form = $(form); + var inputs = form.getElementsByTagName('input'); + + if (!typeName && !name) + return inputs; + + var matchingInputs = new Array(); + for (var i = 0; i < inputs.length; i++) { + var input = inputs[i]; + if ((typeName && input.type != typeName) || + (name && input.name != name)) + continue; + matchingInputs.push(input); + } + + return matchingInputs; + }, + + disable: function(form) { + var elements = Form.getElements(form); + for (var i = 0; i < elements.length; i++) { + var element = elements[i]; + element.blur(); + element.disabled = 'true'; + } + }, + + enable: function(form) { + var elements = Form.getElements(form); + for (var i = 0; i < elements.length; i++) { + var element = elements[i]; + element.disabled = ''; + } + }, + + focusFirstElement: function(form) { + var form = $(form); + var elements = Form.getElements(form); + for (var i = 0; i < elements.length; i++) { + var element = elements[i]; + if (element.type != 'hidden' && !element.disabled) { + Field.activate(element); + break; + } + } + }, + + reset: function(form) { + $(form).reset(); + } +} + +Form.Element = { + serialize: function(element) { + var element = $(element); + var method = element.tagName.toLowerCase(); + var parameter = Form.Element.Serializers[method](element); + + if (parameter) + return encodeURIComponent(parameter[0]) + '=' + + encodeURIComponent(parameter[1]); + }, + + getValue: function(element) { + var element = $(element); + var method = element.tagName.toLowerCase(); + var parameter = Form.Element.Serializers[method](element); + + if (parameter) + return parameter[1]; + } +} + +Form.Element.Serializers = { + input: function(element) { + switch (element.type.toLowerCase()) { + case 'submit': + case 'hidden': + case 'password': + case 'text': + return Form.Element.Serializers.textarea(element); + case 'checkbox': + case 'radio': + return Form.Element.Serializers.inputSelector(element); + } + return false; + }, + + inputSelector: function(element) { + if (element.checked) + return [element.name, element.value]; + }, + + textarea: function(element) { + return [element.name, element.value]; + }, + + select: function(element) { + var value = ''; + if (element.type == 'select-one') { + var index = element.selectedIndex; + if (index >= 0) + value = element.options[index].value || element.options[index].text; + } else { + value = new Array(); + for (var i = 0; i < element.length; i++) { + var opt = element.options[i]; + if (opt.selected) + value.push(opt.value || opt.text); + } + } + return [element.name, value]; + } +} + +/*--------------------------------------------------------------------------*/ + +var $F = Form.Element.getValue; + +/*--------------------------------------------------------------------------*/ + +Abstract.TimedObserver = function() {} +Abstract.TimedObserver.prototype = { + initialize: function(element, frequency, callback) { + this.frequency = frequency; + this.element = $(element); + this.callback = callback; + + this.lastValue = this.getValue(); + this.registerCallback(); + }, + + registerCallback: function() { + setInterval(this.onTimerEvent.bind(this), this.frequency * 1000); + }, + + onTimerEvent: function() { + var value = this.getValue(); + if (this.lastValue != value) { + this.callback(this.element, value); + this.lastValue = value; + } + } +} + +Form.Element.Observer = Class.create(); +Form.Element.Observer.prototype = Object.extend(new Abstract.TimedObserver(), { + getValue: function() { + return Form.Element.getValue(this.element); + } +}); + +Form.Observer = Class.create(); +Form.Observer.prototype = Object.extend(new Abstract.TimedObserver(), { + getValue: function() { + return Form.serialize(this.element); + } +}); + +/*--------------------------------------------------------------------------*/ + +Abstract.EventObserver = function() {} +Abstract.EventObserver.prototype = { + initialize: function(element, callback) { + this.element = $(element); + this.callback = callback; + + this.lastValue = this.getValue(); + if (this.element.tagName.toLowerCase() == 'form') + this.registerFormCallbacks(); + else + this.registerCallback(this.element); + }, + + onElementEvent: function() { + var value = this.getValue(); + if (this.lastValue != value) { + this.callback(this.element, value); + this.lastValue = value; + } + }, + + registerFormCallbacks: function() { + var elements = Form.getElements(this.element); + for (var i = 0; i < elements.length; i++) + this.registerCallback(elements[i]); + }, + + registerCallback: function(element) { + if (element.type) { + switch (element.type.toLowerCase()) { + case 'checkbox': + case 'radio': + element.target = this; + element.prev_onclick = element.onclick || Prototype.emptyFunction; + element.onclick = function() { + this.prev_onclick(); + this.target.onElementEvent(); + } + break; + case 'password': + case 'text': + case 'textarea': + case 'select-one': + case 'select-multiple': + element.target = this; + element.prev_onchange = element.onchange || Prototype.emptyFunction; + element.onchange = function() { + this.prev_onchange(); + this.target.onElementEvent(); + } + break; + } + } + } +} + +Form.Element.EventObserver = Class.create(); +Form.Element.EventObserver.prototype = Object.extend(new Abstract.EventObserver(), { + getValue: function() { + return Form.Element.getValue(this.element); + } +}); + +Form.EventObserver = Class.create(); +Form.EventObserver.prototype = Object.extend(new Abstract.EventObserver(), { + getValue: function() { + return Form.serialize(this.element); + } +}); + + +if (!window.Event) { + var Event = new Object(); +} + +Object.extend(Event, { + KEY_BACKSPACE: 8, + KEY_TAB: 9, + KEY_RETURN: 13, + KEY_ESC: 27, + KEY_LEFT: 37, + KEY_UP: 38, + KEY_RIGHT: 39, + KEY_DOWN: 40, + KEY_DELETE: 46, + + element: function(event) { + return event.target || event.srcElement; + }, + + isLeftClick: function(event) { + return (((event.which) && (event.which == 1)) || + ((event.button) && (event.button == 1))); + }, + + pointerX: function(event) { + return event.pageX || (event.clientX + + (document.documentElement.scrollLeft || document.body.scrollLeft)); + }, + + pointerY: function(event) { + return event.pageY || (event.clientY + + (document.documentElement.scrollTop || document.body.scrollTop)); + }, + + stop: function(event) { + if (event.preventDefault) { + event.preventDefault(); + event.stopPropagation(); + } else { + event.returnValue = false; + } + }, + + // find the first node with the given tagName, starting from the + // node the event was triggered on; traverses the DOM upwards + findElement: function(event, tagName) { + var element = Event.element(event); + while (element.parentNode && (!element.tagName || + (element.tagName.toUpperCase() != tagName.toUpperCase()))) + element = element.parentNode; + return element; + }, + + observers: false, + + _observeAndCache: function(element, name, observer, useCapture) { + if (!this.observers) this.observers = []; + if (element.addEventListener) { + this.observers.push([element, name, observer, useCapture]); + element.addEventListener(name, observer, useCapture); + } else if (element.attachEvent) { + this.observers.push([element, name, observer, useCapture]); + element.attachEvent('on' + name, observer); + } + }, + + unloadCache: function() { + if (!Event.observers) return; + for (var i = 0; i < Event.observers.length; i++) { + Event.stopObserving.apply(this, Event.observers[i]); + Event.observers[i][0] = null; + } + Event.observers = false; + }, + + observe: function(element, name, observer, useCapture) { + var element = $(element); + useCapture = useCapture || false; + + if (name == 'keypress' && + ((/Konqueror|Safari|KHTML/.test(navigator.userAgent)) + || element.attachEvent)) + name = 'keydown'; + + this._observeAndCache(element, name, observer, useCapture); + }, + + stopObserving: function(element, name, observer, useCapture) { + var element = $(element); + useCapture = useCapture || false; + + if (name == 'keypress' && + ((/Konqueror|Safari|KHTML/.test(navigator.userAgent)) + || element.detachEvent)) + name = 'keydown'; + + if (element.removeEventListener) { + element.removeEventListener(name, observer, useCapture); + } else if (element.detachEvent) { + element.detachEvent('on' + name, observer); + } + } +}); + +/* prevent memory leaks in IE */ +Event.observe(window, 'unload', Event.unloadCache, false); + +var Position = { + + // set to true if needed, warning: firefox performance problems + // NOT neeeded for page scrolling, only if draggable contained in + // scrollable elements + includeScrollOffsets: false, + + // must be called before calling withinIncludingScrolloffset, every time the + // page is scrolled + prepare: function() { + this.deltaX = window.pageXOffset + || document.documentElement.scrollLeft + || document.body.scrollLeft + || 0; + this.deltaY = window.pageYOffset + || document.documentElement.scrollTop + || document.body.scrollTop + || 0; + }, + + realOffset: function(element) { + var valueT = 0, valueL = 0; + do { + valueT += element.scrollTop || 0; + valueL += element.scrollLeft || 0; + element = element.parentNode; + } while (element); + return [valueL, valueT]; + }, + + cumulativeOffset: function(element) { + var valueT = 0, valueL = 0; + do { + valueT += element.offsetTop || 0; + valueL += element.offsetLeft || 0; + element = element.offsetParent; + } while (element); + return [valueL, valueT]; + }, + + // caches x/y coordinate pair to use with overlap + within: function(element, x, y) { + if (this.includeScrollOffsets) + return this.withinIncludingScrolloffsets(element, x, y); + this.xcomp = x; + this.ycomp = y; + this.offset = this.cumulativeOffset(element); + + return (y >= this.offset[1] && + y < this.offset[1] + element.offsetHeight && + x >= this.offset[0] && + x < this.offset[0] + element.offsetWidth); + }, + + withinIncludingScrolloffsets: function(element, x, y) { + var offsetcache = this.realOffset(element); + + this.xcomp = x + offsetcache[0] - this.deltaX; + this.ycomp = y + offsetcache[1] - this.deltaY; + this.offset = this.cumulativeOffset(element); + + return (this.ycomp >= this.offset[1] && + this.ycomp < this.offset[1] + element.offsetHeight && + this.xcomp >= this.offset[0] && + this.xcomp < this.offset[0] + element.offsetWidth); + }, + + // within must be called directly before + overlap: function(mode, element) { + if (!mode) return 0; + if (mode == 'vertical') + return ((this.offset[1] + element.offsetHeight) - this.ycomp) / + element.offsetHeight; + if (mode == 'horizontal') + return ((this.offset[0] + element.offsetWidth) - this.xcomp) / + element.offsetWidth; + }, + + clone: function(source, target) { + source = $(source); + target = $(target); + target.style.position = 'absolute'; + var offsets = this.cumulativeOffset(source); + target.style.top = offsets[1] + 'px'; + target.style.left = offsets[0] + 'px'; + target.style.width = source.offsetWidth + 'px'; + target.style.height = source.offsetHeight + 'px'; + } +} diff --git a/zookeeper-docs/src/main/resources/markdown/skin/screen.css b/zookeeper-docs/src/main/resources/markdown/skin/screen.css new file mode 100644 index 000000000..9ce32c292 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/skin/screen.css @@ -0,0 +1,531 @@ +/* +* Licensed to the Apache Software Foundation (ASF) under one or more +* contributor license agreements. See the NOTICE file distributed with +* this work for additional information regarding copyright ownership. +* The ASF licenses this file to You 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. +*/ +body { margin: 0px 0px 0px 0px; font-family: Verdana, Helvetica, sans-serif; } + +h1 { font-size : 160%; margin: 0px 0px 0px 0px; padding: 0px; } +h2 { font-size : 140%; margin: 1em 0px 0.8em 0px; padding: 0px; font-weight : bold;} +h3 { font-size : 130%; margin: 0.8em 0px 0px 0px; padding: 0px; font-weight : bold; } +.h3 { margin: 22px 0px 3px 0px; } +h4 { font-size : 120%; margin: 0.7em 0px 0px 0px; padding: 0px; font-weight : normal; text-align: left; } +.h4 { margin: 18px 0px 0px 0px; } +h4.faq { font-size : 120%; margin: 18px 0px 0px 0px; padding: 0px; font-weight : bold; text-align: left; } +h5 { font-size : 100%; margin: 14px 0px 0px 0px; padding: 0px; font-weight : normal; text-align: left; } + +/** +* table +*/ +table .title { background-color: #000000; } +.ForrestTable { + color: #ffffff; + background-color: #7099C5; + width: 100%; + font-size : 100%; + empty-cells: show; +} +table caption { + padding-left: 5px; + color: white; + text-align: left; + font-weight: bold; + background-color: #000000; +} +.ForrestTable td { + color: black; + background-color: #f0f0ff; +} +.ForrestTable th { text-align: center; } +/** + * Page Header + */ + +#top { + position: relative; + float: left; + width: 100%; + background: #294563; /* if you want a background in the header, put it here */ +} + +#top .breadtrail { + background: #CFDCED; + color: black; + border-bottom: solid 1px white; + padding: 3px 10px; + font-size: 75%; +} +#top .breadtrail a { color: black; } + +#top .header { + float: left; + width: 100%; + background: url("header_white_line.gif") repeat-x bottom; +} + +#top .grouplogo { + padding: 7px 0 10px 10px; + float: left; + text-align: left; +} +#top .projectlogo { + padding: 7px 0 10px 10px; + float: left; + width: 33%; + text-align: right; +} +#top .projectlogoA1 { + padding: 7px 0 10px 10px; + float: right; +} +html>body #top .searchbox { + bottom: 0px; +} +#top .searchbox { + position: absolute; + right: 10px; + height: 42px; + font-size: 70%; + white-space: nowrap; + bottom: -1px; /* compensate for IE rendering issue */ + border-radius: 5px 5px 0px 0px; +} + +#top .searchbox form { + padding: 5px 10px; + margin: 0; +} +#top .searchbox p { + padding: 0 0 2px 0; + margin: 0; +} +#top .searchbox input { + font-size: 100%; +} + +#tabs { + clear: both; + padding-left: 10px; + margin: 0; + list-style: none; +} + +#tabs li { + float: left; + margin: 0 3px 0 0; + padding: 0; + border-radius: 5px 5px 0px 0px; +} + +/*background: url("tab-left.gif") no-repeat left top;*/ +#tabs li a { + float: left; + display: block; + font-family: verdana, arial, sans-serif; + text-decoration: none; + color: black; + white-space: nowrap; + padding: 5px 15px 4px; + width: .1em; /* IE/Win fix */ +} + +#tabs li a:hover { + + cursor: pointer; + text-decoration:underline; +} + +#tabs > li a { width: auto; } /* Rest of IE/Win fix */ + +/* Commented Backslash Hack hides rule from IE5-Mac \*/ +#tabs a { float: none; } +/* End IE5-Mac hack */ + +#top .header .current { + background-color: #4C6C8F; +} +#top .header .current a { + font-weight: bold; + padding-bottom: 5px; + color: white; +} +#publishedStrip { + padding-right: 10px; + padding-left: 20px; + padding-top: 3px; + padding-bottom:3px; + color: #ffffff; + font-size : 60%; + font-weight: bold; + background-color: #4C6C8F; + text-align:right; +} + +#level2tabs { +margin: 0; +float:left; +position:relative; + +} + + + +#level2tabs a:hover { + + cursor: pointer; + text-decoration:underline; + +} + +#level2tabs a{ + + cursor: pointer; + text-decoration:none; + background-image: url('chapter.gif'); + background-repeat: no-repeat; + background-position: center left; + padding-left: 6px; + margin-left: 6px; +} + +/* +* border-top: solid #4C6C8F 15px; +*/ +#main { + position: relative; + background: white; + clear:both; +} +#main .breadtrail { + clear:both; + position: relative; + background: #CFDCED; + color: black; + border-bottom: solid 1px black; + border-top: solid 1px black; + padding: 0px 180px; + font-size: 75%; + z-index:10; +} + +img.corner { + width: 15px; + height: 15px; + border: none; + display: block !important; +} + +img.cornersmall { + width: 5px; + height: 5px; + border: none; + display: block !important; +} +/** + * Side menu + */ +#menu a { font-weight: normal; text-decoration: none;} +#menu a:visited { font-weight: normal; } +#menu a:active { font-weight: normal; } +#menu a:hover { font-weight: normal; text-decoration:underline;} + +#menuarea { width:10em;} +#menu { + position: relative; + float: left; + width: 160px; + padding-top: 0px; + padding-bottom: 15px; + top:-18px; + left:10px; + z-index: 20; + background-color: #f90; + font-size : 70%; + border-radius: 0px 0px 15px 15px; +} + +.menutitle { + cursor:pointer; + padding: 3px 12px; + margin-left: 10px; + background-image: url('chapter.gif'); + background-repeat: no-repeat; + background-position: center left; + font-weight : bold; +} + +.menutitle.selected { + background-image: url('chapter_open.gif'); +} + +.menutitle:hover{text-decoration:underline;cursor: pointer;} + +#menu .menuitemgroup { + margin: 0px 0px 6px 8px; + padding: 0px; + font-weight : bold; } + +#menu .selectedmenuitemgroup{ + margin: 0px 0px 0px 8px; + padding: 0px; + font-weight : normal; + + } + +#menu .menuitem { + padding: 2px 0px 1px 13px; + background-image: url('page.gif'); + background-repeat: no-repeat; + background-position: center left; + font-weight : normal; + margin-left: 10px; +} + +#menu .selected { + font-style : normal; + margin-right: 10px; + +} +.menuitem .selected { + border-style: solid; + border-width: 1px; +} +#menu .menupageitemgroup { + padding: 3px 0px 4px 6px; + font-style : normal; + border-bottom: 1px solid ; + border-left: 1px solid ; + border-right: 1px solid ; + margin-right: 10px; +} +#menu .menupageitem { + font-style : normal; + font-weight : normal; + border-width: 0px; + font-size : 90%; +} +#menu .searchbox { + text-align: center; +} +#menu .searchbox form { + padding: 3px 3px; + margin: 0; +} +#menu .searchbox input { + font-size: 100%; +} + +#content { + padding: 20px 20px 20px 180px; + margin: 0; + font : small Verdana, Helvetica, sans-serif; + font-size : 80%; +} + +#content ul { + margin: 0; + padding: 0 25px; +} +#content li { + padding: 0 5px; +} +#feedback { + color: black; + background: #CFDCED; + text-align:center; + margin-top: 5px; +} +#feedback #feedbackto { + font-size: 90%; + color: black; +} +#footer { + clear: both; + position: relative; /* IE bugfix (http://www.dracos.co.uk/web/css/ie6floatbug/) */ + width: 100%; + background: #CFDCED; + border-top: solid 1px #4C6C8F; + color: black; +} +#footer .copyright { + position: relative; /* IE bugfix cont'd */ + padding: 5px; + margin: 0; + width: 60%; +} +#footer .lastmodified { + position: relative; /* IE bugfix cont'd */ + float: right; + width: 30%; + padding: 5px; + margin: 0; + text-align: right; +} +#footer a { color: white; } + +#footer #logos { + text-align: left; +} + + +/** + * Misc Styles + */ + +acronym { cursor: help; } +.boxed { background-color: #a5b6c6;} +.underlined_5 {border-bottom: solid 5px #4C6C8F;} +.underlined_10 {border-bottom: solid 10px #4C6C8F;} +/* ==================== snail trail ============================ */ + +.trail { + position: relative; /* IE bugfix cont'd */ + font-size: 70%; + text-align: right; + float: right; + margin: -10px 5px 0px 5px; + padding: 0; +} + +#motd-area { + position:relative; + float:right; + width: 35%; + background-color: #f0f0ff; + border: solid 1px #4C6C8F; + margin: 0px 0px 10px 10px; + padding: 5px; +} + +#minitoc-area { + border-top: solid 1px #4C6C8F; + border-bottom: solid 1px #4C6C8F; + margin: 15px 10% 5px 15px; + /* margin-bottom: 15px; + margin-left: 15px; + margin-right: 10%;*/ + padding-bottom: 7px; + padding-top: 5px; +} +.minitoc { + list-style-image: url('current.gif'); + font-weight: normal; +} + +.abstract{ + text-align:justify; + } + +li p { + margin: 0; + padding: 0; +} + +.pdflink { + position: relative; /* IE bugfix cont'd */ + float: right; + margin: 0px 5px; + padding: 0; +} +.pdflink br { + margin-top: -10px; + padding-left: 1px; +} +.pdflink a { + display: block; + font-size: 70%; + text-align: center; + margin: 0; + padding: 0; +} + +.pdflink img { + display: block; + height: 16px; + width: 16px; +} +.xmllink { + position: relative; /* IE bugfix cont'd */ + float: right; + margin: 0px 5px; + padding: 0; +} +.xmllink br { + margin-top: -10px; + padding-left: 1px; +} +.xmllink a { + display: block; + font-size: 70%; + text-align: center; + margin: 0; + padding: 0; +} + +.xmllink img { + display: block; + height: 16px; + width: 16px; +} +.podlink { + position: relative; /* IE bugfix cont'd */ + float: right; + margin: 0px 5px; + padding: 0; +} +.podlink br { + margin-top: -10px; + padding-left: 1px; +} +.podlink a { + display: block; + font-size: 70%; + text-align: center; + margin: 0; + padding: 0; +} + +.podlink img { + display: block; + height: 16px; + width: 16px; +} + +.printlink { + position: relative; /* IE bugfix cont'd */ + float: right; +} +.printlink br { + margin-top: -10px; + padding-left: 1px; +} +.printlink a { + display: block; + font-size: 70%; + text-align: center; + margin: 0; + padding: 0; +} +.printlink img { + display: block; + height: 16px; + width: 16px; +} + +p.instruction { + display: list-item; + list-style-image: url('../instruction_arrow.png'); + list-style-position: outside; + margin-left: 2em; +}
\ No newline at end of file diff --git a/zookeeper-docs/src/main/resources/markdown/zookeeperAdmin.md b/zookeeper-docs/src/main/resources/markdown/zookeeperAdmin.md new file mode 100644 index 000000000..8ca1f8312 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/zookeeperAdmin.md @@ -0,0 +1,1270 @@ +<!-- +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. +//--> + +# ZooKeeper Administrator's Guide + +### A Guide to Deployment and Administration + +* [Deployment](#ch_deployment) + * [System Requirements](#sc_systemReq) + * [Supported Platforms](#sc_supportedPlatforms) + * [Required Software](#sc_requiredSoftware) + * [Clustered (Multi-Server) Setup](#sc_zkMulitServerSetup) + * [Single Server and Developer Setup](#sc_singleAndDevSetup) +* [Administration](#ch_administration) + * [Designing a ZooKeeper Deployment](#sc_designing) + * [Cross Machine Requirements](#sc_CrossMachineRequirements) + * [Single Machine Requirements](#Single+Machine+Requirements) + * [Provisioning](#sc_provisioning) + * [Things to Consider: ZooKeeper Strengths and Limitations](#sc_strengthsAndLimitations) + * [Administering](#sc_administering) + * [Maintenance](#sc_maintenance) + * [Ongoing Data Directory Cleanup](#Ongoing+Data+Directory+Cleanup) + * [Debug Log Cleanup (log4j)](#Debug+Log+Cleanup+%28log4j%29) + * [Supervision](#sc_supervision) + * [Monitoring](#sc_monitoring) + * [Logging](#sc_logging) + * [Troubleshooting](#sc_troubleshooting) + * [Configuration Parameters](#sc_configuration) + * [Minimum Configuration](#sc_minimumConfiguration) + * [Advanced Configuration](#sc_advancedConfiguration) + * [Cluster Options](#sc_clusterOptions) + * [Authentication and Authorization Options](#sc_authOptions) + * [Experimental Options/Features](#Experimental+Options%2FFeatures) + * [Unsafe Options](#Unsafe+Options) + * [Communication using the Netty framework](#Communication+using+the+Netty+framework) + * [ZooKeeper Commands: The Four Letter Words](#sc_zkCommands) + * [Data File Management](#sc_dataFileManagement) + * [The Data Directory](#The+Data+Directory) + * [The Log Directory](#The+Log+Directory) + * [File Management](#sc_filemanagement) + * [Recovery - TxnLogToolkit](#Recovery+-+TxnLogToolkit) + * [Things to Avoid](#sc_commonProblems) + * [Best Practices](#sc_bestPractices) + +<a name="ch_deployment"></a> + +## Deployment + +This section contains information about deploying Zookeeper and +covers these topics: + +* [System Requirements](#sc_systemReq) +* [Clustered (Multi-Server) Setup](#sc_zkMulitServerSetup) +* [Single Server and Developer Setup](#sc_singleAndDevSetup) + +The first two sections assume you are interested in installing +ZooKeeper in a production environment such as a datacenter. The final +section covers situations in which you are setting up ZooKeeper on a +limited basis - for evaluation, testing, or development - but not in a +production environment. + +<a name="sc_systemReq"></a> + +### System Requirements + +<a name="sc_supportedPlatforms"></a> + +#### Supported Platforms + +ZooKeeper consists of multiple components. Some components are +supported broadly, and other components are supported only on a smaller +set of platforms. + +* **Client** is the Java client + library, used by applications to connect to a ZooKeeper ensemble. +* **Server** is the Java server + that runs on the ZooKeeper ensemble nodes. +* **Native Client** is a client + implemented in C, similar to the Java client, used by applications + to connect to a ZooKeeper ensemble. +* **Contrib** refers to multiple + optional add-on components. + +The following matrix describes the level of support committed for +running each component on different operating system platforms. + +##### Support Matrix + +| Operating System | Client | Server | Native Client | Contrib | +|------------------|--------|--------|---------------|---------| +| GNU/Linux | Development and Production | Development and Production | Development and Production | Development and Production | +| Solaris | Development and Production | Development and Production | Not Supported | Not Supported | +| FreeBSD | Development and Production | Development and Production | Not Supported | Not Supported | +| Windows | Development and Production | Development and Production | Not Supported | Not Supported | +| Mac OS X | Development Only | Development Only | Not Supported | Not Supported | + +For any operating system not explicitly mentioned as supported in +the matrix, components may or may not work. The ZooKeeper community +will fix obvious bugs that are reported for other platforms, but there +is no full support. + +<a name="sc_requiredSoftware"></a> + +#### Required Software + +ZooKeeper runs in Java, release 1.7 or greater (JDK 7 or +greater, FreeBSD support requires openjdk7). It runs as an +_ensemble_ of ZooKeeper servers. Three +ZooKeeper servers is the minimum recommended size for an +ensemble, and we also recommend that they run on separate +machines. At Yahoo!, ZooKeeper is usually deployed on +dedicated RHEL boxes, with dual-core processors, 2GB of RAM, +and 80GB IDE hard drives. + +<a name="sc_zkMulitServerSetup"></a> + +### Clustered (Multi-Server) Setup + +For reliable ZooKeeper service, you should deploy ZooKeeper in a +cluster known as an _ensemble_. As long as a majority +of the ensemble are up, the service will be available. Because Zookeeper +requires a majority, it is best to use an +odd number of machines. For example, with four machines ZooKeeper can +only handle the failure of a single machine; if two machines fail, the +remaining two machines do not constitute a majority. However, with five +machines ZooKeeper can handle the failure of two machines. + +######Note +>As mentioned in the +[ZooKeeper Getting Started Guide](zookeeperStarted.html) +, a minimum of three servers are required for a fault tolerant +clustered setup, and it is strongly recommended that you have an +odd number of servers. + +>Usually three servers is more than enough for a production +install, but for maximum reliability during maintenance, you may +wish to install five servers. With three servers, if you perform +maintenance on one of them, you are vulnerable to a failure on one +of the other two servers during that maintenance. If you have five +of them running, you can take one down for maintenance, and know +that you're still OK if one of the other four suddenly fails. + +>Your redundancy considerations should include all aspects of +your environment. If you have three ZooKeeper servers, but their +network cables are all plugged into the same network switch, then +the failure of that switch will take down your entire ensemble. + +Here are the steps to setting a server that will be part of an +ensemble. These steps should be performed on every host in the +ensemble: + +1. Install the Java JDK. You can use the native packaging system + for your system, or download the JDK from: + [http://java.sun.com/javase/downloads/index.jsp](http://java.sun.com/javase/downloads/index.jsp) + +2. Set the Java heap size. This is very important to avoid + swapping, which will seriously degrade ZooKeeper performance. To + determine the correct value, use load tests, and make sure you are + well below the usage limit that would cause you to swap. Be + conservative - use a maximum heap size of 3GB for a 4GB + machine. + +3. Install the ZooKeeper Server Package. It can be downloaded + from: + [http://zookeeper.apache.org/releases.html](http://zookeeper.apache.org/releases.html) + +4. Create a configuration file. This file can be called anything. + Use the following settings as a starting point: + + tickTime=2000 + dataDir=/var/lib/zookeeper/ + clientPort=2181 + initLimit=5 + syncLimit=2 + server.1=zoo1:2888:3888 + server.2=zoo2:2888:3888 + server.3=zoo3:2888:3888 + + You can find the meanings of these and other configuration + settings in the section [Configuration Parameters](#sc_configuration). A word + though about a few here: + Every machine that is part of the ZooKeeper ensemble should know + about every other machine in the ensemble. You accomplish this with + the series of lines of the form **server.id=host:port:port**. The parameters **host** and **port** are straightforward. You attribute the + server id to each machine by creating a file named + *myid*, one for each server, which resides in + that server's data directory, as specified by the configuration file + parameter **dataDir**. + +5. The myid file + consists of a single line containing only the text of that machine's + id. So *myid* of server 1 would contain the text + "1" and nothing else. The id must be unique within the + ensemble and should have a value between 1 and 255. + **IMPORTANT:** if you enable extended features such + as TTL Nodes (see below) the id must be between 1 + and 254 due to internal limitations. + +6. If your configuration file is set up, you can start a + ZooKeeper server: + + $ java -cp zookeeper.jar:lib/slf4j-api-1.7.5.jar:lib/slf4j-log4j12-1.7.5.jar:lib/log4j-1.2.17.jar:conf \\ + org.apache.zookeeper.server.quorum.QuorumPeerMain zoo.cfg + + QuorumPeerMain starts a ZooKeeper server, + [JMX](http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/) + management beans are also registered which allows + management through a JMX management console. + The [ZooKeeper JMX document](zookeeperJMX.html) contains details on managing ZooKeeper with JMX. + See the script _bin/zkServer.sh_, + which is included in the release, for an example + of starting server instances. + +7. Test your deployment by connecting to the hosts: + In Java, you can run the following command to execute + simple operations: + + $ bin/zkCli.sh -server 127.0.0.1:2181 + +<a name="sc_singleAndDevSetup"></a> + +### Single Server and Developer Setup + +If you want to setup ZooKeeper for development purposes, you will +probably want to setup a single server instance of ZooKeeper, and then +install either the Java or C client-side libraries and bindings on your +development machine. + +The steps to setting up a single server instance are the similar +to the above, except the configuration file is simpler. You can find the +complete instructions in the [Installing and +Running ZooKeeper in Single Server Mode](zookeeperStarted.html#sc_InstallingSingleMode) section of the [ZooKeeper Getting Started +Guide](zookeeperStarted.html). + +For information on installing the client side libraries, refer to +the [Bindings](zookeeperProgrammers.html#ch_bindings) +section of the [ZooKeeper +Programmer's Guide](zookeeperProgrammers.html). + +<a name="ch_administration"></a> + +## Administration + +This section contains information about running and maintaining +ZooKeeper and covers these topics: + +* [Designing a ZooKeeper Deployment](#sc_designing) +* [Provisioning](#sc_provisioning) +* [Things to Consider: ZooKeeper Strengths and Limitations](#sc_strengthsAndLimitations) +* [Administering](#sc_administering) +* [Maintenance](#sc_maintenance) +* [Supervision](#sc_supervision) +* [Monitoring](#sc_monitoring) +* [Logging](#sc_logging) +* [Troubleshooting](#sc_troubleshooting) +* [Configuration Parameters](#sc_configuration) +* [ZooKeeper Commands: The Four Letter Words](#sc_zkCommands) +* [Data File Management](#sc_dataFileManagement) +* [Things to Avoid](#sc_commonProblems) +* [Best Practices](#sc_bestPractices) + +<a name="sc_designing"></a> + +### Designing a ZooKeeper Deployment + +The reliability of ZooKeeper rests on two basic assumptions. + +1. Only a minority of servers in a deployment + will fail. _Failure_ in this context + means a machine crash, or some error in the network that + partitions a server off from the majority. +1. Deployed machines operate correctly. To + operate correctly means to execute code correctly, to have + clocks that work properly, and to have storage and network + components that perform consistently. + +The sections below contain considerations for ZooKeeper +administrators to maximize the probability for these assumptions +to hold true. Some of these are cross-machines considerations, +and others are things you should consider for each and every +machine in your deployment. + +<a name="sc_CrossMachineRequirements"></a> + +#### Cross Machine Requirements + +For the ZooKeeper service to be active, there must be a +majority of non-failing machines that can communicate with +each other. To create a deployment that can tolerate the +failure of F machines, you should count on deploying 2xF+1 +machines. Thus, a deployment that consists of three machines +can handle one failure, and a deployment of five machines can +handle two failures. Note that a deployment of six machines +can only handle two failures since three machines is not a +majority. For this reason, ZooKeeper deployments are usually +made up of an odd number of machines. + +To achieve the highest probability of tolerating a failure +you should try to make machine failures independent. For +example, if most of the machines share the same switch, +failure of that switch could cause a correlated failure and +bring down the service. The same holds true of shared power +circuits, cooling systems, etc. + +<a name="Single+Machine+Requirements"></a> + +#### Single Machine Requirements + +If ZooKeeper has to contend with other applications for +access to resources like storage media, CPU, network, or +memory, its performance will suffer markedly. ZooKeeper has +strong durability guarantees, which means it uses storage +media to log changes before the operation responsible for the +change is allowed to complete. You should be aware of this +dependency then, and take great care if you want to ensure +that ZooKeeper operations aren’t held up by your media. Here +are some things you can do to minimize that sort of +degradation: + +* ZooKeeper's transaction log must be on a dedicated + device. (A dedicated partition is not enough.) ZooKeeper + writes the log sequentially, without seeking Sharing your + log device with other processes can cause seeks and + contention, which in turn can cause multi-second + delays. +* Do not put ZooKeeper in a situation that can cause a + swap. In order for ZooKeeper to function with any sort of + timeliness, it simply cannot be allowed to swap. + Therefore, make certain that the maximum heap size given + to ZooKeeper is not bigger than the amount of real memory + available to ZooKeeper. For more on this, see + [Things to Avoid](#sc_commonProblems) + below. + +<a name="sc_provisioning"></a> + +### Provisioning + +<a name="sc_strengthsAndLimitations"></a> + +### Things to Consider: ZooKeeper Strengths and Limitations + +<a name="sc_administering"></a> + +### Administering + +<a name="sc_maintenance"></a> + +### Maintenance + +Little long term maintenance is required for a ZooKeeper +cluster however you must be aware of the following: + +<a name="Ongoing+Data+Directory+Cleanup"></a> + +#### Ongoing Data Directory Cleanup + +The ZooKeeper [Data +Directory](#var_datadir) contains files which are a persistent copy +of the znodes stored by a particular serving ensemble. These +are the snapshot and transactional log files. As changes are +made to the znodes these changes are appended to a +transaction log. Occasionally, when a log grows large, a +snapshot of the current state of all znodes will be written +to the filesystem and a new transaction log file is created +for future transactions. During snapshotting, ZooKeeper may +continue appending incoming transactions to the old log file. +Therefore, some transactions which are newer than a snapshot +may be found in the last transaction log preceding the +snapshot. + +A ZooKeeper server **will not remove +old snapshots and log files** when using the default +configuration (see autopurge below), this is the +responsibility of the operator. Every serving environment is +different and therefore the requirements of managing these +files may differ from install to install (backup for example). + +The PurgeTxnLog utility implements a simple retention +policy that administrators can use. The [API docs](index.html) contains details on +calling conventions (arguments, etc...). + +In the following example the last count snapshots and +their corresponding logs are retained and the others are +deleted. The value of <count> should typically be +greater than 3 (although not required, this provides 3 backups +in the unlikely event a recent log has become corrupted). This +can be run as a cron job on the ZooKeeper server machines to +clean up the logs daily. + + java -cp zookeeper.jar:lib/slf4j-api-1.7.5.jar:lib/slf4j-log4j12-1.7.5.jar:lib/log4j-1.2.17.jar:conf org.apache.zookeeper.server.PurgeTxnLog <dataDir> <snapDir> -n <count> + + +Automatic purging of the snapshots and corresponding +transaction logs was introduced in version 3.4.0 and can be +enabled via the following configuration parameters **autopurge.snapRetainCount** and **autopurge.purgeInterval**. For more on +this, see [Advanced Configuration](#sc_advancedConfiguration) +below. + +<a name="Debug+Log+Cleanup+%28log4j%29"></a> + +#### Debug Log Cleanup (log4j) + +See the section on [logging](#sc_logging) in this document. It is +expected that you will setup a rolling file appender using the +in-built log4j feature. The sample configuration file in the +release tar's conf/log4j.properties provides an example of +this. + +<a name="sc_supervision"></a> + +### Supervision + +You will want to have a supervisory process that manages +each of your ZooKeeper server processes (JVM). The ZK server is +designed to be "fail fast" meaning that it will shutdown +(process exit) if an error occurs that it cannot recover +from. As a ZooKeeper serving cluster is highly reliable, this +means that while the server may go down the cluster as a whole +is still active and serving requests. Additionally, as the +cluster is "self healing" the failed server once restarted will +automatically rejoin the ensemble w/o any manual +interaction. + +Having a supervisory process such as [daemontools](http://cr.yp.to/daemontools.html) or +[SMF](http://en.wikipedia.org/wiki/Service\_Management\_Facility) +(other options for supervisory process are also available, it's +up to you which one you would like to use, these are just two +examples) managing your ZooKeeper server ensures that if the +process does exit abnormally it will automatically be restarted +and will quickly rejoin the cluster. + +<a name="sc_monitoring"></a> + +### Monitoring + +The ZooKeeper service can be monitored in one of two +primary ways; 1) the command port through the use of [4 letter words](#sc_zkCommands) and 2) [JMX](zookeeperJMX.html). See the appropriate section for +your environment/requirements. + +<a name="sc_logging"></a> + +### Logging + +ZooKeeper uses **log4j** version 1.2 as its logging infrastructure. +The ZooKeeper default `log4j.properties` file resides in the `conf` +directory. Log4j requires that `log4j.properties` either be in the +working directory (the directory from which ZooKeeper is run) or be accessible from the classpath. + +For more information, see +[Log4j Default Initialization Procedure](http://logging.apache.org/log4j/1.2/manual.html#defaultInit) of the log4j manual. + +<a name="sc_troubleshooting"></a> + +### Troubleshooting + +* *Server not coming up because of file corruption* : + A server might not be able to read its database and fail to come up because of + some file corruption in the transaction logs of the ZooKeeper server. You will + see some IOException on loading ZooKeeper database. In such a case, + make sure all the other servers in your ensemble are up and working. Use "stat" + command on the command port to see if they are in good health. After you have verified that + all the other servers of the ensemble are up, you can go ahead and clean the database + of the corrupt server. Delete all the files in datadir/version-2 and datalogdir/version-2/. + Restart the server. + +<a name="sc_configuration"></a> + +### Configuration Parameters + +ZooKeeper's behavior is governed by the ZooKeeper configuration +file. This file is designed so that the exact same file can be used by +all the servers that make up a ZooKeeper server assuming the disk +layouts are the same. If servers use different configuration files, care +must be taken to ensure that the list of servers in all of the different +configuration files match. + +<a name="sc_minimumConfiguration"></a> + +#### Minimum Configuration + +Here are the minimum configuration keywords that must be defined +in the configuration file: + +* *clientPort* : + the port to listen for client connections; that is, the + port that clients attempt to connect to. + +* *dataDir* : + the location where ZooKeeper will store the in-memory + database snapshots and, unless specified otherwise, the + transaction log of updates to the database. + ######Note + >Be careful where you put the transaction log. A + dedicated transaction log device is key to consistent good + performance. Putting the log on a busy device will adversely + effect performance. + +* *tickTime* : + the length of a single tick, which is the basic time unit + used by ZooKeeper, as measured in milliseconds. It is used to + regulate heartbeats, and timeouts. For example, the minimum + session timeout will be two ticks. + +<a name="sc_advancedConfiguration"></a> + +#### Advanced Configuration + +The configuration settings in the section are optional. You can +use them to further fine tune the behaviour of your ZooKeeper servers. +Some can also be set using Java system properties, generally of the +form _zookeeper.keyword_. The exact system +property, when available, is noted below. + +* *dataLogDir* : + (No Java system property) + This option will direct the machine to write the + transaction log to the **dataLogDir** rather than the **dataDir**. This allows a dedicated log + device to be used, and helps avoid competition between logging + and snapshots. + ######Note + >Having a dedicated log device has a large impact on + throughput and stable latencies. It is highly recommended to + dedicate a log device and set **dataLogDir** to point to a directory on + that device, and then make sure to point **dataDir** to a directory + _not_ residing on that device. + +* *globalOutstandingLimit* : + (Java system property: **zookeeper.globalOutstandingLimit.**) + Clients can submit requests faster than ZooKeeper can + process them, especially if there are a lot of clients. To + prevent ZooKeeper from running out of memory due to queued + requests, ZooKeeper will throttle clients so that there is no + more than globalOutstandingLimit outstanding requests in the + system. The default limit is 1,000. + +* *preAllocSize* : + (Java system property: **zookeeper.preAllocSize**) + To avoid seeks ZooKeeper allocates space in the + transaction log file in blocks of preAllocSize kilobytes. The + default block size is 64M. One reason for changing the size of + the blocks is to reduce the block size if snapshots are taken + more often. (Also, see **snapCount**). + +* *snapCount* : + (Java system property: **zookeeper.snapCount**) + ZooKeeper records its transactions using snapshots and + a transaction log (think write-ahead log).The number of + transactions recorded in the transaction log before a snapshot + can be taken (and the transaction log rolled) is determined + by snapCount. In order to prevent all of the machines in the quorum + from taking a snapshot at the same time, each ZooKeeper server + will take a snapshot when the number of transactions in the transaction log + reaches a runtime generated random value in the \[snapCount/2+1, snapCount] + range.The default snapCount is 100,000. + +* *maxClientCnxns* : + (No Java system property) + Limits the number of concurrent connections (at the socket + level) that a single client, identified by IP address, may make + to a single member of the ZooKeeper ensemble. This is used to + prevent certain classes of DoS attacks, including file + descriptor exhaustion. The default is 60. Setting this to 0 + entirely removes the limit on concurrent connections. + +* *clientPortAddress* : + **New in 3.3.0:** the + address (ipv4, ipv6 or hostname) to listen for client + connections; that is, the address that clients attempt + to connect to. This is optional, by default we bind in + such a way that any connection to the **clientPort** for any + address/interface/nic on the server will be + accepted. + +* *minSessionTimeout* : + (No Java system property) + **New in 3.3.0:** the + minimum session timeout in milliseconds that the server + will allow the client to negotiate. Defaults to 2 times + the **tickTime**. + +* *maxSessionTimeout* : + (No Java system property) + **New in 3.3.0:** the + maximum session timeout in milliseconds that the server + will allow the client to negotiate. Defaults to 20 times + the **tickTime**. + +* *fsync.warningthresholdms* : + (Java system property: **zookeeper.fsync.warningthresholdms**) + **New in 3.3.4:** A + warning message will be output to the log whenever an + fsync in the Transactional Log (WAL) takes longer than + this value. The values is specified in milliseconds and + defaults to 1000. This value can only be set as a + system property. + +* *autopurge.snapRetainCount* : + (No Java system property) + **New in 3.4.0:** + When enabled, ZooKeeper auto purge feature retains + the **autopurge.snapRetainCount** most + recent snapshots and the corresponding transaction logs in the + **dataDir** and **dataLogDir** respectively and deletes the rest. + Defaults to 3. Minimum value is 3. + +* *autopurge.purgeInterval* : + (No Java system property) + **New in 3.4.0:** The + time interval in hours for which the purge task has to + be triggered. Set to a positive integer (1 and above) + to enable the auto purging. Defaults to 0. + +* *syncEnabled* : + (Java system property: **zookeeper.observer.syncEnabled**) + **New in 3.4.6:** + The observers now log transaction and write snapshot to disk + by default like the participants. This reduces the recovery time + of the observers on restart. Set to "false" to disable this + feature. Default is "true" + +<a name="sc_clusterOptions"></a> + +#### Cluster Options + +The options in this section are designed for use with an ensemble +of servers -- that is, when deploying clusters of servers. + +* *electionAlg* : + (No Java system property) + Election implementation to use. A value of "1" corresponds to the + non-authenticated UDP-based version of fast leader election, "2" + corresponds to the authenticated UDP-based version of fast + leader election, and "3" corresponds to TCP-based version of + fast leader election. Currently, algorithm 3 is the default. + ######Note + >The implementations of leader election 1, and 2 are now + **deprecated**. We have the intention + of removing them in the next release, at which point only the + FastLeaderElection will be available. + +* *initLimit* : + (No Java system property) + Amount of time, in ticks (see [tickTime](#id_tickTime)), to allow followers to + connect and sync to a leader. Increased this value as needed, if + the amount of data managed by ZooKeeper is large. + +* *leaderServes* : + (Java system property: zookeeper.**leaderServes**) + Leader accepts client connections. Default value is "yes". + The leader machine coordinates updates. For higher update + throughput at the slight expense of read throughput the leader + can be configured to not accept clients and focus on + coordination. The default to this option is yes, which means + that a leader will accept client connections. + ######Note + >Turning on leader selection is highly recommended when + you have more than three ZooKeeper servers in an ensemble. + +* *server.x=[hostname]:nnnnn[:nnnnn], etc* : + (No Java system property) + servers making up the ZooKeeper ensemble. When the server + starts up, it determines which server it is by looking for the + file *myid* in the data directory. That file + contains the server number, in ASCII, and it should match + **x** in **server.x** in the left hand side of this + setting. + The list of servers that make up ZooKeeper servers that is + used by the clients must match the list of ZooKeeper servers + that each ZooKeeper server has. + There are two port numbers **nnnnn**. + The first followers use to connect to the leader, and the second is for + leader election. If you want to test multiple servers on a single machine, then + different ports can be used for each server. + +* *syncLimit* : + (No Java system property) + Amount of time, in ticks (see [tickTime](#id_tickTime)), to allow followers to sync + with ZooKeeper. If followers fall too far behind a leader, they + will be dropped. + +* *group.x=nnnnn[:nnnnn]* : + (No Java system property) + Enables a hierarchical quorum construction."x" is a group identifier + and the numbers following the "=" sign correspond to server identifiers. + The left-hand side of the assignment is a colon-separated list of server + identifiers. Note that groups must be disjoint and the union of all groups + must be the ZooKeeper ensemble. + You will find an example [here](zookeeperHierarchicalQuorums.html) + +* *weight.x=nnnnn* : + (No Java system property) + Used along with "group", it assigns a weight to a server when + forming quorums. Such a value corresponds to the weight of a server + when voting. There are a few parts of ZooKeeper that require voting + such as leader election and the atomic broadcast protocol. By default + the weight of server is 1. If the configuration defines groups, but not + weights, then a value of 1 will be assigned to all servers. + You will find an example [here](zookeeperHierarchicalQuorums.html) + +* *cnxTimeout* : + (Java system property: zookeeper.**cnxTimeout**) + Sets the timeout value for opening connections for leader election notifications. + Only applicable if you are using electionAlg 3. + ######Note + >Default value is 5 seconds. + +* *4lw.commands.whitelist* : + (Java system property: **zookeeper.4lw.commands.whitelist**) + **New in 3.5.3:** + A list of comma separated [Four Letter Words](#sc_4lw) + commands that user wants to use. A valid Four Letter Words + command must be put in this list else ZooKeeper server will + not enable the command. + By default the whitelist only contains "srvr" command + which zkServer.sh uses. The rest of four letter word commands are disabled + by default. + Here's an example of the configuration that enables stat, ruok, conf, and isro + command while disabling the rest of Four Letter Words command: + + 4lw.commands.whitelist=stat, ruok, conf, isro + + +If you really need enable all four letter word commands by default, you can use +the asterisk option so you don't have to include every command one by one in the list. +As an example, this will enable all four letter word commands: + + + 4lw.commands.whitelist=* + + +* *ipReachableTimeout* : + (Java system property: **zookeeper.ipReachableTimeout**) + + New in **3.4.11:** + Set this timeout value for IP addresses reachable checking when + hostname is resolved, as mesured in milliseconds. By default, + ZooKeeper will use the first IP address of the hostname(without + any reachable checking). When zookeeper.ipReachableTimeout is + set(larger than 0), ZooKeeper will will try to pick up the first + IP address which is reachable. This is done by calling Java API + InetAddress.isReachable(long timeout) function, in which this + timeout value is used. If none of such reachable IP address can + be found, the first IP address of the hostname will be used + anyway. + +* *tcpKeepAlive* : + (Java system property: **zookeeper.tcpKeepAlive**) + **New in 3.4.11:** + Setting this to true sets the TCP keepAlive flag on the + sockets used by quorum members to perform elections. + This will allow for connections between quorum members to + remain up when there is network infrastructure that may + otherwise break them. Some NATs and firewalls may terminate + or lose state for long running or idle connections. + Enabling this option relies on OS level settings to work + properly, check your operating system's options regarding TCP + keepalive for more information. Defaults to + **false**. + +<a name="sc_authOptions"></a> + +#### Authentication and Authorization Options + +The options in this section allow control over +encryption/authentication/authorization performed by the service. + +* *DigestAuthenticationProvider.superDigest* : + (Java system property: **zookeeper.DigestAuthenticationProvider.superDigest**) + By default this feature is **disabled** + **New in 3.2:** + Enables a ZooKeeper ensemble administrator to access the + znode hierarchy as a "super" user. In particular no ACL + checking occurs for a user authenticated as + super. + org.apache.zookeeper.server.auth.DigestAuthenticationProvider + can be used to generate the superDigest, call it with + one parameter of "super:<password>". Provide the + generated "super:<data>" as the system property value + when starting each server of the ensemble. + When authenticating to a ZooKeeper server (from a + ZooKeeper client) pass a scheme of "digest" and authdata + of "super:<password>". Note that digest auth passes + the authdata in plaintext to the server, it would be + prudent to use this authentication method only on + localhost (not over the network) or over an encrypted + connection. + +* *isro* : + **New in 3.4.0:** Tests if + server is running in read-only mode. The server will respond with + "ro" if in read-only mode or "rw" if not in read-only mode. + +* *gtmk* : + Gets the current trace mask as a 64-bit signed long value in + decimal format. See `stmk` for an explanation of + the possible values. + +* *stmk* : + Sets the current trace mask. The trace mask is 64 bits, + where each bit enables or disables a specific category of trace + logging on the server. Log4J must be configured to enable + `TRACE` level first in order to see trace logging + messages. The bits of the trace mask correspond to the following + trace logging categories. + + | Trace Mask Bit Values | | + |-----------------------|---------------------| + | 0b0000000000 | Unused, reserved for future use. | + | 0b0000000010 | Logs client requests, excluding ping requests. | + | 0b0000000100 | Unused, reserved for future use. | + | 0b0000001000 | Logs client ping requests. | + | 0b0000010000 | Logs packets received from the quorum peer that is the current leader, excluding ping requests. | + | 0b0000100000 | Logs addition, removal and validation of client sessions. | + | 0b0001000000 | Logs delivery of watch events to client sessions. | + | 0b0010000000 | Logs ping packets received from the quorum peer that is the current leader. | + | 0b0100000000 | Unused, reserved for future use. | + | 0b1000000000 | Unused, reserved for future use. | + + All remaining bits in the 64-bit value are unused and + reserved for future use. Multiple trace logging categories are + specified by calculating the bitwise OR of the documented values. + The default trace mask is 0b0100110010. Thus, by default, trace + logging includes client requests, packets received from the + leader and sessions. + To set a different trace mask, send a request containing the + `stmk` four-letter word followed by the trace + mask represented as a 64-bit signed long value. This example uses + the Perl `pack` function to construct a trace + mask that enables all trace logging categories described above and + convert it to a 64-bit signed long value with big-endian byte + order. The result is appended to `stmk` and sent + to the server using netcat. The server responds with the new + trace mask in decimal format. + + + $ perl -e "print 'stmk', pack('q>', 0b0011111010)" | nc localhost 2181 + 250 + +<a name="Experimental+Options%2FFeatures"></a> + +#### Experimental Options/Features + +New features that are currently considered experimental. + +* *Read Only Mode Server* : + (Java system property: **readonlymode.enabled**) + **New in 3.4.0:** + Setting this value to true enables Read Only Mode server + support (disabled by default). ROM allows clients + sessions which requested ROM support to connect to the + server even when the server might be partitioned from + the quorum. In this mode ROM clients can still read + values from the ZK service, but will be unable to write + values and see changes from other clients. See + ZOOKEEPER-784 for more details. + +<a name="Unsafe+Options"></a> + +#### Unsafe Options + +The following options can be useful, but be careful when you use +them. The risk of each is explained along with the explanation of what +the variable does. + +* *forceSync* : + (Java system property: **zookeeper.forceSync**) + Requires updates to be synced to media of the transaction + log before finishing processing the update. If this option is + set to no, ZooKeeper will not require updates to be synced to + the media. + +* *jute.maxbuffer:* : + (Java system property:**jute.maxbuffer**) + This option can only be set as a Java system property. + There is no zookeeper prefix on it. It specifies the maximum + size of the data that can be stored in a znode. The default is + 0xfffff, or just under 1M. If this option is changed, the system + property must be set on all servers and clients otherwise + problems will arise. This is really a sanity check. ZooKeeper is + designed to store data on the order of kilobytes in size. + +* *skipACL* : + (Java system property: **zookeeper.skipACL**) + Skips ACL checks. This results in a boost in throughput, + but opens up full access to the data tree to everyone. + +* *quorumListenOnAllIPs* : + When set to true the ZooKeeper server will listen + for connections from its peers on all available IP addresses, + and not only the address configured in the server list of the + configuration file. It affects the connections handling the + ZAB protocol and the Fast Leader Election protocol. Default + value is **false**. + +<a name="Communication+using+the+Netty+framework"></a> + +#### Communication using the Netty framework + +[Netty](http://netty.io) +is an NIO based client/server communication framework, it +simplifies (over NIO being used directly) many of the +complexities of network level communication for java +applications. Additionally the Netty framework has built +in support for encryption (SSL) and authentication +(certificates). These are optional features and can be +turned on or off individually. + +In versions 3.5+, a ZooKeeper server can use Netty +instead of NIO (default option) by setting the environment +variable **zookeeper.serverCnxnFactory** +to **org.apache.zookeeper.server.NettyServerCnxnFactory**; +for the client, set **zookeeper.clientCnxnSocket** +to **org.apache.zookeeper.ClientCnxnSocketNetty**. + +TBD - tuning options for netty - currently there are none that are netty specific but we should add some. Esp around max bound on the number of reader worker threads netty creates. + +TBD - how to manage encryption + +TBD - how to manage certificates + +<a name="sc_adminserver_config"></a> + +<a name="sc_zkCommands"></a> + +### ZooKeeper Commands: The Four Letter Words + +ZooKeeper responds to a small set of commands. Each command is +composed of four letters. You issue the commands to ZooKeeper via telnet +or nc, at the client port. + +Three of the more interesting commands: "stat" gives some +general information about the server and connected clients, +while "srvr" and "cons" give extended details on server and +connections respectively. + +* *conf* : + **New in 3.3.0:** Print + details about serving configuration. + +* *cons* : + **New in 3.3.0:** List + full connection/session details for all clients connected + to this server. Includes information on numbers of packets + received/sent, session id, operation latencies, last + operation performed, etc... + +* *crst* : + **New in 3.3.0:** Reset + connection/session statistics for all connections. + +* *dump* : + Lists the outstanding sessions and ephemeral nodes. This + only works on the leader. + +* *envi* : + Print details about serving environment + +* *ruok* : + Tests if server is running in a non-error state. The server + will respond with imok if it is running. Otherwise it will not + respond at all. + A response of "imok" does not necessarily indicate that the + server has joined the quorum, just that the server process is active + and bound to the specified client port. Use "stat" for details on + state wrt quorum and client connection information. + +* *srst* : + Reset server statistics. + +* *srvr* : + **New in 3.3.0:** Lists + full details for the server. + +* *stat* : + Lists brief details for the server and connected + clients. + +* *wchs* : + **New in 3.3.0:** Lists + brief information on watches for the server. + +* *wchc* : + **New in 3.3.0:** Lists + detailed information on watches for the server, by + session. This outputs a list of sessions(connections) + with associated watches (paths). Note, depending on the + number of watches this operation may be expensive (ie + impact server performance), use it carefully. + +* *dirs* : + **New in 3.5.1:** + Shows the total size of snapshot and log files in bytes + +* *wchp* : + **New in 3.3.0:** Lists + detailed information on watches for the server, by path. + This outputs a list of paths (znodes) with associated + sessions. Note, depending on the number of watches this + operation may be expensive (ie impact server performance), + use it carefully. + +* *mntr* : + **New in 3.4.0:** Outputs a list + of variables that could be used for monitoring the health of the cluster. + + + $ echo mntr | nc localhost 2185 + zk_version 3.4.0 + zk_avg_latency 0 + zk_max_latency 0 + zk_min_latency 0 + zk_packets_received 70 + zk_packets_sent 69 + zk_outstanding_requests 0 + zk_server_state leader + zk_znode_count 4 + zk_watch_count 0 + zk_ephemerals_count 0 + zk_approximate_data_size 27 + zk_followers 4 - only exposed by the Leader + zk_synced_followers 4 - only exposed by the Leader + zk_pending_syncs 0 - only exposed by the Leader + zk_open_file_descriptor_count 23 - only available on Unix platforms + zk_max_file_descriptor_count 1024 - only available on Unix platforms + zk_fsync_threshold_exceed_count 0 + +The output is compatible with java properties format and the content +may change over time (new keys added). Your scripts should expect changes. +ATTENTION: Some of the keys are platform specific and some of the keys are only exported by the Leader. +The output contains multiple lines with the following format: + + + key \t value + + + +Here's an example of the **ruok** +command: + + + $ echo ruok | nc 127.0.0.1 5111 + imok + +<a name="sc_dataFileManagement"></a> + +### Data File Management + +ZooKeeper stores its data in a data directory and its transaction +log in a transaction log directory. By default these two directories are +the same. The server can (and should) be configured to store the +transaction log files in a separate directory than the data files. +Throughput increases and latency decreases when transaction logs reside +on a dedicated log devices. + +<a name="The+Data+Directory"></a> + +#### The Data Directory + +This directory has two or three files in it: + +* *myid* - contains a single integer in + human readable ASCII text that represents the server id. +* *snapshot.<zxid>* - holds the fuzzy + snapshot of a data tree. + +Each ZooKeeper server has a unique id. This id is used in two +places: the *myid* file and the configuration file. +The *myid* file identifies the server that +corresponds to the given data directory. The configuration file lists +the contact information for each server identified by its server id. +When a ZooKeeper server instance starts, it reads its id from the +*myid* file and then, using that id, reads from the +configuration file, looking up the port on which it should +listen. + +The *snapshot* files stored in the data +directory are fuzzy snapshots in the sense that during the time the +ZooKeeper server is taking the snapshot, updates are occurring to the +data tree. The suffix of the *snapshot* file names +is the _zxid_, the ZooKeeper transaction id, of the +last committed transaction at the start of the snapshot. Thus, the +snapshot includes a subset of the updates to the data tree that +occurred while the snapshot was in process. The snapshot, then, may +not correspond to any data tree that actually existed, and for this +reason we refer to it as a fuzzy snapshot. Still, ZooKeeper can +recover using this snapshot because it takes advantage of the +idempotent nature of its updates. By replaying the transaction log +against fuzzy snapshots ZooKeeper gets the state of the system at the +end of the log. + +<a name="The+Log+Directory"></a> + +#### The Log Directory + +The Log Directory contains the ZooKeeper transaction logs. +Before any update takes place, ZooKeeper ensures that the transaction +that represents the update is written to non-volatile storage. A new +log file is started when the number of transactions written to the +current log file reaches a (variable) threshold. The threshold is +computed using the same parameter which influences the frequency of +snapshotting (see snapCount above). The log file's suffix is the first +zxid written to that log. + +<a name="sc_filemanagement"></a> + +#### File Management + +The format of snapshot and log files does not change between +standalone ZooKeeper servers and different configurations of +replicated ZooKeeper servers. Therefore, you can pull these files from +a running replicated ZooKeeper server to a development machine with a +stand-alone ZooKeeper server for trouble shooting. + +Using older log and snapshot files, you can look at the previous +state of ZooKeeper servers and even restore that state. The +LogFormatter class allows an administrator to look at the transactions +in a log. + +The ZooKeeper server creates snapshot and log files, but +never deletes them. The retention policy of the data and log +files is implemented outside of the ZooKeeper server. The +server itself only needs the latest complete fuzzy snapshot, all log +files following it, and the last log file preceding it. The latter +requirement is necessary to include updates which happened after this +snapshot was started but went into the existing log file at that time. +This is possible because snapshotting and rolling over of logs +proceed somewhat independently in ZooKeeper. See the +[maintenance](#sc_maintenance) section in +this document for more details on setting a retention policy +and maintenance of ZooKeeper storage. + +######Note +>The data stored in these files is not encrypted. In the case of +storing sensitive data in ZooKeeper, necessary measures need to be +taken to prevent unauthorized access. Such measures are external to +ZooKeeper (e.g., control access to the files) and depend on the +individual settings in which it is being deployed. + +<a name="Recovery+-+TxnLogToolkit"></a> + +####Recovery - TxnLogToolkit + +TxnLogToolkit is a command line tool shipped with ZooKeeper which +is capable of recovering transaction log entries with broken CRC. + +Running it without any command line parameters or with the `-h,--help` argument, it outputs the following help page: + + $ bin/zkTxnLogToolkit.sh + usage: TxnLogToolkit [-dhrv] txn_log_file_name + -d,--dump Dump mode. Dump all entries of the log file. (this is the default) + -h,--help Print help message + -r,--recover Recovery mode. Re-calculate CRC for broken entries. + -v,--verbose Be verbose in recovery mode: print all entries, not just fixed ones. + -y,--yes Non-interactive mode: repair all CRC errors without asking + +The default behaviour is safe: it dumps the entries of the given +transaction log file to the screen: (same as using `-d,--dump` parameter) + + $ bin/zkTxnLogToolkit.sh log.100000001 + ZooKeeper Transactional Log File with dbid 0 txnlog format version 2 + 4/5/18 2:15:58 PM CEST session 0x16295bafcc40000 cxid 0x0 zxid 0x100000001 createSession 30000 + CRC ERROR - 4/5/18 2:16:05 PM CEST session 0x16295bafcc40000 cxid 0x1 zxid 0x100000002 closeSession null + 4/5/18 2:16:05 PM CEST session 0x16295bafcc40000 cxid 0x1 zxid 0x100000002 closeSession null + 4/5/18 2:16:12 PM CEST session 0x26295bafcc90000 cxid 0x0 zxid 0x100000003 createSession 30000 + 4/5/18 2:17:34 PM CEST session 0x26295bafcc90000 cxid 0x0 zxid 0x200000001 closeSession null + 4/5/18 2:17:34 PM CEST session 0x16295bd23720000 cxid 0x0 zxid 0x200000002 createSession 30000 + 4/5/18 2:18:02 PM CEST session 0x16295bd23720000 cxid 0x2 zxid 0x200000003 create '/andor,#626262,v{s{31,s{'world,'anyone}}},F,1 + EOF reached after 6 txns. + +There's a CRC error in the 2nd entry of the above transaction log file. In **dump** +mode, the toolkit only prints this information to the screen without touching the original file. In +**recovery** mode (`-r,--recover` flag) the original file still remains +untouched and all transactions will be copied over to a new txn log file with ".fixed" suffix. It recalculates +CRC values and copies the calculated value, if it doesn't match the original txn entry. +By default, the tool works interactively: it asks for confirmation whenever CRC error encountered. + + $ bin/zkTxnLogToolkit.sh -r log.100000001 + ZooKeeper Transactional Log File with dbid 0 txnlog format version 2 + CRC ERROR - 4/5/18 2:16:05 PM CEST session 0x16295bafcc40000 cxid 0x1 zxid 0x100000002 closeSession null + Would you like to fix it (Yes/No/Abort) ? + +Answering **Yes** means the newly calculated CRC value will be outputted +to the new file. **No** means that the original CRC value will be copied over. +**Abort** will abort the entire operation and exits. +(In this case the ".fixed" will not be deleted and left in a half-complete state: contains only entries which +have already been processed or only the header if the operation was aborted at the first entry.) + + $ bin/zkTxnLogToolkit.sh -r log.100000001 + ZooKeeper Transactional Log File with dbid 0 txnlog format version 2 + CRC ERROR - 4/5/18 2:16:05 PM CEST session 0x16295bafcc40000 cxid 0x1 zxid 0x100000002 closeSession null + Would you like to fix it (Yes/No/Abort) ? y + EOF reached after 6 txns. + Recovery file log.100000001.fixed has been written with 1 fixed CRC error(s) + +The default behaviour of recovery is to be silent: only entries with CRC error get printed to the screen. +One can turn on verbose mode with the `-v,--verbose` parameter to see all records. +Interactive mode can be turned off with the `-y,--yes` parameter. In this case all CRC errors will be fixed +in the new transaction file. + +<a name="sc_commonProblems"></a> + +### Things to Avoid + +Here are some common problems you can avoid by configuring +ZooKeeper correctly: + +* *inconsistent lists of servers* : + The list of ZooKeeper servers used by the clients must match + the list of ZooKeeper servers that each ZooKeeper server has. + Things work okay if the client list is a subset of the real list, + but things will really act strange if clients have a list of + ZooKeeper servers that are in different ZooKeeper clusters. Also, + the server lists in each Zookeeper server configuration file + should be consistent with one another. + +* *incorrect placement of transaction log* : + The most performance critical part of ZooKeeper is the + transaction log. ZooKeeper syncs transactions to media before it + returns a response. A dedicated transaction log device is key to + consistent good performance. Putting the log on a busy device will + adversely effect performance. If you only have one storage device, + put trace files on NFS and increase the snapshotCount; it doesn't + eliminate the problem, but it should mitigate it. + +* *incorrect Java heap size* : + You should take special care to set your Java max heap size + correctly. In particular, you should not create a situation in + which ZooKeeper swaps to disk. The disk is death to ZooKeeper. + Everything is ordered, so if processing one request swaps the + disk, all other queued requests will probably do the same. the + disk. DON'T SWAP. + Be conservative in your estimates: if you have 4G of RAM, do + not set the Java max heap size to 6G or even 4G. For example, it + is more likely you would use a 3G heap for a 4G machine, as the + operating system and the cache also need memory. The best and only + recommend practice for estimating the heap size your system needs + is to run load tests, and then make sure you are well below the + usage limit that would cause the system to swap. + +* *Publicly accessible deployment* : + A ZooKeeper ensemble is expected to operate in a trusted computing environment. + It is thus recommended to deploy ZooKeeper behind a firewall. + +<a name="sc_bestPractices"></a> + +### Best Practices + +For best results, take note of the following list of good +Zookeeper practices: + +For multi-tenant installations see the [section](zookeeperProgrammers.html#ch_zkSessions) +detailing ZooKeeper "chroot" support, this can be very useful +when deploying many applications/services interfacing to a +single ZooKeeper cluster. + + diff --git a/zookeeper-docs/src/main/resources/markdown/zookeeperHierarchicalQuorums.md b/zookeeper-docs/src/main/resources/markdown/zookeeperHierarchicalQuorums.md new file mode 100644 index 000000000..e11f34f2b --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/zookeeperHierarchicalQuorums.md @@ -0,0 +1,47 @@ +<!-- +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. +//--> + +# Introduction to hierarchical quorums + +This document gives an example of how to use hierarchical quorums. The basic idea is +very simple. First, we split servers into groups, and add a line for each group listing +the servers that form this group. Next we have to assign a weight to each server. + +The following example shows how to configure a system with three groups of three servers +each, and we assign a weight of 1 to each server: + + + group.1=1:2:3 + group.2=4:5:6 + group.3=7:8:9 + + weight.1=1 + weight.2=1 + weight.3=1 + weight.4=1 + weight.5=1 + weight.6=1 + weight.7=1 + weight.8=1 + weight.9=1 + + +When running the system, we are able to form a quorum once we have a majority of votes from +a majority of non-zero-weight groups. Groups that have zero weight are discarded and not +considered when forming quorums. Looking at the example, we are able to form a quorum once +we have votes from at least two servers from each of two different groups. + + diff --git a/zookeeper-docs/src/main/resources/markdown/zookeeperInternals.md b/zookeeper-docs/src/main/resources/markdown/zookeeperInternals.md new file mode 100644 index 000000000..84793f127 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/zookeeperInternals.md @@ -0,0 +1,370 @@ +<!-- +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. +//--> + +# ZooKeeper Internals + +* [Introduction](#ch_Introduction) +* [Atomic Broadcast](#sc_atomicBroadcast) + * [Guarantees, Properties, and Definitions](#sc_guaranteesPropertiesDefinitions) + * [Leader Activation](#sc_leaderElection) + * [Active Messaging](#sc_activeMessaging) + * [Summary](#sc_summary) + * [Comparisons](#sc_comparisons) +* [Quorums](#sc_quorum) +* [Logging](#sc_logging) + * [Developer Guidelines](#sc_developerGuidelines) + * [Logging at the Right Level](#sc_rightLevel) + * [Use of Standard slf4j Idioms](#sc_slf4jIdioms) + +<a name="ch_Introduction"></a> + +## Introduction + +This document contains information on the inner workings of ZooKeeper. +So far, it discusses these topics: + +* [Atomic Broadcast](#sc_atomicBroadcast) +* [Logging](#sc_logging) + +<a name="sc_atomicBroadcast"></a> + +## Atomic Broadcast + +At the heart of ZooKeeper is an atomic messaging system that keeps all of the servers in sync. + +<a name="sc_guaranteesPropertiesDefinitions"></a> + +### Guarantees, Properties, and Definitions + +The specific guarantees provided by the messaging system used by ZooKeeper are the following: + +* *_Reliable delivery_* : + If a message, m, is delivered + by one server, it will be eventually delivered by all servers. + +* *_Total order_* : + If a message is + delivered before message b by one server, a will be delivered before b by all + servers. If a and b are delivered messages, either a will be delivered before b + or b will be delivered before a. + +* *_Causal order_* : + If a message b is sent after a message a has been delivered by the sender of b, + a must be ordered before b. If a sender sends c after sending b, c must be ordered after b. + +The ZooKeeper messaging system also needs to be efficient, reliable, and easy to +implement and maintain. We make heavy use of messaging, so we need the system to +be able to handle thousands of requests per second. Although we can require at +least k+1 correct servers to send new messages, we must be able to recover from +correlated failures such as power outages. When we implemented the system we had +little time and few engineering resources, so we needed a protocol that is +accessible to engineers and is easy to implement. We found that our protocol +satisfied all of these goals. + +Our protocol assumes that we can construct point-to-point FIFO channels between +the servers. While similar services usually assume message delivery that can +lose or reorder messages, our assumption of FIFO channels is very practical +given that we use TCP for communication. Specifically we rely on the following property of TCP: + +* *_Ordered delivery_* : + Data is delivered in the same order it is sent and a message m is + delivered only after all messages sent before m have been delivered. + (The corollary to this is that if message m is lost all messages after m will be lost.) + +* *_No message after close_* : + Once a FIFO channel is closed, no messages will be received from it. + +FLP proved that consensus cannot be achieved in asynchronous distributed systems +if failures are possible. To ensure we achieve consensus in the presence of failures +we use timeouts. However, we rely on times for liveness not for correctness. So, +if timeouts stop working (clocks malfunction for example) the messaging system may +hang, but it will not violate its guarantees. + +When describing the ZooKeeper messaging protocol we will talk of packets, +proposals, and messages: + +* *_Packet_* : + a sequence of bytes sent through a FIFO channel + +* *_Proposal_* : + a unit of agreement. Proposals are agreed upon by exchanging packets + with a quorum of ZooKeeper servers. Most proposals contain messages, however the + NEW_LEADER proposal is an example of a proposal that does not correspond to a message. + +* *_Message_* : + a sequence of bytes to be atomically broadcast to all ZooKeeper + servers. A message put into a proposal and agreed upon before it is delivered. + +As stated above, ZooKeeper guarantees a total order of messages, and it also +guarantees a total order of proposals. ZooKeeper exposes the total ordering using +a ZooKeeper transaction id (_zxid_). All proposals will be stamped with a zxid when +it is proposed and exactly reflects the total ordering. Proposals are sent to all +ZooKeeper servers and committed when a quorum of them acknowledge the proposal. +If a proposal contains a message, the message will be delivered when the proposal +is committed. Acknowledgement means the server has recorded the proposal to persistent storage. +Our quorums have the requirement that any pair of quorum must have at least one server +in common. We ensure this by requiring that all quorums have size (_n/2+1_) where +n is the number of servers that make up a ZooKeeper service. + +The zxid has two parts: the epoch and a counter. In our implementation the zxid +is a 64-bit number. We use the high order 32-bits for the epoch and the low order +32-bits for the counter. Because it has two parts represent the zxid both as a +number and as a pair of integers, (_epoch, count_). The epoch number represents a +change in leadership. Each time a new leader comes into power it will have its +own epoch number. We have a simple algorithm to assign a unique zxid to a proposal: +the leader simply increments the zxid to obtain a unique zxid for each proposal. _Leadership activation will ensure that only one leader uses a given epoch, so our +simple algorithm guarantees that every proposal will have a unique id._ + +ZooKeeper messaging consists of two phases: + +* *_Leader activation_* : + In this phase a leader establishes the correct state of the system + and gets ready to start making proposals. + +* *_Active messaging_* : + In this phase a leader accepts messages to propose and coordinates message delivery. + +ZooKeeper is a holistic protocol. We do not focus on individual proposals, rather +look at the stream of proposals as a whole. Our strict ordering allows us to do this +efficiently and greatly simplifies our protocol. Leadership activation embodies +this holistic concept. A leader becomes active only when a quorum of followers +(The leader counts as a follower as well. You can always vote for yourself ) has synced +up with the leader, they have the same state. This state consists of all of the +proposals that the leader believes have been committed and the proposal to follow +the leader, the NEW_LEADER proposal. (Hopefully you are thinking to +yourself, _Does the set of proposals that the leader believes has been committed +included all the proposals that really have been committed?_ The answer is _yes_. +Below, we make clear why.) + +<a name="sc_leaderElection"></a> + +### Leader Activation + +Leader activation includes leader election. We currently have two leader election +algorithms in ZooKeeper: LeaderElection and FastLeaderElection (AuthFastLeaderElection +is a variant of FastLeaderElection that uses UDP and allows servers to perform a simple +form of authentication to avoid IP spoofing). ZooKeeper messaging doesn't care about the +exact method of electing a leader has long as the following holds: + +* The leader has seen the highest zxid of all the followers. +* A quorum of servers have committed to following the leader. + +Of these two requirements only the first, the highest zxid amoung the followers +needs to hold for correct operation. The second requirement, a quorum of followers, +just needs to hold with high probability. We are going to recheck the second requirement, +so if a failure happens during or after the leader election and quorum is lost, +we will recover by abandoning leader activation and running another election. + +After leader election a single server will be designated as a leader and start +waiting for followers to connect. The rest of the servers will try to connect to +the leader. The leader will sync up with followers by sending any proposals they +are missing, or if a follower is missing too many proposals, it will send a full +snapshot of the state to the follower. + +There is a corner case in which a follower that has proposals, U, not seen +by a leader arrives. Proposals are seen in order, so the proposals of U will have a zxids +higher than zxids seen by the leader. The follower must have arrived after the +leader election, otherwise the follower would have been elected leader given that +it has seen a higher zxid. Since committed proposals must be seen by a quorum of +servers, and a quorum of servers that elected the leader did not see U, the proposals +of you have not been committed, so they can be discarded. When the follower connects +to the leader, the leader will tell the follower to discard U. + +A new leader establishes a zxid to start using for new proposals by getting the +epoch, e, of the highest zxid it has seen and setting the next zxid to use to be +(e+1, 0), fter the leader syncs with a follower, it will propose a NEW_LEADER +proposal. Once the NEW_LEADER proposal has been committed, the leader will activate +and start receiving and issuing proposals. + +It all sounds complicated but here are the basic rules of operation during leader +activation: + +* A follower will ACK the NEW_LEADER proposal after it has synced with the leader. +* A follower will only ACK a NEW_LEADER proposal with a given zxid from a single server. +* A new leader will COMMIT the NEW_LEADER proposal when a quorum of followers have ACKed it. +* A follower will commit any state it received from the leader when the NEW_LEADER proposal is COMMIT. +* A new leader will not accept new proposals until the NEW_LEADER proposal has been COMMITED. + +If leader election terminates erroneously, we don't have a problem since the +NEW_LEADER proposal will not be committed since the leader will not have quorum. +When this happens, the leader and any remaining followers will timeout and go back +to leader election. + +<a name="sc_activeMessaging"></a> + +### Active Messaging + +Leader Activation does all the heavy lifting. Once the leader is coronated he can +start blasting out proposals. As long as he remains the leader no other leader can +emerge since no other leader will be able to get a quorum of followers. If a new +leader does emerge, +it means that the leader has lost quorum, and the new leader will clean up any +mess left over during her leadership activation. + +ZooKeeper messaging operates similar to a classic two-phase commit. + + + +All communication channels are FIFO, so everything is done in order. Specifically +the following operating constraints are observed: + +* The leader sends proposals to all followers using + the same order. Moreover, this order follows the order in which requests have been + received. Because we use FIFO channels this means that followers also receive proposals in order. +* Followers process messages in the order they are received. This + means that messages will be ACKed in order and the leader will receive ACKs from + followers in order, due to the FIFO channels. It also means that if message $m$ + has been written to non-volatile storage, all messages that were proposed before + $m$ have been written to non-volatile storage. +* The leader will issue a COMMIT to all followers as soon as a + quorum of followers have ACKed a message. Since messages are ACKed in order, + COMMITs will be sent by the leader as received by the followers in order. +* COMMITs are processed in order. Followers deliver a proposals + message when that proposal is committed. + +<a name="sc_summary"></a> + +### Summary + +So there you go. Why does it work? Specifically, why does a set of proposals +believed by a new leader always contain any proposal that has actually been committed? +First, all proposals have a unique zxid, so unlike other protocols, we never have +to worry about two different values being proposed for the same zxid; followers +(a leader is also a follower) see and record proposals in order; proposals are +committed in order; there is only one active leader at a time since followers only +follow a single leader at a time; a new leader has seen all committed proposals +from the previous epoch since it has seen the highest zxid from a quorum of servers; +any uncommited proposals from a previous epoch seen by a new leader will be committed +by that leader before it becomes active. + +<a name="sc_comparisons"></a> + +### Comparisons + +Isn't this just Multi-Paxos? No, Multi-Paxos requires some way of assuring that +there is only a single coordinator. We do not count on such assurances. Instead +we use the leader activation to recover from leadership change or old leaders +believing they are still active. + +Isn't this just Paxos? Your active messaging phase looks just like phase 2 of Paxos? +Actually, to us active messaging looks just like 2 phase commit without the need to +handle aborts. Active messaging is different from both in the sense that it has +cross proposal ordering requirements. If we do not maintain strict FIFO ordering of +all packets, it all falls apart. Also, our leader activation phase is different from +both of them. In particular, our use of epochs allows us to skip blocks of uncommitted +proposals and to not worry about duplicate proposals for a given zxid. + +<a name="sc_quorum"></a> + +## Quorums + +Atomic broadcast and leader election use the notion of quorum to guarantee a consistent +view of the system. By default, ZooKeeper uses majority quorums, which means that every +voting that happens in one of these protocols requires a majority to vote on. One example is +acknowledging a leader proposal: the leader can only commit once it receives an +acknowledgement from a quorum of servers. + +If we extract the properties that we really need from our use of majorities, we have that we only +need to guarantee that groups of processes used to validate an operation by voting (e.g., acknowledging +a leader proposal) pairwise intersect in at least one server. Using majorities guarantees such a property. +However, there are other ways of constructing quorums different from majorities. For example, we can assign +weights to the votes of servers, and say that the votes of some servers are more important. To obtain a quorum, +we get enough votes so that the sum of weights of all votes is larger than half of the total sum of all weights. + +A different construction that uses weights and is useful in wide-area deployments (co-locations) is a hierarchical +one. With this construction, we split the servers into disjoint groups and assign weights to processes. To form +a quorum, we have to get a hold of enough servers from a majority of groups G, such that for each group g in G, +the sum of votes from g is larger than half of the sum of weights in g. Interestingly, this construction enables +smaller quorums. If we have, for example, 9 servers, we split them into 3 groups, and assign a weight of 1 to each +server, then we are able to form quorums of size 4. Note that two subsets of processes composed each of a majority +of servers from each of a majority of groups necessarily have a non-empty intersection. It is reasonable to expect +that a majority of co-locations will have a majority of servers available with high probability. + +With ZooKeeper, we provide a user with the ability of configuring servers to use majority quorums, weights, or a +hierarchy of groups. + +<a name="sc_logging"></a> + +## Logging + +Zookeeper uses [slf4j](http://www.slf4j.org/index.html) as an abstraction layer for logging. [log4j](http://logging.apache.org/log4j) in version 1.2 is chosen as the final logging implementation for now. +For better embedding support, it is planned in the future to leave the decision of choosing the final logging implementation to the end user. +Therefore, always use the slf4j api to write log statements in the code, but configure log4j for how to log at runtime. +Note that slf4j has no FATAL level, former messages at FATAL level have been moved to ERROR level. +For information on configuring log4j for +ZooKeeper, see the [Logging](zookeeperAdmin.html#sc_logging) section +of the [ZooKeeper Administrator's Guide.](zookeeperAdmin.html) + +<a name="sc_developerGuidelines"></a> + +### Developer Guidelines + +Please follow the [slf4j manual](http://www.slf4j.org/manual.html) when creating log statements within code. +Also read the[FAQ on performance](http://www.slf4j.org/faq.html#logging\_performance) +, when creating log statements. Patch reviewers will look for the following: + +<a name="sc_rightLevel"></a> + +#### Logging at the Right Level + +There are several levels of logging in slf4j. + +It's important to pick the right one. In order of higher to lower severity: + +1. ERROR level designates error events that might still allow the application to continue running. +1. WARN level designates potentially harmful situations. +1. INFO level designates informational messages that highlight the progress of the application at coarse-grained level. +1. DEBUG Level designates fine-grained informational events that are most useful to debug an application. +1. TRACE Level designates finer-grained informational events than the DEBUG. + +ZooKeeper is typically run in production such that log messages of INFO level +severity and higher (more severe) are output to the log. + +<a name="sc_slf4jIdioms"></a> + +#### Use of Standard slf4j Idioms + +_Static Message Logging_ + + LOG.debug("process completed successfully!"); + +However when creating parameterized messages are required, use formatting anchors. + + LOG.debug("got {} messages in {} minutes",new Object[]{count,time}); + +_Naming_ + +Loggers should be named after the class in which they are used. + + public class Foo { + private static final Logger LOG = LoggerFactory.getLogger(Foo.class); + .... + public Foo() { + LOG.info("constructing Foo"); + +_Exception handling_ + + try { + // code + } catch (XYZException e) { + // do this + LOG.error("Something bad happened", e); + // don't do this (generally) + // LOG.error(e); + // why? because "don't do" case hides the stack trace + + // continue process here as you need... recover or (re)throw + } diff --git a/zookeeper-docs/src/main/resources/markdown/zookeeperJMX.md b/zookeeper-docs/src/main/resources/markdown/zookeeperJMX.md new file mode 100644 index 000000000..5a6686f06 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/zookeeperJMX.md @@ -0,0 +1,118 @@ +<!-- +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. +//--> + +# ZooKeeper JMX + +* [JMX](#ch_jmx) +* [Starting ZooKeeper with JMX enabled](#ch_starting) +* [Run a JMX console](#ch_console) +* [ZooKeeper MBean Reference](#ch_reference) + +<a name="ch_jmx"></a> + +## JMX + +Apache ZooKeeper has extensive support for JMX, allowing you +to view and manage a ZooKeeper serving ensemble. + +This document assumes that you have basic knowledge of +JMX. See [Sun JMX Technology](http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/) page to get started with JMX. + +See the [JMX Management Guide](http://java.sun.com/javase/6/docs/technotes/guides/management/agent.html) for details on setting up local and +remote management of VM instances. By default the included +_zkServer.sh_ supports only local management - +review the linked document to enable support for remote management +(beyond the scope of this document). + +<a name="ch_starting"></a> + +## Starting ZooKeeper with JMX enabled + +The class +_org.apache.zookeeper.server.quorum.QuorumPeerMain_ +will start a JMX manageable ZooKeeper server. This class +registers the proper MBeans during initalization to support JMX +monitoring and management of the +instance. See _bin/zkServer.sh_ for one +example of starting ZooKeeper using QuorumPeerMain. + +<a name="ch_console"></a> + +## Run a JMX console + +There are a number of JMX consoles available which can connect +to the running server. For this example we will use Sun's +_jconsole_. + +The Java JDK ships with a simple JMX console +named [jconsole](http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html) +which can be used to connect to ZooKeeper and inspect a running +server. Once you've started ZooKeeper using QuorumPeerMain +start _jconsole_, which typically resides in +_JDK_HOME/bin/jconsole_ + +When the "new connection" window is displayed either connect +to local process (if jconsole started on same host as Server) or +use the remote process connection. + +By default the "overview" tab for the VM is displayed (this +is a great way to get insight into the VM btw). Select +the "MBeans" tab. + +You should now see _org.apache.ZooKeeperService_ +on the left hand side. Expand this item and depending on how you've +started the server you will be able to monitor and manage various +service related features. + +Also note that ZooKeeper will register log4j MBeans as +well. In the same section along the left hand side you will see +"log4j". Expand that to manage log4j through JMX. Of particular +interest is the ability to dynamically change the logging levels +used by editing the appender and root thresholds. Log4j MBean +registration can be disabled by passing +_-Dzookeeper.jmx.log4j.disable=true_ to the JVM +when starting ZooKeeper. + +<a name="ch_reference"></a> + +## ZooKeeper MBean Reference + +This table details JMX for a server participating in a +replicated ZooKeeper ensemble (ie not standalone). This is the +typical case for a production environment. + +### MBeans, their names and description + +| MBean | MBean Object Name | Description | +|-----------|-------------------|-------------------------------------------------| +| Quorum | ReplicatedServer_id<#> | Represents the Quorum, or Ensemble - parent of all cluster members. Note that the object name includes the "myid" of the server (name suffix) that your JMX agent has connected to. | +| LocalPeer/RemotePeer | replica.<#> | Represents a local or remote peer (ie server participating in the ensemble). Note that the object name includes the "myid" of the server (name suffix). | +| LeaderElection | LeaderElection | Represents a ZooKeeper cluster leader election which is in progress. Provides information about the election, such as when it started. | +| Leader | Leader | Indicates that the parent replica is the leader and provides attributes/operations for that server. Note that Leader is a subclass of ZooKeeperServer, so it provides all of the information normally associated with a ZooKeeperServer node. | +| Follower | Follower | Indicates that the parent replica is a follower and provides attributes/operations for that server. Note that Follower is a subclass of ZooKeeperServer, so it provides all of the information normally associated with a ZooKeeperServer node. | +| DataTree | InMemoryDataTree | Statistics on the in memory znode database, also operations to access finer (and more computationally intensive) statistics on the data (such as ephemeral count). InMemoryDataTrees are children of ZooKeeperServer nodes. | +| ServerCnxn | <session_id> | Statistics on each client connection, also operations on those connections (such as termination). Note the object name is the session id of the connection in hex form. | + +This table details JMX for a standalone server. Typically +standalone is only used in development situations. + +### MBeans, their names and description + +| MBean | MBean Object Name | Description | +|-------|-------------------|------------------------| +| ZooKeeperServer | StandaloneServer_port<#> | Statistics on the running server, also operations to reset these attributes. Note that the object name includes the client port of the server (name suffix). | +| DataTree | InMemoryDataTree | Statistics on the in memory znode database, also operations to access finer (and more computationally intensive) statistics on the data (such as ephemeral count). | +| ServerCnxn | < session_id > | Statistics on each client connection, also operations on those connections (such as termination). Note the object name is the session id of the connection in hex form. | diff --git a/zookeeper-docs/src/main/resources/markdown/zookeeperObservers.md b/zookeeper-docs/src/main/resources/markdown/zookeeperObservers.md new file mode 100644 index 000000000..4642b1372 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/zookeeperObservers.md @@ -0,0 +1,106 @@ +<!-- +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. +//--> + +# ZooKeeper Observers + +* [Observers: Scaling ZooKeeper Without Hurting Write Performance](#ch_Introduction) +* [How to use Observers](#sc_UsingObservers) +* [Example use cases](#ch_UseCases) + +<a name="ch_Introduction"></a> + +## Observers: Scaling ZooKeeper Without Hurting Write Performance + +Although ZooKeeper performs very well by having clients connect directly +to voting members of the ensemble, this architecture makes it hard to +scale out to huge numbers of clients. The problem is that as we add more +voting members, the write performance drops. This is due to the fact that +a write operation requires the agreement of (in general) at least half the +nodes in an ensemble and therefore the cost of a vote can increase +significantly as more voters are added. + +We have introduced a new type of ZooKeeper node called +an _Observer_ which helps address this problem and +further improves ZooKeeper's scalability. Observers are non-voting members +of an ensemble which only hear the results of votes, not the agreement +protocol that leads up to them. Other than this simple distinction, +Observers function exactly the same as Followers - clients may connect to +them and send read and write requests to them. Observers forward these +requests to the Leader like Followers do, but they then simply wait to +hear the result of the vote. Because of this, we can increase the number +of Observers as much as we like without harming the performance of votes. + +Observers have other advantages. Because they do not vote, they are not a +critical part of the ZooKeeper ensemble. Therefore they can fail, or be +disconnected from the cluster, without harming the availability of the +ZooKeeper service. The benefit to the user is that Observers may connect +over less reliable network links than Followers. In fact, Observers may be +used to talk to a ZooKeeper server from another data center. Clients of +the Observer will see fast reads, as all reads are served locally, and +writes result in minimal network traffic as the number of messages +required in the absence of the vote protocol is smaller. + +<a name="sc_UsingObservers"></a> + +## How to use Observers + +Setting up a ZooKeeper ensemble that uses Observers is very simple, +and requires just two changes to your config files. Firstly, in the config +file of every node that is to be an Observer, you must place this line: + + peerType=observer + +This line tells ZooKeeper that the server is to be an Observer. Secondly, +in every server config file, you must add :observer to the server +definition line of each Observer. For example: + + server.1:localhost:2181:3181:observer + +This tells every other server that server.1 is an Observer, and that they +should not expect it to vote. This is all the configuration you need to do +to add an Observer to your ZooKeeper cluster. Now you can connect to it as +though it were an ordinary Follower. Try it out, by running: + + $ bin/zkCli.sh -server localhost:2181 + +where localhost:2181 is the hostname and port number of the Observer as +specified in every config file. You should see a command line prompt +through which you can issue commands like _ls_ to query +the ZooKeeper service. + +<a name="ch_UseCases"></a> + +## Example use cases + +Two example use cases for Observers are listed below. In fact, wherever +you wish to scale the number of clients of your ZooKeeper ensemble, or +where you wish to insulate the critical part of an ensemble from the load +of dealing with client requests, Observers are a good architectural +choice. + +* As a datacenter bridge: Forming a ZK ensemble between two + datacenters is a problematic endeavour as the high variance in latency + between the datacenters could lead to false positive failure detection + and partitioning. However if the ensemble runs entirely in one + datacenter, and the second datacenter runs only Observers, partitions + aren't problematic as the ensemble remains connected. Clients of the + Observers may still see and issue proposals. +* As a link to a message bus: Some companies have expressed an + interest in using ZK as a component of a persistent reliable message + bus. Observers would give a natural integration point for this work: a + plug-in mechanism could be used to attach the stream of proposals an + Observer sees to a publish-subscribe system, again without loading the + core ensemble. diff --git a/zookeeper-docs/src/main/resources/markdown/zookeeperOtherInfo.md b/zookeeper-docs/src/main/resources/markdown/zookeeperOtherInfo.md new file mode 100644 index 000000000..e3c0ae5fa --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/zookeeperOtherInfo.md @@ -0,0 +1,22 @@ +<!-- +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. +//--> + +# ZooKeeper + +## Other Info + +currently empty + diff --git a/zookeeper-docs/src/main/resources/markdown/zookeeperOver.md b/zookeeper-docs/src/main/resources/markdown/zookeeperOver.md new file mode 100644 index 000000000..b33cedf53 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/zookeeperOver.md @@ -0,0 +1,343 @@ +<!-- +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. +//--> + +# ZooKeeper + +* [ZooKeeper: A Distributed Coordination Service for Distributed Applications](#ch_DesignOverview) + * [Design Goals](#sc_designGoals) + * [Data model and the hierarchical namespace](#sc_dataModelNameSpace) + * [Nodes and ephemeral nodes](#Nodes+and+ephemeral+nodes) + * [Conditional updates and watches](#Conditional+updates+and+watches) + * [Guarantees](#Guarantees) + * [Simple API](#Simple+API) + * [Implementation](#Implementation) + * [Uses](#Uses) + * [Performance](#Performance) + * [Reliability](#Reliability) + * [The ZooKeeper Project](#The+ZooKeeper+Project) + +<a name="ch_DesignOverview"></a> + +## ZooKeeper: A Distributed Coordination Service for Distributed Applications + +ZooKeeper is a distributed, open-source coordination service for +distributed applications. It exposes a simple set of primitives that +distributed applications can build upon to implement higher level services +for synchronization, configuration maintenance, and groups and naming. It +is designed to be easy to program to, and uses a data model styled after +the familiar directory tree structure of file systems. It runs in Java and +has bindings for both Java and C. + +Coordination services are notoriously hard to get right. They are +especially prone to errors such as race conditions and deadlock. The +motivation behind ZooKeeper is to relieve distributed applications the +responsibility of implementing coordination services from scratch. + +<a name="sc_designGoals"></a> + +### Design Goals + +**ZooKeeper is simple.** ZooKeeper +allows distributed processes to coordinate with each other through a +shared hierarchal namespace which is organized similarly to a standard +file system. The name space consists of data registers - called znodes, +in ZooKeeper parlance - and these are similar to files and directories. +Unlike a typical file system, which is designed for storage, ZooKeeper +data is kept in-memory, which means ZooKeeper can achieve high +throughput and low latency numbers. + +The ZooKeeper implementation puts a premium on high performance, +highly available, strictly ordered access. The performance aspects of +ZooKeeper means it can be used in large, distributed systems. The +reliability aspects keep it from being a single point of failure. The +strict ordering means that sophisticated synchronization primitives can +be implemented at the client. + +**ZooKeeper is replicated.** Like the +distributed processes it coordinates, ZooKeeper itself is intended to be +replicated over a sets of hosts called an ensemble. + + + +The servers that make up the ZooKeeper service must all know about +each other. They maintain an in-memory image of state, along with a +transaction logs and snapshots in a persistent store. As long as a +majority of the servers are available, the ZooKeeper service will be +available. + +Clients connect to a single ZooKeeper server. The client maintains +a TCP connection through which it sends requests, gets responses, gets +watch events, and sends heart beats. If the TCP connection to the server +breaks, the client will connect to a different server. + +**ZooKeeper is ordered.** ZooKeeper +stamps each update with a number that reflects the order of all +ZooKeeper transactions. Subsequent operations can use the order to +implement higher-level abstractions, such as synchronization +primitives. + +**ZooKeeper is fast.** It is +especially fast in "read-dominant" workloads. ZooKeeper applications run +on thousands of machines, and it performs best where reads are more +common than writes, at ratios of around 10:1. + +<a name="sc_dataModelNameSpace"></a> + +### Data model and the hierarchical namespace + +The name space provided by ZooKeeper is much like that of a +standard file system. A name is a sequence of path elements separated by +a slash (/). Every node in ZooKeeper's name space is identified by a +path. + +#### ZooKeeper's Hierarchical Namespace + + + +<a name="Nodes+and+ephemeral+nodes"></a> + +### Nodes and ephemeral nodes + +Unlike standard file systems, each node in a ZooKeeper +namespace can have data associated with it as well as children. It is +like having a file-system that allows a file to also be a directory. +(ZooKeeper was designed to store coordination data: status information, +configuration, location information, etc., so the data stored at each +node is usually small, in the byte to kilobyte range.) We use the term +_znode_ to make it clear that we are talking about +ZooKeeper data nodes. + +Znodes maintain a stat structure that includes version numbers for +data changes, ACL changes, and timestamps, to allow cache validations +and coordinated updates. Each time a znode's data changes, the version +number increases. For instance, whenever a client retrieves data it also +receives the version of the data. + +The data stored at each znode in a namespace is read and written +atomically. Reads get all the data bytes associated with a znode and a +write replaces all the data. Each node has an Access Control List (ACL) +that restricts who can do what. + +ZooKeeper also has the notion of ephemeral nodes. These znodes +exists as long as the session that created the znode is active. When the +session ends the znode is deleted. Ephemeral nodes are useful when you +want to implement _[tbd]_. + +<a name="Conditional+updates+and+watches"></a> + +### Conditional updates and watches + +ZooKeeper supports the concept of _watches_. +Clients can set a watch on a znode. A watch will be triggered and +removed when the znode changes. When a watch is triggered, the client +receives a packet saying that the znode has changed. If the +connection between the client and one of the Zoo Keeper servers is +broken, the client will receive a local notification. These can be used +to _[tbd]_. + +<a name="Guarantees"></a> + +### Guarantees + +ZooKeeper is very fast and very simple. Since its goal, though, is +to be a basis for the construction of more complicated services, such as +synchronization, it provides a set of guarantees. These are: + +* Sequential Consistency - Updates from a client will be applied + in the order that they were sent. +* Atomicity - Updates either succeed or fail. No partial + results. +* Single System Image - A client will see the same view of the + service regardless of the server that it connects to. + +* Reliability - Once an update has been applied, it will persist + from that time forward until a client overwrites the update. + +* Timeliness - The clients view of the system is guaranteed to + be up-to-date within a certain time bound. + +For more information on these, and how they can be used, see +_[tbd]_ + +<a name="Simple+API"></a> + +### Simple API + +One of the design goals of ZooKeeper is provide a very simple +programming interface. As a result, it supports only these +operations: + +* *create* : + creates a node at a location in the tree + +* *delete* : + deletes a node + +* *exists* : + tests if a node exists at a location + +* *get data* : + reads the data from a node + +* *set data* : + writes data to a node + +* *get children* : + retrieves a list of children of a node + +* *sync* : + waits for data to be propagated + +For a more in-depth discussion on these, and how they can be used +to implement higher level operations, please refer to +_[tbd]_ + +<a name="Implementation"></a> + +### Implementation + +[ZooKeeper Components](#zkComponents) shows the high-level components +of the ZooKeeper service. With the exception of the request processor, +each of +the servers that make up the ZooKeeper service replicates its own copy +of each of the components. + +<a name="zkComponents"></a> + + + +The replicated database is an in-memory database containing the +entire data tree. Updates are logged to disk for recoverability, and +writes are serialized to disk before they are applied to the in-memory +database. + +Every ZooKeeper server services clients. Clients connect to +exactly one server to submit irequests. Read requests are serviced from +the local replica of each server database. Requests that change the +state of the service, write requests, are processed by an agreement +protocol. + +As part of the agreement protocol all write requests from clients +are forwarded to a single server, called the +_leader_. The rest of the ZooKeeper servers, called +_followers_, receive message proposals from the +leader and agree upon message delivery. The messaging layer takes care +of replacing leaders on failures and syncing followers with +leaders. + +ZooKeeper uses a custom atomic messaging protocol. Since the +messaging layer is atomic, ZooKeeper can guarantee that the local +replicas never diverge. When the leader receives a write request, it +calculates what the state of the system is when the write is to be +applied and transforms this into a transaction that captures this new +state. + +<a name="Uses"></a> + +### Uses + +The programming interface to ZooKeeper is deliberately simple. +With it, however, you can implement higher order operations, such as +synchronizations primitives, group membership, ownership, etc. Some +distributed applications have used it to: _[tbd: add uses from +white paper and video presentation.]_ For more information, see +_[tbd]_ + +<a name="Performance"></a> + +### Performance + +ZooKeeper is designed to be highly performant. But is it? The +results of the ZooKeeper's development team at Yahoo! Research indicate +that it is. (See [ZooKeeper Throughput as the Read-Write Ratio Varies](#zkPerfRW).) It is especially high +performance in applications where reads outnumber writes, since writes +involve synchronizing the state of all servers. (Reads outnumbering +writes is typically the case for a coordination service.) + +<a name="zkPerfRW"></a> + + + +The [ZooKeeper Throughput as the Read-Write Ratio Varies](#zkPerfRW) is a throughput +graph of ZooKeeper release 3.2 running on servers with dual 2Ghz +Xeon and two SATA 15K RPM drives. One drive was used as a +dedicated ZooKeeper log device. The snapshots were written to +the OS drive. Write requests were 1K writes and the reads were +1K reads. "Servers" indicate the size of the ZooKeeper +ensemble, the number of servers that make up the +service. Approximately 30 other servers were used to simulate +the clients. The ZooKeeper ensemble was configured such that +leaders do not allow connections from clients. + +######Note +>In version 3.2 r/w performance improved by ~2x compared to + the [previous 3.1 release](http://zookeeper.apache.org/docs/r3.1.1/zookeeperOver.html#Performance). + +Benchmarks also indicate that it is reliable, too. +[Reliability in the Presence of Errors](#zkPerfReliability) shows how a deployment responds to +various failures. The events marked in the figure are the following: + +1. Failure and recovery of a follower +1. Failure and recovery of a different follower +1. Failure of the leader +1. Failure and recovery of two followers +1. Failure of another leader + +<a name="Reliability"></a> + +### Reliability + +To show the behavior of the system over time as +failures are injected we ran a ZooKeeper service made up of +7 machines. We ran the same saturation benchmark as before, +but this time we kept the write percentage at a constant +30%, which is a conservative ratio of our expected +workloads. + +<a name="zkPerfReliability"></a> + + + +The are a few important observations from this graph. First, if +followers fail and recover quickly, then ZooKeeper is able to sustain a +high throughput despite the failure. But maybe more importantly, the +leader election algorithm allows for the system to recover fast enough +to prevent throughput from dropping substantially. In our observations, +ZooKeeper takes less than 200ms to elect a new leader. Third, as +followers recover, ZooKeeper is able to raise throughput again once they +start processing requests. + +<a name="The+ZooKeeper+Project"></a> + +### The ZooKeeper Project + +ZooKeeper has been +[successfully used](https://cwiki.apache.org/confluence/display/ZOOKEEPER/PoweredBy) +in many industrial applications. It is used at Yahoo! as the +coordination and failure recovery service for Yahoo! Message +Broker, which is a highly scalable publish-subscribe system +managing thousands of topics for replication and data +delivery. It is used by the Fetching Service for Yahoo! +crawler, where it also manages failure recovery. A number of +Yahoo! advertising systems also use ZooKeeper to implement +reliable services. + +All users and developers are encouraged to join the +community and contribute their expertise. See the +[Zookeeper Project on Apache](http://zookeeper.apache.org/) +for more information. + + diff --git a/zookeeper-docs/src/main/resources/markdown/zookeeperProgrammers.md b/zookeeper-docs/src/main/resources/markdown/zookeeperProgrammers.md new file mode 100644 index 000000000..1048789d6 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/zookeeperProgrammers.md @@ -0,0 +1,1262 @@ +<!-- +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. +//--> + +# ZooKeeper Programmer's Guide + +### Developing Distributed Applications that use ZooKeeper + +* [Introduction](#_introduction) +* [The ZooKeeper Data Model](#ch_zkDataModel) + * [ZNodes](#sc_zkDataModel_znodes) + * [Watches](#sc_zkDataMode_watches) + * [Data Access](#Data+Access) + * [Ephemeral Nodes](#Ephemeral+Nodes) + * [Sequence Nodes -- Unique Naming](#Sequence+Nodes+--+Unique+Naming) + * [Time in ZooKeeper](#sc_timeInZk) + * [ZooKeeper Stat Structure](#sc_zkStatStructure) +* [ZooKeeper Sessions](#ch_zkSessions) +* [ZooKeeper Watches](#ch_zkWatches) + * [Semantics of Watches](#sc_WatchSemantics) + * [What ZooKeeper Guarantees about Watches](#sc_WatchGuarantees) + * [Things to Remember about Watches](#sc_WatchRememberThese) +* [ZooKeeper access control using ACLs](#sc_ZooKeeperAccessControl) + * [ACL Permissions](#sc_ACLPermissions) + * [Builtin ACL Schemes](#sc_BuiltinACLSchemes) + * [ZooKeeper C client API](#ZooKeeper+C+client+API) +* [Pluggable ZooKeeper authentication](#sc_ZooKeeperPluggableAuthentication) +* [Consistency Guarantees](#ch_zkGuarantees) +* [Bindings](#ch_bindings) + * [Java Binding](#Java+Binding) + * [C Binding](#C+Binding) + * [Installation](#Installation) + * [Building Your Own C Client](#Building+Your+Own+C+Client) +* [Building Blocks: A Guide to ZooKeeper Operations](#ch_guideToZkOperations) + * [Handling Errors](#sc_errorsZk) + * [Connecting to ZooKeeper](#sc_connectingToZk) + * [Read Operations](#sc_readOps) + * [Write Operations](#sc_writeOps) + * [Handling Watches](#sc_handlingWatches) + * [Miscelleaneous ZooKeeper Operations](#sc_miscOps) +* [Program Structure, with Simple Example](#ch_programStructureWithExample) +* [Gotchas: Common Problems and Troubleshooting](#ch_gotchas) + +<a name="_introduction"></a> + +## Introduction + +This document is a guide for developers wishing to create +distributed applications that take advantage of ZooKeeper's coordination +services. It contains conceptual and practical information. + +The first four sections of this guide present higher level +discussions of various ZooKeeper concepts. These are necessary both for an +understanding of how ZooKeeper works as well how to work with it. It does +not contain source code, but it does assume a familiarity with the +problems associated with distributed computing. The sections in this first +group are: + +* [The ZooKeeper Data Model](#ch_zkDataModel) +* [ZooKeeper Sessions](#ch_zkSessions) +* [ZooKeeper Watches](#ch_zkWatches) +* [Consistency Guarantees](#ch_zkGuarantees) + +The next four sections provide practical programming +information. These are: + +* [Building Blocks: A Guide to ZooKeeper Operations](#ch_guideToZkOperations) +* [Bindings](#ch_bindings) +* [Program Structure, with Simple Example](#ch_programStructureWithExample) + _[tbd]_ +* [Gotchas: Common Problems and Troubleshooting](#ch_gotchas) + +The book concludes with an [appendix](#apx_linksToOtherInfo) containing links to other +useful, ZooKeeper-related information. + +Most of information in this document is written to be accessible as +stand-alone reference material. However, before starting your first +ZooKeeper application, you should probably at least read the chaptes on +the [ZooKeeper Data Model](#ch_zkDataModel) and [ZooKeeper Basic Operations](#ch_guideToZkOperations). Also, +the [Simple Programmming +Example](#ch_programStructureWithExample) _[tbd]_ is helpful for understanding the basic +structure of a ZooKeeper client application. + +<a name="ch_zkDataModel"></a> + +## The ZooKeeper Data Model + +ZooKeeper has a hierarchal name space, much like a distributed file +system. The only difference is that each node in the namespace can have +data associated with it as well as children. It is like having a file +system that allows a file to also be a directory. Paths to nodes are +always expressed as canonical, absolute, slash-separated paths; there are +no relative reference. Any unicode character can be used in a path subject +to the following constraints: + +* The null character (\\u0000) cannot be part of a path name. (This + causes problems with the C binding.) +* The following characters can't be used because they don't + display well, or render in confusing ways: \\u0001 - \\u001F and \\u007F + - \\u009F. +* The following characters are not allowed: \\ud800 - uF8FF, + \\uFFF0 - uFFFF. +* The "." character can be used as part of another name, but "." + and ".." cannot alone be used to indicate a node along a path, + because ZooKeeper doesn't use relative paths. The following would be + invalid: "/a/b/./c" or "/a/b/../c". +* The token "zookeeper" is reserved. + +<a name="sc_zkDataModel_znodes"></a> + +### ZNodes + +Every node in a ZooKeeper tree is referred to as a +_znode_. Znodes maintain a stat structure that +includes version numbers for data changes, acl changes. The stat +structure also has timestamps. The version number, together with the +timestamp, allows ZooKeeper to validate the cache and to coordinate +updates. Each time a znode's data changes, the version number increases. +For instance, whenever a client retrieves data, it also receives the +version of the data. And when a client performs an update or a delete, +it must supply the version of the data of the znode it is changing. If +the version it supplies doesn't match the actual version of the data, +the update will fail. (This behavior can be overridden. For more +information see... )_[tbd...]_ + +######Note + +>In distributed application engineering, the word +_node_ can refer to a generic host machine, a +server, a member of an ensemble, a client process, etc. In the ZooKeeper +documentation, _znodes_ refer to the data nodes. +_Servers_ refer to machines that make up the +ZooKeeper service; _quorum peers_ refer to the +servers that make up an ensemble; client refers to any host or process +which uses a ZooKeeper service. + +Znodes are the main enitity that a programmer access. They have +several characteristics that are worth mentioning here. + +<a name="sc_zkDataMode_watches"></a> + +#### Watches + +Clients can set watches on znodes. Changes to that znode trigger +the watch and then clear the watch. When a watch triggers, ZooKeeper +sends the client a notification. More information about watches can be +found in the section +[ZooKeeper Watches](#ch_zkWatches). + +<a name="Data+Access"></a> + +#### Data Access + +The data stored at each znode in a namespace is read and written +atomically. Reads get all the data bytes associated with a znode and a +write replaces all the data. Each node has an Access Control List +(ACL) that restricts who can do what. + +ZooKeeper was not designed to be a general database or large +object store. Instead, it manages coordination data. This data can +come in the form of configuration, status information, rendezvous, etc. +A common property of the various forms of coordination data is that +they are relatively small: measured in kilobytes. +The ZooKeeper client and the server implementations have sanity checks +to ensure that znodes have less than 1M of data, but the data should +be much less than that on average. Operating on relatively large data +sizes will cause some operations to take much more time than others and +will affect the latencies of some operations because of the extra time +needed to move more data over the network and onto storage media. If +large data storage is needed, the usually pattern of dealing with such +data is to store it on a bulk storage system, such as NFS or HDFS, and +store pointers to the storage locations in ZooKeeper. + +<a name="Ephemeral+Nodes"></a> + +#### Ephemeral Nodes + +ZooKeeper also has the notion of ephemeral nodes. These znodes +exists as long as the session that created the znode is active. When +the session ends the znode is deleted. Because of this behavior +ephemeral znodes are not allowed to have children. + +<a name="Sequence+Nodes+--+Unique+Naming"></a> + +#### Sequence Nodes -- Unique Naming + +When creating a znode you can also request that +ZooKeeper append a monotonically increasing counter to the end +of path. This counter is unique to the parent znode. The +counter has a format of %010d -- that is 10 digits with 0 +(zero) padding (the counter is formatted in this way to +simplify sorting), i.e. "<path>0000000001". See +[Queue +Recipe](recipes.html#sc_recipes_Queues) for an example use of this feature. Note: the +counter used to store the next sequence number is a signed int +(4bytes) maintained by the parent node, the counter will +overflow when incremented beyond 2147483647 (resulting in a +name "<path>-2147483648"). + +<a name="sc_timeInZk"></a> + +### Time in ZooKeeper + +ZooKeeper tracks time multiple ways: + +* **Zxid** + Every change to the ZooKeeper state receives a stamp in the + form of a _zxid_ (ZooKeeper Transaction Id). + This exposes the total ordering of all changes to ZooKeeper. Each + change will have a unique zxid and if zxid1 is smaller than zxid2 + then zxid1 happened before zxid2. +* **Version numbers** + Every change to a node will cause an increase to one of the + version numbers of that node. The three version numbers are version + (number of changes to the data of a znode), cversion (number of + changes to the children of a znode), and aversion (number of changes + to the ACL of a znode). +* **Ticks** + When using multi-server ZooKeeper, servers use ticks to define + timing of events such as status uploads, session timeouts, + connection timeouts between peers, etc. The tick time is only + indirectly exposed through the minimum session timeout (2 times the + tick time); if a client requests a session timeout less than the + minimum session timeout, the server will tell the client that the + session timeout is actually the minimum session timeout. +* **Real time** + ZooKeeper doesn't use real time, or clock time, at all except + to put timestamps into the stat structure on znode creation and + znode modification. + +<a name="sc_zkStatStructure"></a> + +### ZooKeeper Stat Structure + +The Stat structure for each znode in ZooKeeper is made up of the +following fields: + +* **czxid** + The zxid of the change that caused this znode to be + created. +* **mzxid** + The zxid of the change that last modified this znode. +* **pzxid** + The zxid of the change that last modified children of this znode. +* **ctime** + The time in milliseconds from epoch when this znode was + created. +* **mtime** + The time in milliseconds from epoch when this znode was last + modified. +* **version** + The number of changes to the data of this znode. +* **cversion** + The number of changes to the children of this znode. +* **aversion** + The number of changes to the ACL of this znode. +* **ephemeralOwner** + The session id of the owner of this znode if the znode is an + ephemeral node. If it is not an ephemeral node, it will be + zero. +* **dataLength** + The length of the data field of this znode. +* **numChildren** + The number of children of this znode. + +<a name="ch_zkSessions"></a> + +## ZooKeeper Sessions + +A ZooKeeper client establishes a session with the ZooKeeper +service by creating a handle to the service using a language +binding. Once created, the handle starts of in the CONNECTING state +and the client library tries to connect to one of the servers that +make up the ZooKeeper service at which point it switches to the +CONNECTED state. During normal operation will be in one of these +two states. If an unrecoverable error occurs, such as session +expiration or authentication failure, or if the application explicitly +closes the handle, the handle will move to the CLOSED state. +The following figure shows the possible state transitions of a +ZooKeeper client: + + + +To create a client session the application code must provide +a connection string containing a comma separated list of host:port pairs, +each corresponding to a ZooKeeper server (e.g. "127.0.0.1:4545" or +"127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002"). The ZooKeeper +client library will pick an arbitrary server and try to connect to +it. If this connection fails, or if the client becomes +disconnected from the server for any reason, the client will +automatically try the next server in the list, until a connection +is (re-)established. + +**Added in 3.2.0**: An +optional "chroot" suffix may also be appended to the connection +string. This will run the client commands while interpreting all +paths relative to this root (similar to the unix chroot +command). If used the example would look like: +"127.0.0.1:4545/app/a" or +"127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002/app/a" where the +client would be rooted at "/app/a" and all paths would be relative +to this root - ie getting/setting/etc... "/foo/bar" would result +in operations being run on "/app/a/foo/bar" (from the server +perspective). This feature is particularly useful in multi-tenant +environments where each user of a particular ZooKeeper service +could be rooted differently. This makes re-use much simpler as +each user can code his/her application as if it were rooted at +"/", while actual location (say /app/a) could be determined at +deployment time. + +When a client gets a handle to the ZooKeeper service, +ZooKeeper creates a ZooKeeper session, represented as a 64-bit +number, that it assigns to the client. If the client connects to a +different ZooKeeper server, it will send the session id as a part +of the connection handshake. As a security measure, the server +creates a password for the session id that any ZooKeeper server +can validate.The password is sent to the client with the session +id when the client establishes the session. The client sends this +password with the session id whenever it reestablishes the session +with a new server. + +One of the parameters to the ZooKeeper client library call +to create a ZooKeeper session is the session timeout in +milliseconds. The client sends a requested timeout, the server +responds with the timeout that it can give the client. The current +implementation requires that the timeout be a minimum of 2 times +the tickTime (as set in the server configuration) and a maximum of +20 times the tickTime. The ZooKeeper client API allows access to +the negotiated timeout. + +When a client (session) becomes partitioned from the ZK +serving cluster it will begin searching the list of servers that +were specified during session creation. Eventually, when +connectivity between the client and at least one of the servers is +re-established, the session will either again transition to the +"connected" state (if reconnected within the session timeout +value) or it will transition to the "expired" state (if +reconnected after the session timeout). It is not advisable to +create a new session object (a new ZooKeeper.class or zookeeper +handle in the c binding) for disconnection. The ZK client library +will handle reconnect for you. In particular we have heuristics +built into the client library to handle things like "herd effect", +etc... Only create a new session when you are notified of session +expiration (mandatory). + +Session expiration is managed by the ZooKeeper cluster +itself, not by the client. When the ZK client establishes a +session with the cluster it provides a "timeout" value detailed +above. This value is used by the cluster to determine when the +client's session expires. Expirations happens when the cluster +does not hear from the client within the specified session timeout +period (i.e. no heartbeat). At session expiration the cluster will +delete any/all ephemeral nodes owned by that session and +immediately notify any/all connected clients of the change (anyone +watching those znodes). At this point the client of the expired +session is still disconnected from the cluster, it will not be +notified of the session expiration until/unless it is able to +re-establish a connection to the cluster. The client will stay in +disconnected state until the TCP connection is re-established with +the cluster, at which point the watcher of the expired session +will receive the "session expired" notification. + +Example state transitions for an expired session as seen by +the expired session's watcher: + +1. 'connected' : session is established and client + is communicating with cluster (client/server communication is + operating properly) +1. .... client is partitioned from the + cluster +1. 'disconnected' : client has lost connectivity + with the cluster +1. .... time elapses, after 'timeout' period the + cluster expires the session, nothing is seen by client as it is + disconnected from cluster +1. .... time elapses, the client regains network + level connectivity with the cluster +1. 'expired' : eventually the client reconnects to + the cluster, it is then notified of the + expiration + +Another parameter to the ZooKeeper session establishment +call is the default watcher. Watchers are notified when any state +change occurs in the client. For example if the client loses +connectivity to the server the client will be notified, or if the +client's session expires, etc... This watcher should consider the +initial state to be disconnected (i.e. before any state changes +events are sent to the watcher by the client lib). In the case of +a new connection, the first event sent to the watcher is typically +the session connection event. + +The session is kept alive by requests sent by the client. If +the session is idle for a period of time that would timeout the +session, the client will send a PING request to keep the session +alive. This PING request not only allows the ZooKeeper server to +know that the client is still active, but it also allows the +client to verify that its connection to the ZooKeeper server is +still active. The timing of the PING is conservative enough to +ensure reasonable time to detect a dead connection and reconnect +to a new server. + +Once a connection to the server is successfully established +(connected) there are basically two cases where the client lib generates +connectionloss (the result code in c binding, exception in Java -- see +the API documentation for binding specific details) when either a synchronous or +asynchronous operation is performed and one of the following holds: + +1. The application calls an operation on a session that is no + longer alive/valid +1. The ZooKeeper client disconnects from a server when there + are pending operations to that server, i.e., there is a pending asynchronous call. + +**Added in 3.2.0 -- SessionMovedException**. There is an internal +exception that is generally not seen by clients called the SessionMovedException. +This exception occurs because a request was received on a connection for a session +which has been reestablished on a different server. The normal cause of this error is +a client that sends a request to a server, but the network packet gets delayed, so +the client times out and connects to a new server. When the delayed packet arrives at +the first server, the old server detects that the session has moved, and closes the +client connection. Clients normally do not see this error since they do not read +from those old connections. (Old connections are usually closed.) One situation in which this +condition can be seen is when two clients try to reestablish the same connection using +a saved session id and password. One of the clients will reestablish the connection +and the second client will be disconnected (causing the pair to attempt to re-establish +its connection/session indefinitely). + +<a name="ch_zkWatches"></a> + +## ZooKeeper Watches + +All of the read operations in ZooKeeper - **getData()**, **getChildren()**, and **exists()** - have the option of setting a watch as a +side effect. Here is ZooKeeper's definition of a watch: a watch event is +one-time trigger, sent to the client that set the watch, which occurs when +the data for which the watch was set changes. There are three key points +to consider in this definition of a watch: + +* **One-time trigger** + One watch event will be sent to the client when the data has changed. + For example, if a client does a getData("/znode1", true) and later the + data for /znode1 is changed or deleted, the client will get a watch + event for /znode1. If /znode1 changes again, no watch event will be + sent unless the client has done another read that sets a new + watch. +* **Sent to the client** + This implies that an event is on the way to the client, but may + not reach the client before the successful return code to the change + operation reaches the client that initiated the change. Watches are + sent asynchronously to watchers. ZooKeeper provides an ordering + guarantee: a client will never see a change for which it has set a + watch until it first sees the watch event. Network delays or other + factors may cause different clients to see watches and return codes + from updates at different times. The key point is that everything seen + by the different clients will have a consistent order. +* **The data for which the watch was + set** + This refers to the different ways a node can change. It + helps to think of ZooKeeper as maintaining two lists of + watches: data watches and child watches. getData() and + exists() set data watches. getChildren() sets child + watches. Alternatively, it may help to think of watches being + set according to the kind of data returned. getData() and + exists() return information about the data of the node, + whereas getChildren() returns a list of children. Thus, + setData() will trigger data watches for the znode being set + (assuming the set is successful). A successful create() will + trigger a data watch for the znode being created and a child + watch for the parent znode. A successful delete() will trigger + both a data watch and a child watch (since there can be no + more children) for a znode being deleted as well as a child + watch for the parent znode. + +Watches are maintained locally at the ZooKeeper server to which the +client is connected. This allows watches to be lightweight to set, +maintain, and dispatch. When a client connects to a new server, the watch +will be triggered for any session events. Watches will not be received +while disconnected from a server. When a client reconnects, any previously +registered watches will be reregistered and triggered if needed. In +general this all occurs transparently. There is one case where a watch +may be missed: a watch for the existence of a znode not yet created will +be missed if the znode is created and deleted while disconnected. + +<a name="sc_WatchSemantics"></a> + +### Semantics of Watches + +We can set watches with the three calls that read the state of +ZooKeeper: exists, getData, and getChildren. The following list details +the events that a watch can trigger and the calls that enable them: + +* **Created event:** + Enabled with a call to exists. +* **Deleted event:** + Enabled with a call to exists, getData, and getChildren. +* **Changed event:** + Enabled with a call to exists and getData. +* **Child event:** + Enabled with a call to getChildren. + +<a name="sc_WatchGuarantees"></a> + +### What ZooKeeper Guarantees about Watches + +With regard to watches, ZooKeeper maintains these +guarantees: + +* Watches are ordered with respect to other events, other + watches, and asynchronous replies. The ZooKeeper client libraries + ensures that everything is dispatched in order. + +* A client will see a watch event for a znode it is watching + before seeing the new data that corresponds to that znode. + +* The order of watch events from ZooKeeper corresponds to the + order of the updates as seen by the ZooKeeper service. + +<a name="sc_WatchRememberThese"></a> + +### Things to Remember about Watches + +* Watches are one time triggers; if you get a watch event and + you want to get notified of future changes, you must set another + watch. + +* Because watches are one time triggers and there is latency + between getting the event and sending a new request to get a watch + you cannot reliably see every change that happens to a node in + ZooKeeper. Be prepared to handle the case where the znode changes + multiple times between getting the event and setting the watch + again. (You may not care, but at least realize it may + happen.) + +* A watch object, or function/context pair, will only be + triggered once for a given notification. For example, if the same + watch object is registered for an exists and a getData call for the + same file and that file is then deleted, the watch object would + only be invoked once with the deletion notification for the file. + +* When you disconnect from a server (for example, when the + server fails), you will not get any watches until the connection + is reestablished. For this reason session events are sent to all + outstanding watch handlers. Use session events to go into a safe + mode: you will not be receiving events while disconnected, so your + process should act conservatively in that mode. + +<a name="sc_ZooKeeperAccessControl"></a> + +## ZooKeeper access control using ACLs + +ZooKeeper uses ACLs to control access to its znodes (the +data nodes of a ZooKeeper data tree). The ACL implementation is +quite similar to UNIX file access permissions: it employs +permission bits to allow/disallow various operations against a +node and the scope to which the bits apply. Unlike standard UNIX +permissions, a ZooKeeper node is not limited by the three standard +scopes for user (owner of the file), group, and world +(other). ZooKeeper does not have a notion of an owner of a +znode. Instead, an ACL specifies sets of ids and permissions that +are associated with those ids. + +Note also that an ACL pertains only to a specific znode. In +particular it does not apply to children. For example, if +_/app_ is only readable by ip:172.16.16.1 and +_/app/status_ is world readable, anyone will +be able to read _/app/status_; ACLs are not +recursive. + +ZooKeeper supports pluggable authentication schemes. Ids are +specified using the form _scheme:expression_, +where _scheme_ is the authentication scheme +that the id corresponds to. The set of valid expressions are defined +by the scheme. For example, _ip:172.16.16.1_ is +an id for a host with the address _172.16.16.1_ +using the _ip_ scheme, whereas _digest:bob:password_ +is an id for the user with the name of _bob_ using +the _digest_ scheme. + +When a client connects to ZooKeeper and authenticates +itself, ZooKeeper associates all the ids that correspond to a +client with the clients connection. These ids are checked against +the ACLs of znodes when a clients tries to access a node. ACLs are +made up of pairs of _(scheme:expression, +perms)_. The format of +the _expression_ is specific to the scheme. For +example, the pair _(ip:19.22.0.0/16, READ)_ +gives the _READ_ permission to any clients with +an IP address that starts with 19.22. + +<a name="sc_ACLPermissions"></a> + +### ACL Permissions + +ZooKeeper supports the following permissions: + +* **CREATE**: you can create a child node +* **READ**: you can get data from a node and list its children. +* **WRITE**: you can set data for a node +* **DELETE**: you can delete a child node +* **ADMIN**: you can set permissions + +The _CREATE_ +and _DELETE_ permissions have been broken out +of the _WRITE_ permission for finer grained +access controls. The cases for _CREATE_ +and _DELETE_ are the following: + +You want A to be able to do a set on a ZooKeeper node, but +not be able to _CREATE_ +or _DELETE_ children. + +_CREATE_ +without _DELETE_: clients create requests by +creating ZooKeeper nodes in a parent directory. You want all +clients to be able to add, but only request processor can +delete. (This is kind of like the APPEND permission for +files.) + +Also, the _ADMIN_ permission is there +since ZooKeeper doesn’t have a notion of file owner. In some +sense the _ADMIN_ permission designates the +entity as the owner. ZooKeeper doesn’t support the LOOKUP +permission (execute permission bit on directories to allow you +to LOOKUP even though you can't list the directory). Everyone +implicitly has LOOKUP permission. This allows you to stat a +node, but nothing more. (The problem is, if you want to call +zoo_exists() on a node that doesn't exist, there is no +permission to check.) + +<a name="sc_BuiltinACLSchemes"></a> + +#### Builtin ACL Schemes + +ZooKeeeper has the following built in schemes: + +* **world** has a + single id, _anyone_, that represents + anyone. +* **auth** is a special + scheme which ignores any provided expression and instead uses the current user, + credentials, and scheme. Any expression (whether _user_ like with SASL + authentication or _user:password_ like with DIGEST authentication) provided is ignored + by the ZooKeeper server when persisting the ACL. However, the expression must still be + provided in the ACL because the ACL must match the form _scheme:expression:perms_. + This scheme is provided as a convenience as it is a common use-case for + a user to create a znode and then restrict access to that znode to only that user. + If there is no authenticated user, setting an ACL with the auth scheme will fail. +* **digest** uses + a _username:password_ string to generate + MD5 hash which is then used as an ACL ID + identity. Authentication is done by sending + the _username:password_ in clear text. When + used in the ACL the expression will be + the _username:base64_ + encoded _SHA1_ + password _digest_. +* **ip** uses the + client host IP as an ACL ID identity. The ACL expression is of + the form _addr/bits_ where the most + significant _bits_ + of _addr_ are matched against the most + significant _bits_ of the client host + IP. +* **x509** uses the client + X500 Principal as an ACL ID identity. The ACL expression is the exact + X500 Principal name of a client. When using the secure port, clients + are automatically authenticated and their auth info for the x509 scheme + is set. + +<a name="ZooKeeper+C+client+API"></a> + +#### ZooKeeper C client API + +The following constants are provided by the ZooKeeper C +library: + +* _const_ _int_ ZOO_PERM_READ; //can read node’s value and list its children +* _const_ _int_ ZOO_PERM_WRITE;// can set the node’s value +* _const_ _int_ ZOO_PERM_CREATE; //can create children +* _const_ _int_ ZOO_PERM_DELETE;// can delete children +* _const_ _int_ ZOO_PERM_ADMIN; //can execute set_acl() +* _const_ _int_ ZOO_PERM_ALL;// all of the above flags OR’d together + +The following are the standard ACL IDs: + +* _struct_ Id ZOO_ANYONE_ID_UNSAFE; //(‘world’,’anyone’) +* _struct_ Id ZOO_AUTH_IDS;// (‘auth’,’’) + +ZOO_AUTH_IDS empty identity string should be interpreted as “the identity of the creator”. + +ZooKeeper client comes with three standard ACLs: + +* _struct_ ACL_vector ZOO_OPEN_ACL_UNSAFE; //(ZOO_PERM_ALL,ZOO_ANYONE_ID_UNSAFE) +* _struct_ ACL_vector ZOO_READ_ACL_UNSAFE;// (ZOO_PERM_READ, ZOO_ANYONE_ID_UNSAFE) +* _struct_ ACL_vector ZOO_CREATOR_ALL_ACL; //(ZOO_PERM_ALL,ZOO_AUTH_IDS) + +The ZOO_OPEN_ACL_UNSAFE is completely open free for all +ACL: any application can execute any operation on the node and +can create, list and delete its children. The +ZOO_READ_ACL_UNSAFE is read-only access for any +application. CREATE_ALL_ACL grants all permissions to the +creator of the node. The creator must have been authenticated by +the server (for example, using “_digest_” +scheme) before it can create nodes with this ACL. + +The following ZooKeeper operations deal with ACLs: + +* _int_ _zoo_add_auth_ + (zhandle_t \*zh,_const_ _char_* + scheme,_const_ _char_* + cert, _int_ certLen, void_completion_t + completion, _const_ _void_ + \*data); + +The application uses the zoo_add_auth function to +authenticate itself to the server. The function can be called +multiple times if the application wants to authenticate using +different schemes and/or identities. + +* _int_ _zoo_create_ + (zhandle_t \*zh, _const_ _char_ + \*path, _const_ _char_ + \*value,_int_ + valuelen, _const_ _struct_ + ACL_vector \*acl, _int_ + flags,_char_ + \*realpath, _int_ + max_realpath_len); + +zoo_create(...) operation creates a new node. The acl +parameter is a list of ACLs associated with the node. The parent +node must have the CREATE permission bit set. + +* _int_ _zoo_get_acl_ + (zhandle_t \*zh, _const_ _char_ + \*path,_struct_ ACL_vector + \*acl, _struct_ Stat \*stat); + +This operation returns a node’s ACL info. + +* _int_ _zoo_set_acl_ + (zhandle_t \*zh, _const_ _char_ + \*path, _int_ + version,_const_ _struct_ + ACL_vector \*acl); + +This function replaces node’s ACL list with a new one. The +node must have the ADMIN permission set. + +Here is a sample code that makes use of the above APIs to +authenticate itself using the “_foo_” scheme +and create an ephemeral node “/xyz” with create-only +permissions. + +######Note +>This is a very simple example which is intended to show +how to interact with ZooKeeper ACLs +specifically. See *.../trunk/zookeeper-client/zookeeper-client-c/src/cli.c* +for an example of a C client implementation + + + + #include <string.h> + #include <errno.h> + + #include "zookeeper.h" + + static zhandle_t *zh; + + /** + * In this example this method gets the cert for your + * environment -- you must provide + */ + char *foo_get_cert_once(char* id) { return 0; } + + /** Watcher function -- empty for this example, not something you should + * do in real code */ + void watcher(zhandle_t *zzh, int type, int state, const char *path, + void *watcherCtx) {} + + int main(int argc, char argv) { + char buffer[512]; + char p[2048]; + char *cert=0; + char appId[64]; + + strcpy(appId, "example.foo_test"); + cert = foo_get_cert_once(appId); + if(cert!=0) { + fprintf(stderr, + "Certificate for appid [%s] is [%s]\n",appId,cert); + strncpy(p,cert, sizeof(p)-1); + free(cert); + } else { + fprintf(stderr, "Certificate for appid [%s] not found\n",appId); + strcpy(p, "dummy"); + } + + zoo_set_debug_level(ZOO_LOG_LEVEL_DEBUG); + + zh = zookeeper_init("localhost:3181", watcher, 10000, 0, 0, 0); + if (!zh) { + return errno; + } + if(zoo_add_auth(zh,"foo",p,strlen(p),0,0)!=ZOK) + return 2; + + struct ACL CREATE_ONLY_ACL[] = {{ZOO_PERM_CREATE, ZOO_AUTH_IDS}}; + struct ACL_vector CREATE_ONLY = {1, CREATE_ONLY_ACL}; + int rc = zoo_create(zh,"/xyz","value", 5, &CREATE_ONLY, ZOO_EPHEMERAL, + buffer, sizeof(buffer)-1); + + /** this operation will fail with a ZNOAUTH error */ + int buflen= sizeof(buffer); + struct Stat stat; + rc = zoo_get(zh, "/xyz", 0, buffer, &buflen, &stat); + if (rc) { + fprintf(stderr, "Error %d for %s\n", rc, __LINE__); + } + + zookeeper_close(zh); + return 0; + } + + +<a name="sc_ZooKeeperPluggableAuthentication"></a> + +## Pluggable ZooKeeper authentication + +ZooKeeper runs in a variety of different environments with +various different authentication schemes, so it has a completely +pluggable authentication framework. Even the builtin authentication +schemes use the pluggable authentication framework. + +To understand how the authentication framework works, first you must +understand the two main authentication operations. The framework +first must authenticate the client. This is usually done as soon as +the client connects to a server and consists of validating information +sent from or gathered about a client and associating it with the connection. +The second operation handled by the framework is finding the entries in an +ACL that correspond to client. ACL entries are <_idspec, +permissions_> pairs. The _idspec_ may be +a simple string match against the authentication information associated +with the connection or it may be a expression that is evaluated against that +information. It is up to the implementation of the authentication plugin +to do the match. Here is the interface that an authentication plugin must +implement: + + + public interface AuthenticationProvider { + String getScheme(); + KeeperException.Code handleAuthentication(ServerCnxn cnxn, byte authData[]); + boolean isValid(String id); + boolean matches(String id, String aclExpr); + boolean isAuthenticated(); + } + + +The first method _getScheme_ returns the string +that identifies the plugin. Because we support multiple methods of authentication, +an authentication credential or an _idspec_ will always be +prefixed with _scheme:_. The ZooKeeper server uses the scheme +returned by the authentication plugin to determine which ids the scheme +applies to. + +_handleAuthentication_ is called when a client +sends authentication information to be associated with a connection. The +client specifies the scheme to which the information corresponds. The +ZooKeeper server passes the information to the authentication plugin whose +_getScheme_ matches the scheme passed by the client. The +implementor of _handleAuthentication_ will usually return +an error if it determines that the information is bad, or it will associate information +with the connection using _cnxn.getAuthInfo().add(new Id(getScheme(), data))_. + +The authentication plugin is involved in both setting and using ACLs. When an +ACL is set for a znode, the ZooKeeper server will pass the id part of the entry to +the _isValid(String id)_ method. It is up to the plugin to verify +that the id has a correct form. For example, _ip:172.16.0.0/16_ +is a valid id, but _ip:host.com_ is not. If the new ACL includes +an "auth" entry, _isAuthenticated_ is used to see if the +authentication information for this scheme that is assocatied with the connection +should be added to the ACL. Some schemes +should not be included in auth. For example, the IP address of the client is not +considered as an id that should be added to the ACL if auth is specified. + +ZooKeeper invokes _matches(String id, String aclExpr)_ when checking an ACL. It +needs to match authentication information of the client against the relevant ACL +entries. To find the entries which apply to the client, the ZooKeeper server will +find the scheme of each entry and if there is authentication information +from that client for that scheme, _matches(String id, String aclExpr)_ +will be called with _id_ set to the authentication information +that was previously added to the connection by _handleAuthentication_ and +_aclExpr_ set to the id of the ACL entry. The authentication plugin +uses its own logic and matching scheme to determine if _id_ is included +in _aclExpr_. + +There are two built in authentication plugins: _ip_ and +_digest_. Additional plugins can adding using system properties. At +startup the ZooKeeper server will look for system properties that start with +"zookeeper.authProvider." and interpret the value of those properties as the class name +of an authentication plugin. These properties can be set using the +_-Dzookeeeper.authProvider.X=com.f.MyAuth_ or adding entries such as +the following in the server configuration file: + + + authProvider.1=com.f.MyAuth + authProvider.2=com.f.MyAuth2 + + +Care should be taking to ensure that the suffix on the property is unique. If there are +duplicates such as _-Dzookeeeper.authProvider.X=com.f.MyAuth -Dzookeeper.authProvider.X=com.f.MyAuth2_, +only one will be used. Also all servers must have the same plugins defined, otherwise clients using +the authentication schemes provided by the plugins will have problems connecting to some servers. + +<a name="ch_zkGuarantees"></a> + +## Consistency Guarantees + +ZooKeeper is a high performance, scalable service. Both reads and +write operations are designed to be fast, though reads are faster than +writes. The reason for this is that in the case of reads, ZooKeeper can +serve older data, which in turn is due to ZooKeeper's consistency +guarantees: + +* *Sequential Consistency* : + Updates from a client will be applied in the order that they + were sent. + +* *Atomicity* : + Updates either succeed or fail -- there are no partial + results. + +* *Single System Image* : + A client will see the same view of the service regardless of + the server that it connects to. + +* *Reliability* : + Once an update has been applied, it will persist from that + time forward until a client overwrites the update. This guarantee + has two corollaries: + 1. If a client gets a successful return code, the update will + have been applied. On some failures (communication errors, + timeouts, etc) the client will not know if the update has + applied or not. We take steps to minimize the failures, but the + guarantee is only present with successful return codes. + (This is called the _monotonicity condition_ in Paxos.) + 1. Any updates that are seen by the client, through a read + request or successful update, will never be rolled back when + recovering from server failures. + +* *Timeliness* : + The clients view of the system is guaranteed to be up-to-date + within a certain time bound (on the order of tens of seconds). + Either system changes will be seen by a client within this bound, or + the client will detect a service outage. + +Using these consistency guarantees it is easy to build higher level +functions such as leader election, barriers, queues, and read/write +revocable locks solely at the ZooKeeper client (no additions needed to +ZooKeeper). See [Recipes and Solutions](recipes.html) +for more details. + +######Note + +>Sometimes developers mistakenly assume one other guarantee that +ZooKeeper does _not_ in fact make. This is: +> * Simultaneously Consistent Cross-Client Views* : + ZooKeeper does not guarantee that at every instance in + time, two different clients will have identical views of + ZooKeeper data. Due to factors like network delays, one client + may perform an update before another client gets notified of the + change. Consider the scenario of two clients, A and B. If client + A sets the value of a znode /a from 0 to 1, then tells client B + to read /a, client B may read the old value of 0, depending on + which server it is connected to. If it + is important that Client A and Client B read the same value, + Client B should should call the **sync()** method from the ZooKeeper API + method before it performs its read. + So, ZooKeeper by itself doesn't guarantee that changes occur + synchronously across all servers, but ZooKeeper + primitives can be used to construct higher level functions that + provide useful client synchronization. (For more information, + see the [ZooKeeper Recipes](recipes.html). + _[tbd:..]_). + +<a name="ch_bindings"></a> + +## Bindings + +The ZooKeeper client libraries come in two languages: Java and C. +The following sections describe these. + +<a name="Java+Binding"></a> + +### Java Binding + +There are two packages that make up the ZooKeeper Java binding: +**org.apache.zookeeper** and **org.apache.zookeeper.data**. The rest of the +packages that make up ZooKeeper are used internally or are part of the +server implementation. The **org.apache.zookeeper.data** package is made up of +generated classes that are used simply as containers. + +The main class used by a ZooKeeper Java client is the **ZooKeeper** class. Its two constructors differ only +by an optional session id and password. ZooKeeper supports session +recovery accross instances of a process. A Java program may save its +session id and password to stable storage, restart, and recover the +session that was used by the earlier instance of the program. + +When a ZooKeeper object is created, two threads are created as +well: an IO thread and an event thread. All IO happens on the IO thread +(using Java NIO). All event callbacks happen on the event thread. +Session maintenance such as reconnecting to ZooKeeper servers and +maintaining heartbeat is done on the IO thread. Responses for +synchronous methods are also processed in the IO thread. All responses +to asynchronous methods and watch events are processed on the event +thread. There are a few things to notice that result from this +design: + +* All completions for asynchronous calls and watcher callbacks + will be made in order, one at a time. The caller can do any + processing they wish, but no other callbacks will be processed + during that time. +* Callbacks do not block the processing of the IO thread or the + processing of the synchronous calls. +* Synchronous calls may not return in the correct order. For + example, assume a client does the following processing: issues an + asynchronous read of node **/a** with + _watch_ set to true, and then in the completion + callback of the read it does a synchronous read of **/a**. (Maybe not good practice, but not illegal + either, and it makes for a simple example.) + Note that if there is a change to **/a** between the asynchronous read and the + synchronous read, the client library will receive the watch event + saying **/a** changed before the + response for the synchronous read, but because the completion + callback is blocking the event queue, the synchronous read will + return with the new value of **/a** + before the watch event is processed. + +Finally, the rules associated with shutdown are straightforward: +once a ZooKeeper object is closed or receives a fatal event +(SESSION_EXPIRED and AUTH_FAILED), the ZooKeeper object becomes invalid. +On a close, the two threads shut down and any further access on zookeeper +handle is undefined behavior and should be avoided. + +<a name="C+Binding"></a> + +### C Binding + +The C binding has a single-threaded and multi-threaded library. +The multi-threaded library is easiest to use and is most similar to the +Java API. This library will create an IO thread and an event dispatch +thread for handling connection maintenance and callbacks. The +single-threaded library allows ZooKeeper to be used in event driven +applications by exposing the event loop used in the multi-threaded +library. + +The package includes two shared libraries: zookeeper_st and +zookeeper_mt. The former only provides the asynchronous APIs and +callbacks for integrating into the application's event loop. The only +reason this library exists is to support the platforms were a +_pthread_ library is not available or is unstable +(i.e. FreeBSD 4.x). In all other cases, application developers should +link with zookeeper_mt, as it includes support for both Sync and Async +API. + +<a name="Installation"></a> + +#### Installation + +If you're building the client from a check-out from the Apache +repository, follow the steps outlined below. If you're building from a +project source package downloaded from apache, skip to step **3**. + +1. Run `ant compile_jute` from the ZooKeeper + top level directory (*.../trunk*). + This will create a directory named "generated" under + *.../trunk/zookeeper-client/zookeeper-client-c*. +2. Change directory to the*.../trunk/zookeeper-client/zookeeper-client-c* + and run `autoreconf -if` to bootstrap **autoconf**, **automake** and **libtool**. Make sure you have **autoconf version 2.59** or greater installed. + Skip to step**4**. +3. If you are building from a project source package, + unzip/untar the source tarball and cd to the* + zookeeper-x.x.x/zookeeper-client/zookeeper-client-c* directory. +4. Run `./configure <your-options>` to + generate the makefile. Here are some of options the **configure** utility supports that can be + useful in this step: + * `--enable-debug` + Enables optimization and enables debug info compiler + options. (Disabled by default.) + * `--without-syncapi` + Disables Sync API support; zookeeper_mt library won't be + built. (Enabled by default.) + * `--disable-static` + Do not build static libraries. (Enabled by + default.) + * `--disable-shared` + Do not build shared libraries. (Enabled by + default.) +######Note +>See INSTALL for general information about running **configure**. +5. Run `make` or `make + install` to build the libraries and install them. +6. To generate doxygen documentation for the ZooKeeper API, run + `make doxygen-doc`. All documentation will be + placed in a new subfolder named docs. By default, this command + only generates HTML. For information on other document formats, + run `./configure --help` + +<a name="Building+Your+Own+C+Client"></a> + +#### Building Your Own C Client + +In order to be able to use the ZooKeeper C API in your application +you have to remember to + +1. Include ZooKeeper header: `#include <zookeeper/zookeeper.h>` +1. If you are building a multithreaded client, compile with + `-DTHREADED` compiler flag to enable the multi-threaded version of + the library, and then link against against the + _zookeeper_mt_ library. If you are building a + single-threaded client, do not compile with `-DTHREADED`, and be + sure to link against the_zookeeper_st_library. + +######Note +>See *.../trunk/zookeeper-client/zookeeper-client-c/src/cli.c* +for an example of a C client implementation + +<a name="ch_guideToZkOperations"></a> + +## Building Blocks: A Guide to ZooKeeper Operations + +This section surveys all the operations a developer can perform +against a ZooKeeper server. It is lower level information than the earlier +concepts chapters in this manual, but higher level than the ZooKeeper API +Reference. It covers these topics: + +* [Connecting to ZooKeeper](#sc_connectingToZk) + +<a name="sc_errorsZk"></a> + +### Handling Errors + +Both the Java and C client bindings may report errors. The Java client binding does so by throwing KeeperException, calling code() on the exception will return the specific error code. The C client binding returns an error code as defined in the enum ZOO_ERRORS. API callbacks indicate result code for both language bindings. See the API documentation (javadoc for Java, doxygen for C) for full details on the possible errors and their meaning. + +<a name="sc_connectingToZk"></a> + +### Connecting to ZooKeeper + +<a name="sc_readOps"></a> + +### Read Operations + +<a name="sc_writeOps"></a> + +### Write Operations + +<a name="sc_handlingWatches"></a> + +### Handling Watches + +<a name="sc_miscOps"></a> + +### Miscelleaneous ZooKeeper Operations + +<a name="ch_programStructureWithExample"></a> + +## Program Structure, with Simple Example + +_[tbd]_ + +<a name="ch_gotchas"></a> + +## Gotchas: Common Problems and Troubleshooting + +So now you know ZooKeeper. It's fast, simple, your application +works, but wait ... something's wrong. Here are some pitfalls that +ZooKeeper users fall into: + +1. If you are using watches, you must look for the connected watch + event. When a ZooKeeper client disconnects from a server, you will + not receive notification of changes until reconnected. If you are + watching for a znode to come into existence, you will miss the event + if the znode is created and deleted while you are disconnected. +1. You must test ZooKeeper server failures. The ZooKeeper service + can survive failures as long as a majority of servers are active. The + question to ask is: can your application handle it? In the real world + a client's connection to ZooKeeper can break. (ZooKeeper server + failures and network partitions are common reasons for connection + loss.) The ZooKeeper client library takes care of recovering your + connection and letting you know what happened, but you must make sure + that you recover your state and any outstanding requests that failed. + Find out if you got it right in the test lab, not in production - test + with a ZooKeeper service made up of a several of servers and subject + them to reboots. +1. The list of ZooKeeper servers used by the client must match the + list of ZooKeeper servers that each ZooKeeper server has. Things can + work, although not optimally, if the client list is a subset of the + real list of ZooKeeper servers, but not if the client lists ZooKeeper + servers not in the ZooKeeper cluster. +1. Be careful where you put that transaction log. The most + performance-critical part of ZooKeeper is the transaction log. + ZooKeeper must sync transactions to media before it returns a + response. A dedicated transaction log device is key to consistent good + performance. Putting the log on a busy device will adversely effect + performance. If you only have one storage device, put trace files on + NFS and increase the snapshotCount; it doesn't eliminate the problem, + but it can mitigate it. +1. Set your Java max heap size correctly. It is very important to + _avoid swapping._ Going to disk unnecessarily will + almost certainly degrade your performance unacceptably. Remember, in + ZooKeeper, everything is ordered, so if one request hits the disk, all + other queued requests hit the disk. + To avoid swapping, try to set the heapsize to the amount of + physical memory you have, minus the amount needed by the OS and cache. + The best way to determine an optimal heap size for your configurations + is to _run load tests_. If for some reason you + can't, be conservative in your estimates and choose a number well + below the limit that would cause your machine to swap. For example, on + a 4G machine, a 3G heap is a conservative estimate to start + with. + +## Links to Other Information + +Outside the formal documentation, there're several other sources of +information for ZooKeeper developers. + +* *ZooKeeper Whitepaper _[tbd: find url]_* : + The definitive discussion of ZooKeeper design and performance, + by Yahoo! Research + +* *API Reference _[tbd: find url]_* : + The complete reference to the ZooKeeper API + +* *[ZooKeeper Talk at the Hadoup Summit 2008](http://us.dl1.yimg.com/download.yahoo.com/dl/ydn/zookeeper.m4v)* : + A video introduction to ZooKeeper, by Benjamin Reed of Yahoo! + Research + +* *[Barrier and Queue Tutorial](https://cwiki.apache.org/confluence/display/ZOOKEEPER/Tutorial)* : + The excellent Java tutorial by Flavio Junqueira, implementing + simple barriers and producer-consumer queues using ZooKeeper. + +* *[ZooKeeper - A Reliable, Scalable Distributed Coordination System](https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeperArticles)* : + An article by Todd Hoff (07/15/2008) + +* *[ZooKeeper Recipes](recipes.html)* : + Pseudo-level discussion of the implementation of various + synchronization solutions with ZooKeeper: Event Handles, Queues, + Locks, and Two-phase Commits. + +* *_[tbd]_* : + Any other good sources anyone can think of... + diff --git a/zookeeper-docs/src/main/resources/markdown/zookeeperQuotas.md b/zookeeper-docs/src/main/resources/markdown/zookeeperQuotas.md new file mode 100644 index 000000000..b573d4cb6 --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/zookeeperQuotas.md @@ -0,0 +1,61 @@ +<!-- +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. +//--> + +# ZooKeeper Quota's Guide + +### A Guide to Deployment and Administration + +* [Quotas](#zookeeper_quotas) + * [Setting Quotas](#Setting+Quotas) + * [Listing Quotas](#Listing+Quotas) + * [Deleting Quotas](#Deleting+Quotas) + +<a name="zookeeper_quotas"></a> + +## Quotas + +ZooKeeper has both namespace and bytes quotas. You can use the ZooKeeperMain class to setup quotas. +ZooKeeper prints _WARN_ messages if users exceed the quota assigned to them. The messages +are printed in the log of the ZooKeeper. + + $ bin/zkCli.sh -server host:port** + +The above command gives you a command line option of using quotas. + +<a name="Setting+Quotas"></a> + +### Setting Quotas + +You can use _setquota_ to set a quota on a ZooKeeper node. It has an option of setting quota with +`-n` (for namespace) +and `-b` (for bytes). + +The ZooKeeper quota are stored in ZooKeeper itself in /zookeeper/quota. To disable other people from +changing the quota's set the ACL for /zookeeper/quota such that only admins are able to read and write to it. + +<a name="Listing+Quotas"></a> + +### Listing Quotas + +You can use _listquota_ to list a quota on a ZooKeeper node. + +<a name="Deleting+Quotas"></a> + +### Deleting Quotas + +You can use _delquota_ to delete quota on a ZooKeeper node. + + diff --git a/zookeeper-docs/src/main/resources/markdown/zookeeperStarted.md b/zookeeper-docs/src/main/resources/markdown/zookeeperStarted.md new file mode 100644 index 000000000..587b8e61f --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/zookeeperStarted.md @@ -0,0 +1,364 @@ +<!-- +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. +//--> + +# ZooKeeper Getting Started Guide + +* [Getting Started: Coordinating Distributed Applications with ZooKeeper](#getting-started-coordinating-distributed-applications-with-zooKeeper) + * [Pre-requisites](#sc_Prerequisites) + * [Download](#sc_Download) + * [Standalone Operation](#sc_InstallingSingleMode) + * [Managing ZooKeeper Storage](#sc_FileManagement) + * [Connecting to ZooKeeper](#sc_ConnectingToZooKeeper) + * [Programming to ZooKeeper](#sc_ProgrammingToZooKeeper) + * [Running Replicated ZooKeeper](#sc_RunningReplicatedZooKeeper) + * [Other Optimizations](#other-optimizations) + +<a name="getting-started-coordinating-distributed-applications-with-zooKeeper"></a> + +## Getting Started: Coordinating Distributed Applications with ZooKeeper + +This document contains information to get you started quickly with +ZooKeeper. It is aimed primarily at developers hoping to try it out, and +contains simple installation instructions for a single ZooKeeper server, a +few commands to verify that it is running, and a simple programming +example. Finally, as a convenience, there are a few sections regarding +more complicated installations, for example running replicated +deployments, and optimizing the transaction log. However for the complete +instructions for commercial deployments, please refer to the [ZooKeeper +Administrator's Guide](zookeeperAdmin.html). + +<a name="sc_Prerequisites"></a> + +### Pre-requisites + +See [System Requirements](zookeeperAdmin.html#sc_systemReq) in the Admin guide. + +<a name="sc_Download"></a> + +### Download + +To get a ZooKeeper distribution, download a recent +[stable](http://zookeeper.apache.org/releases.html) release from one of the Apache Download +Mirrors. + +<a name="sc_InstallingSingleMode"></a> + +### Standalone Operation + +Setting up a ZooKeeper server in standalone mode is +straightforward. The server is contained in a single JAR file, +so installation consists of creating a configuration. + +Once you've downloaded a stable ZooKeeper release unpack +it and cd to the root + +To start ZooKeeper you need a configuration file. Here is a sample, +create it in **conf/zoo.cfg**: + + + tickTime=2000 + dataDir=/var/lib/zookeeper + clientPort=2181 + + +This file can be called anything, but for the sake of this +discussion call +it **conf/zoo.cfg**. Change the +value of **dataDir** to specify an +existing (empty to start with) directory. Here are the meanings +for each of the fields: + +* ***tickTime*** : + the basic time unit in milliseconds used by ZooKeeper. It is + used to do heartbeats and the minimum session timeout will be + twice the tickTime. + +* ***dataDir*** : + the location to store the in-memory database snapshots and, + unless specified otherwise, the transaction log of updates to the + database. + +* ***clientPort*** : + the port to listen for client connections + +Now that you created the configuration file, you can start +ZooKeeper: + + + bin/zkServer.sh start + + +ZooKeeper logs messages using log4j -- more detail +available in the +[Logging](zookeeperProgrammers.html#Logging) +section of the Programmer's Guide. You will see log messages +coming to the console (default) and/or a log file depending on +the log4j configuration. + +The steps outlined here run ZooKeeper in standalone mode. There is +no replication, so if ZooKeeper process fails, the service will go down. +This is fine for most development situations, but to run ZooKeeper in +replicated mode, please see [Running Replicated +ZooKeeper](#sc_RunningReplicatedZooKeeper). + +<a name="sc_FileManagement"></a> + +### Managing ZooKeeper Storage + +For long running production systems ZooKeeper storage must +be managed externally (dataDir and logs). See the section on +[maintenance](zookeeperAdmin.html#sc_maintenance) for +more details. + +<a name="sc_ConnectingToZooKeeper"></a> + +### Connecting to ZooKeeper + + + $ bin/zkCli.sh -server 127.0.0.1:2181 + + +This lets you perform simple, file-like operations. + +Once you have connected, you should see something like: + + + Connecting to localhost:2181 + log4j:WARN No appenders could be found for logger (org.apache.zookeeper.ZooKeeper). + log4j:WARN Please initialize the log4j system properly. + Welcome to ZooKeeper! + JLine support is enabled + [zkshell: 0] + +From the shell, type `help` to get a listing of commands that can be executed from the client, as in: + + + [zkshell: 0] help + ZooKeeper host:port cmd args + get path [watch] + ls path [watch] + set path data [version] + delquota [-n|-b] path + quit + printwatches on|off + create path data acl + stat path [watch] + listquota path + history + setAcl path acl + getAcl path + sync path + redo cmdno + addauth scheme auth + delete path [version] + deleteall path + setquota -n|-b val path + + +From here, you can try a few simple commands to get a feel for this simple command line interface. First, start by issuing the list command, as +in `ls`, yielding: + + + [zkshell: 8] ls / + [zookeeper] + + +Next, create a new znode by running `create /zk_test my_data`. This creates a new znode and associates the string "my_data" with the node. +You should see: + + + [zkshell: 9] create /zk_test my_data + Created /zk_test + + +Issue another `ls /` command to see what the directory looks like: + + + [zkshell: 11] ls / + [zookeeper, zk_test] + + +Notice that the zk_test directory has now been created. + +Next, verify that the data was associated with the znode by running the `get` command, as in: + + + [zkshell: 12] get /zk_test + my_data + cZxid = 5 + ctime = Fri Jun 05 13:57:06 PDT 2009 + mZxid = 5 + mtime = Fri Jun 05 13:57:06 PDT 2009 + pZxid = 5 + cversion = 0 + dataVersion = 0 + aclVersion = 0 + ephemeralOwner = 0 + dataLength = 7 + numChildren = 0 + + +We can change the data associated with zk_test by issuing the `set` command, as in: + + + [zkshell: 14] set /zk_test junk + cZxid = 5 + ctime = Fri Jun 05 13:57:06 PDT 2009 + mZxid = 6 + mtime = Fri Jun 05 14:01:52 PDT 2009 + pZxid = 5 + cversion = 0 + dataVersion = 1 + aclVersion = 0 + ephemeralOwner = 0 + dataLength = 4 + numChildren = 0 + [zkshell: 15] get /zk_test + junk + cZxid = 5 + ctime = Fri Jun 05 13:57:06 PDT 2009 + mZxid = 6 + mtime = Fri Jun 05 14:01:52 PDT 2009 + pZxid = 5 + cversion = 0 + dataVersion = 1 + aclVersion = 0 + ephemeralOwner = 0 + dataLength = 4 + numChildren = 0 + + +(Notice we did a `get` after setting the data and it did, indeed, change. + +Finally, let's `delete` the node by issuing: + + + [zkshell: 16] delete /zk_test + [zkshell: 17] ls / + [zookeeper] + [zkshell: 18] + + +That's it for now. To explore more, continue with the rest of this document and see the [Programmer's Guide](zookeeperProgrammers.html). + +<a name="sc_ProgrammingToZooKeeper"></a> + +### Programming to ZooKeeper + +ZooKeeper has a Java bindings and C bindings. They are +functionally equivalent. The C bindings exist in two variants: single +threaded and multi-threaded. These differ only in how the messaging loop +is done. For more information, see the [Programming +Examples in the ZooKeeper Programmer's Guide](zookeeperProgrammers.html#ch_programStructureWithExample) for +sample code using of the different APIs. + +<a name="sc_RunningReplicatedZooKeeper"></a> + +### Running Replicated ZooKeeper + +Running ZooKeeper in standalone mode is convenient for evaluation, +some development, and testing. But in production, you should run +ZooKeeper in replicated mode. A replicated group of servers in the same +application is called a _quorum_, and in replicated +mode, all servers in the quorum have copies of the same configuration +file. + +######Note +>For replicated mode, a minimum of three servers are required, +and it is strongly recommended that you have an odd number of +servers. If you only have two servers, then you are in a +situation where if one of them fails, there are not enough +machines to form a majority quorum. Two servers is inherently +**less** stable than a single server, because there are two single +points of failure. + +The required +**conf/zoo.cfg** +file for replicated mode is similar to the one used in standalone +mode, but with a few differences. Here is an example: + + tickTime=2000 + dataDir=/var/lib/zookeeper + clientPort=2181 + initLimit=5 + syncLimit=2 + server.1=zoo1:2888:3888 + server.2=zoo2:2888:3888 + server.3=zoo3:2888:3888 + +The new entry, **initLimit** is +timeouts ZooKeeper uses to limit the length of time the ZooKeeper +servers in quorum have to connect to a leader. The entry **syncLimit** limits how far out of date a server can +be from a leader. + +With both of these timeouts, you specify the unit of time using +**tickTime**. In this example, the timeout +for initLimit is 5 ticks at 2000 milleseconds a tick, or 10 +seconds. + +The entries of the form _server.X_ list the +servers that make up the ZooKeeper service. When the server starts up, +it knows which server it is by looking for the file +_myid_ in the data directory. That file has the +contains the server number, in ASCII. + +Finally, note the two port numbers after each server +name: " 2888" and "3888". Peers use the former port to connect +to other peers. Such a connection is necessary so that peers +can communicate, for example, to agree upon the order of +updates. More specifically, a ZooKeeper server uses this port +to connect followers to the leader. When a new leader arises, a +follower opens a TCP connection to the leader using this +port. Because the default leader election also uses TCP, we +currently require another port for leader election. This is the +second port in the server entry. + +######Note +>If you want to test multiple servers on a single +machine, specify the servername +as _localhost_ with unique quorum & +leader election ports (i.e. 2888:3888, 2889:3889, 2890:3890 in +the example above) for each server.X in that server's config +file. Of course separate _dataDir_s and +distinct _clientPort_s are also necessary +(in the above replicated example, running on a +single _localhost_, you would still have +three config files). + +>Please be aware that setting up multiple servers on a single +machine will not create any redundancy. If something were to +happen which caused the machine to die, all of the zookeeper +servers would be offline. Full redundancy requires that each +server have its own machine. It must be a completely separate +physical server. Multiple virtual machines on the same physical +host are still vulnerable to the complete failure of that host. + +<a name="other-optimizations"></a> + +### Other Optimizations + +There are a couple of other configuration parameters that can +greatly increase performance: + +* To get low latencies on updates it is important to + have a dedicated transaction log directory. By default + transaction logs are put in the same directory as the data + snapshots and _myid_ file. The dataLogDir + parameters indicates a different directory to use for the + transaction logs. +* _[tbd: what is the other config param?]_ + + diff --git a/zookeeper-docs/src/main/resources/markdown/zookeeperTutorial.md b/zookeeper-docs/src/main/resources/markdown/zookeeperTutorial.md new file mode 100644 index 000000000..21fbcccfb --- /dev/null +++ b/zookeeper-docs/src/main/resources/markdown/zookeeperTutorial.md @@ -0,0 +1,666 @@ +<!-- +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. +//--> + +# Programming with ZooKeeper - A basic tutorial + +* [Introduction](#ch_Introduction) +* [Barriers](#sc_barriers) +* [Producer-Consumer Queues](#sc_producerConsumerQueues) +* [Complete example](#Complete+example) + * [Queue test](#Queue+test) + * [Barrier test](#Barrier+test) + * [Source Listing](#sc_sourceListing) + +<a name="ch_Introduction"></a> + +## Introduction + +In this tutorial, we show simple implementations of barriers and +producer-consumer queues using ZooKeeper. We call the respective classes Barrier and Queue. +These examples assume that you have at least one ZooKeeper server running. + +Both primitives use the following common excerpt of code: + + static ZooKeeper zk = null; + static Integer mutex; + + String root; + + SyncPrimitive(String address) { + if(zk == null){ + try { + System.out.println("Starting ZK:"); + zk = new ZooKeeper(address, 3000, this); + mutex = new Integer(-1); + System.out.println("Finished starting ZK: " + zk); + } catch (IOException e) { + System.out.println(e.toString()); + zk = null; + } + } + } + + synchronized public void process(WatchedEvent event) { + synchronized (mutex) { + mutex.notify(); + } + } + + + +Both classes extend SyncPrimitive. In this way, we execute steps that are +common to all primitives in the constructor of SyncPrimitive. To keep the examples +simple, we create a ZooKeeper object the first time we instantiate either a barrier +object or a queue object, and we declare a static variable that is a reference +to this object. The subsequent instances of Barrier and Queue check whether a +ZooKeeper object exists. Alternatively, we could have the application creating a +ZooKeeper object and passing it to the constructor of Barrier and Queue. + +We use the process() method to process notifications triggered due to watches. +In the following discussion, we present code that sets watches. A watch is internal +structure that enables ZooKeeper to notify a client of a change to a node. For example, +if a client is waiting for other clients to leave a barrier, then it can set a watch and +wait for modifications to a particular node, which can indicate that it is the end of the wait. +This point becomes clear once we go over the examples. + +<a name="sc_barriers"></a> + +## Barriers + +A barrier is a primitive that enables a group of processes to synchronize the +beginning and the end of a computation. The general idea of this implementation +is to have a barrier node that serves the purpose of being a parent for individual +process nodes. Suppose that we call the barrier node "/b1". Each process "p" then +creates a node "/b1/p". Once enough processes have created their corresponding +nodes, joined processes can start the computation. + +In this example, each process instantiates a Barrier object, and its constructor takes as parameters: + +* the address of a ZooKeeper server (e.g., "zoo1.foo.com:2181") +* the path of the barrier node on ZooKeeper (e.g., "/b1") +* the size of the group of processes + +The constructor of Barrier passes the address of the Zookeeper server to the +constructor of the parent class. The parent class creates a ZooKeeper instance if +one does not exist. The constructor of Barrier then creates a +barrier node on ZooKeeper, which is the parent node of all process nodes, and +we call root (**Note:** This is not the ZooKeeper root "/"). + + /** + * Barrier constructor + * + * @param address + * @param root + * @param size + */ + Barrier(String address, String root, int size) { + super(address); + this.root = root; + this.size = size; + // Create barrier node + if (zk != null) { + try { + Stat s = zk.exists(root, false); + if (s == null) { + zk.create(root, new byte[0], Ids.OPEN_ACL_UNSAFE, + CreateMode.PERSISTENT); + } + } catch (KeeperException e) { + System.out + .println("Keeper exception when instantiating queue: " + + e.toString()); + } catch (InterruptedException e) { + System.out.println("Interrupted exception"); + } + } + + // My node name + try { + name = new String(InetAddress.getLocalHost().getCanonicalHostName().toString()); + } catch (UnknownHostException e) { + System.out.println(e.toString()); + } + } + + +To enter the barrier, a process calls enter(). The process creates a node under +the root to represent it, using its host name to form the node name. It then wait +until enough processes have entered the barrier. A process does it by checking +the number of children the root node has with "getChildren()", and waiting for +notifications in the case it does not have enough. To receive a notification when +there is a change to the root node, a process has to set a watch, and does it +through the call to "getChildren()". In the code, we have that "getChildren()" +has two parameters. The first one states the node to read from, and the second is +a boolean flag that enables the process to set a watch. In the code the flag is true. + + /** + * Join barrier + * + * @return + * @throws KeeperException + * @throws InterruptedException + */ + + boolean enter() throws KeeperException, InterruptedException{ + zk.create(root + "/" + name, new byte[0], Ids.OPEN_ACL_UNSAFE, + CreateMode.EPHEMERAL_SEQUENTIAL); + while (true) { + synchronized (mutex) { + List<String> list = zk.getChildren(root, true); + + if (list.size() < size) { + mutex.wait(); + } else { + return true; + } + } + } + } + + +Note that enter() throws both KeeperException and InterruptedException, so it is +the responsibility of the application to catch and handle such exceptions. + +Once the computation is finished, a process calls leave() to leave the barrier. +First it deletes its corresponding node, and then it gets the children of the root +node. If there is at least one child, then it waits for a notification (obs: note +that the second parameter of the call to getChildren() is true, meaning that +ZooKeeper has to set a watch on the the root node). Upon reception of a notification, +it checks once more whether the root node has any children. + + /** + * Wait until all reach barrier + * + * @return + * @throws KeeperException + * @throws InterruptedException + */ + + boolean leave() throws KeeperException, InterruptedException { + zk.delete(root + "/" + name, 0); + while (true) { + synchronized (mutex) { + List<String> list = zk.getChildren(root, true); + if (list.size() > 0) { + mutex.wait(); + } else { + return true; + } + } + } + } + + +<a name="sc_producerConsumerQueues"></a> + +## Producer-Consumer Queues + +A producer-consumer queue is a distributed data structure that groups of processes +use to generate and consume items. Producer processes create new elements and add +them to the queue. Consumer processes remove elements from the list, and process them. +In this implementation, the elements are simple integers. The queue is represented +by a root node, and to add an element to the queue, a producer process creates a new node, +a child of the root node. + +The following excerpt of code corresponds to the constructor of the object. As +with Barrier objects, it first calls the constructor of the parent class, SyncPrimitive, +that creates a ZooKeeper object if one doesn't exist. It then verifies if the root +node of the queue exists, and creates if it doesn't. + + /** + * Constructor of producer-consumer queue + * + * @param address + * @param name + */ + Queue(String address, String name) { + super(address); + this.root = name; + // Create ZK node name + if (zk != null) { + try { + Stat s = zk.exists(root, false); + if (s == null) { + zk.create(root, new byte[0], Ids.OPEN_ACL_UNSAFE, + CreateMode.PERSISTENT); + } + } catch (KeeperException e) { + System.out + .println("Keeper exception when instantiating queue: " + + e.toString()); + } catch (InterruptedException e) { + System.out.println("Interrupted exception"); + } + } + } + + +A producer process calls "produce()" to add an element to the queue, and passes +an integer as an argument. To add an element to the queue, the method creates a +new node using "create()", and uses the SEQUENCE flag to instruct ZooKeeper to +append the value of the sequencer counter associated to the root node. In this way, +we impose a total order on the elements of the queue, thus guaranteeing that the +oldest element of the queue is the next one consumed. + + /** + * Add element to the queue. + * + * @param i + * @return + */ + + boolean produce(int i) throws KeeperException, InterruptedException{ + ByteBuffer b = ByteBuffer.allocate(4); + byte[] value; + + // Add child with value i + b.putInt(i); + value = b.array(); + zk.create(root + "/element", value, Ids.OPEN_ACL_UNSAFE, + CreateMode.PERSISTENT_SEQUENTIAL); + + return true; + } + + +To consume an element, a consumer process obtains the children of the root node, +reads the node with smallest counter value, and returns the element. Note that +if there is a conflict, then one of the two contending processes won't be able to +delete the node and the delete operation will throw an exception. + +A call to getChildren() returns the list of children in lexicographic order. +As lexicographic order does not necessary follow the numerical order of the counter +values, we need to decide which element is the smallest. To decide which one has +the smallest counter value, we traverse the list, and remove the prefix "element" +from each one. + + /** + * Remove first element from the queue. + * + * @return + * @throws KeeperException + * @throws InterruptedException + */ + int consume() throws KeeperException, InterruptedException{ + int retvalue = -1; + Stat stat = null; + + // Get the first element available + while (true) { + synchronized (mutex) { + List<String> list = zk.getChildren(root, true); + if (list.size() == 0) { + System.out.println("Going to wait"); + mutex.wait(); + } else { + Integer min = new Integer(list.get(0).substring(7)); + for(String s : list){ + Integer tempValue = new Integer(s.substring(7)); + //System.out.println("Temporary value: " + tempValue); + if(tempValue < min) min = tempValue; + } + System.out.println("Temporary value: " + root + "/element" + min); + byte[] b = zk.getData(root + "/element" + min, + false, stat); + zk.delete(root + "/element" + min, 0); + ByteBuffer buffer = ByteBuffer.wrap(b); + retvalue = buffer.getInt(); + + return retvalue; + } + } + } + } + } + + +<a name="Complete+example"></a> + +## Complete example + +In the following section you can find a complete command line application to demonstrate the above mentioned +recipes. Use the following command to run it. + + ZOOBINDIR="[path_to_distro]/bin" + . "$ZOOBINDIR"/zkEnv.sh + java SyncPrimitive [Test Type] [ZK server] [No of elements] [Client type] + +<a name="Queue+test"></a> + +### Queue test + +Start a producer to create 100 elements + + java SyncPrimitive qTest localhost 100 p + + +Start a consumer to consume 100 elements + + java SyncPrimitive qTest localhost 100 c + +<a name="Barrier+test"></a> + +### Barrier test + +Start a barrier with 2 participants (start as many times as many participants you'd like to enter) + + java SyncPrimitive bTest localhost 2 + +<a name="sc_sourceListing"></a> + +### Source Listing + +#### SyncPrimitive.Java + + import java.io.IOException; + import java.net.InetAddress; + import java.net.UnknownHostException; + import java.nio.ByteBuffer; + import java.util.List; + import java.util.Random; + + import org.apache.zookeeper.CreateMode; + import org.apache.zookeeper.KeeperException; + import org.apache.zookeeper.WatchedEvent; + import org.apache.zookeeper.Watcher; + import org.apache.zookeeper.ZooKeeper; + import org.apache.zookeeper.ZooDefs.Ids; + import org.apache.zookeeper.data.Stat; + + public class SyncPrimitive implements Watcher { + + static ZooKeeper zk = null; + static Integer mutex; + String root; + + SyncPrimitive(String address) { + if(zk == null){ + try { + System.out.println("Starting ZK:"); + zk = new ZooKeeper(address, 3000, this); + mutex = new Integer(-1); + System.out.println("Finished starting ZK: " + zk); + } catch (IOException e) { + System.out.println(e.toString()); + zk = null; + } + } + //else mutex = new Integer(-1); + } + + synchronized public void process(WatchedEvent event) { + synchronized (mutex) { + //System.out.println("Process: " + event.getType()); + mutex.notify(); + } + } + + /** + * Barrier + */ + static public class Barrier extends SyncPrimitive { + int size; + String name; + + /** + * Barrier constructor + * + * @param address + * @param root + * @param size + */ + Barrier(String address, String root, int size) { + super(address); + this.root = root; + this.size = size; + + // Create barrier node + if (zk != null) { + try { + Stat s = zk.exists(root, false); + if (s == null) { + zk.create(root, new byte[0], Ids.OPEN_ACL_UNSAFE, + CreateMode.PERSISTENT); + } + } catch (KeeperException e) { + System.out + .println("Keeper exception when instantiating queue: " + + e.toString()); + } catch (InterruptedException e) { + System.out.println("Interrupted exception"); + } + } + + // My node name + try { + name = new String(InetAddress.getLocalHost().getCanonicalHostName().toString()); + } catch (UnknownHostException e) { + System.out.println(e.toString()); + } + + } + + /** + * Join barrier + * + * @return + * @throws KeeperException + * @throws InterruptedException + */ + + boolean enter() throws KeeperException, InterruptedException{ + zk.create(root + "/" + name, new byte[0], Ids.OPEN_ACL_UNSAFE, + CreateMode.EPHEMERAL_SEQUENTIAL); + while (true) { + synchronized (mutex) { + List<String> list = zk.getChildren(root, true); + + if (list.size() < size) { + mutex.wait(); + } else { + return true; + } + } + } + } + + /** + * Wait until all reach barrier + * + * @return + * @throws KeeperException + * @throws InterruptedException + */ + boolean leave() throws KeeperException, InterruptedException{ + zk.delete(root + "/" + name, 0); + while (true) { + synchronized (mutex) { + List<String> list = zk.getChildren(root, true); + if (list.size() > 0) { + mutex.wait(); + } else { + return true; + } + } + } + } + } + + /** + * Producer-Consumer queue + */ + static public class Queue extends SyncPrimitive { + + /** + * Constructor of producer-consumer queue + * + * @param address + * @param name + */ + Queue(String address, String name) { + super(address); + this.root = name; + // Create ZK node name + if (zk != null) { + try { + Stat s = zk.exists(root, false); + if (s == null) { + zk.create(root, new byte[0], Ids.OPEN_ACL_UNSAFE, + CreateMode.PERSISTENT); + } + } catch (KeeperException e) { + System.out + .println("Keeper exception when instantiating queue: " + + e.toString()); + } catch (InterruptedException e) { + System.out.println("Interrupted exception"); + } + } + } + + /** + * Add element to the queue. + * + * @param i + * @return + */ + + boolean produce(int i) throws KeeperException, InterruptedException{ + ByteBuffer b = ByteBuffer.allocate(4); + byte[] value; + + // Add child with value i + b.putInt(i); + value = b.array(); + zk.create(root + "/element", value, Ids.OPEN_ACL_UNSAFE, + CreateMode.PERSISTENT_SEQUENTIAL); + + return true; + } + + /** + * Remove first element from the queue. + * + * @return + * @throws KeeperException + * @throws InterruptedException + */ + int consume() throws KeeperException, InterruptedException{ + int retvalue = -1; + Stat stat = null; + + // Get the first element available + while (true) { + synchronized (mutex) { + List<String> list = zk.getChildren(root, true); + if (list.size() == 0) { + System.out.println("Going to wait"); + mutex.wait(); + } else { + Integer min = new Integer(list.get(0).substring(7)); + String minNode = list.get(0); + for(String s : list){ + Integer tempValue = new Integer(s.substring(7)); + //System.out.println("Temporary value: " + tempValue); + if(tempValue < min) { + min = tempValue; + minNode = s; + } + } + System.out.println("Temporary value: " + root + "/" + minNode); + byte[] b = zk.getData(root + "/" + minNode, + false, stat); + zk.delete(root + "/" + minNode, 0); + ByteBuffer buffer = ByteBuffer.wrap(b); + retvalue = buffer.getInt(); + + return retvalue; + } + } + } + } + } + + public static void main(String args[]) { + if (args[0].equals("qTest")) + queueTest(args); + else + barrierTest(args); + } + + public static void queueTest(String args[]) { + Queue q = new Queue(args[1], "/app1"); + + System.out.println("Input: " + args[1]); + int i; + Integer max = new Integer(args[2]); + + if (args[3].equals("p")) { + System.out.println("Producer"); + for (i = 0; i < max; i++) + try{ + q.produce(10 + i); + } catch (KeeperException e){ + + } catch (InterruptedException e){ + + } + } else { + System.out.println("Consumer"); + + for (i = 0; i < max; i++) { + try{ + int r = q.consume(); + System.out.println("Item: " + r); + } catch (KeeperException e){ + i--; + } catch (InterruptedException e){ + } + } + } + } + + public static void barrierTest(String args[]) { + Barrier b = new Barrier(args[1], "/b1", new Integer(args[2])); + try{ + boolean flag = b.enter(); + System.out.println("Entered barrier: " + args[2]); + if(!flag) System.out.println("Error when entering the barrier"); + } catch (KeeperException e){ + } catch (InterruptedException e){ + } + + // Generate random integer + Random rand = new Random(); + int r = rand.nextInt(100); + // Loop for rand iterations + for (int i = 0; i < r; i++) { + try { + Thread.sleep(100); + } catch (InterruptedException e) { + } + } + try{ + b.leave(); + } catch (KeeperException e){ + + } catch (InterruptedException e){ + + } + System.out.println("Left barrier"); + } + } + |
