ZOOKEEPER-2110 Typo fixes in the ZK documentation. (Jeffrey Schroeder via rakeshr)

git-svn-id: https://svn.apache.org/repos/asf/zookeeper/trunk@1655082 13f79535-47bb-0310-9956-ffa450edef68

CHANGES.txt

@@ -47,6 +47,8 @@ IMPROVEMENTS:
   ZOOKEEPER-1963 Make JDK 7 the minimum requirement for Zookeeper 
   (Hongchao via fpj)
 
+  ZOOKEEPER-2110 Typo fixes in the ZK documentation. (Jeffrey Schroeder via rakeshr)
+
 Release 3.5.0 - 8/4/2014
 
 NEW FEATURES:

src/docs/src/documentation/content/xdocs/recipes.xml

@@ -614,7 +614,7 @@
     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 of failure of the current
+    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

src/docs/src/documentation/content/xdocs/releasenotes.xml

@@ -85,7 +85,7 @@ This meant that developers had to track watches they were interested in and rere
 In this release the client library tracks watches that a client has registered and reregisters the watches when a connection is made to a new server.
 Applications that still manually reregister interest should continue working properly as long as they are able to handle unsolicited watches.
 For example, an old application may register a watch for /foo and /goo, lose the connection, and reregister only /goo.
-As long as the application is able to recieve a notification for /foo, (probably ignoring it) the applications does not to be changes.
+As long as the application is able to recieve a notification for /foo, (probably ignoring it) it does not need to be changed.
 One caveat to the watch management: it is possible to miss an event for the creation and deletion of a znode if watching for creation and both the create and delete happens while the client is disconnected from ZooKeeper.
 </para>
 

src/docs/src/documentation/content/xdocs/zookeeperAdmin.xml

@@ -390,7 +390,7 @@ server.3=zoo3:2888:3888</programlisting>
       <title>Single Machine Requirements</title>
 
       <para>If ZooKeeper has to contend with other applications for
-        access to resourses like storage media, CPU, network, or
+        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

src/docs/src/documentation/content/xdocs/zookeeperInternals.xml

@@ -323,7 +323,7 @@ message when that proposal is committed.</para></listitem>
 
 <section id="sc_summary">
 <title>Summary</title>
-<para>So there you go. Why does it work? Specifically, why does is set of proposals 
+<para>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 

src/docs/src/documentation/content/xdocs/zookeeperObservers.xml

@@ -116,7 +116,7 @@
     <title>Example use cases</title>
     <para>
       Two example use cases for Observers are listed below. In fact, wherever
-      you wish to scale the numbe of clients of your ZooKeeper ensemble, or
+      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.

src/docs/src/documentation/content/xdocs/zookeeperOver.xml

@@ -136,7 +136,7 @@
     <section>
       <title>Nodes and ephemeral nodes</title>
 
-      <para>Unlike is standard file systems, each node in a ZooKeeper
+      <para>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,
@@ -166,9 +166,9 @@
       <title>Conditional updates and watches</title>
 
       <para>ZooKeeper supports the concept of <emphasis>watches</emphasis>.
-      Clients can set a watch on a znodes. 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. And if the
+      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 <emphasis>[tbd]</emphasis>.</para>
@@ -293,7 +293,7 @@
       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 components.</para>
+      of each of the components.</para>
 
       <figure id="fg_zkComponents">
         <title>ZooKeeper Components</title>

src/docs/src/documentation/content/xdocs/zookeeperTutorial.xml

@@ -196,7 +196,7 @@ a boolean flag that enables the process to set a watch. In the code the flag is
 </programlisting>
 <para>
 Note that enter() throws both KeeperException and InterruptedException, so it is 
-the reponsability of the application to catch and handle such exceptions.</para>
+the responsibility of the application to catch and handle such exceptions.</para>
 
 <para>
 Once the computation is finished, a process calls leave() to leave the barrier. 
@@ -204,7 +204,7 @@ First it deletes its corresponding node, and then it gets the children of the ro
 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 child.</para>
+it checks once more whether the root node has any children.</para>
 
 <programlisting>
         /**
@@ -233,7 +233,7 @@ it checks once more whether the root node has any child.</para>
 </section>
 <section id="sc_producerConsumerQueues"><title>Producer-Consumer Queues</title>
 <para>
-A producer-consumer queue is a distributed data estructure thata group of processes 
+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