ZOOKEEPER-1615. minor typos in ZooKeeper Programmer's Guide web page (Evan Zacks via phunt)

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

CHANGES.txt

@@ -476,6 +476,8 @@ IMPROVEMENTS:
 
   ZOOKEEPER-1619. Allow spaces in URL (Edward Ribeiro via phunt)
 
+  ZOOKEEPER-1615. minor typos in ZooKeeper Programmer's Guide web page
+  (Evan Zacks via phunt)
 
 Release 3.4.0 - 
 

docs/zookeeperProgrammers.html

@@ -481,7 +481,7 @@ document.write("Last Published: " + document.lastModified);
       <em>znode</em>. 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 allow ZooKeeper to validate the cache and to coordinate
+      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,
@@ -582,7 +582,7 @@ document.write("Last Published: " + document.lastModified);
 </p>
 
           
-<p>Every change to a a node will cause an increase to one of the
+<p>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
@@ -927,7 +927,7 @@ document.write("Last Published: " + document.lastModified);
 <strong>Added in 3.2.0 -- SessionMovedException</strong>. 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 be reestablished on a different server. The normal cause of this error is
+      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
@@ -936,7 +936,7 @@ document.write("Last Published: " + document.lastModified);
       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
-      it's connection/session indefinitely).</p>
+      its connection/session indefinitely).</p>
 <p> 
 <strong>Updating the list of servers</strong>.  We allow a client to 
       update the connection string by providing a new comma separated list of host:port pairs, 
@@ -1047,13 +1047,13 @@ document.write("Last Published: " + document.lastModified);
     
 </ul>
 <p>Watches are maintained locally at the ZooKeeper server to which the
-    client is connected. This allows watches to be light weight to set,
+    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 existance of a znode not yet created will
+    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.</p>
 <a name="sc_WatchGuarantees"></a>
 <h3 class="h4">What ZooKeeper Guarantees about Watches</h3>
@@ -1649,7 +1649,7 @@ authProvider.2=com.f.MyAuth2
               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
-              only guarantee is only present with successful return codes.
+              guarantee is only present with successful return codes.
               (This is called the <em>monotonicity condition</em> in Paxos.)</p>
             
 </li>
@@ -1672,7 +1672,7 @@ authProvider.2=com.f.MyAuth2
 </dt>
 <dd>
 <p>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.)
+          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.</p>
 </dd>
@@ -1975,7 +1975,7 @@ authProvider.2=com.f.MyAuth2
 <li>
             
 <p>Include ZooKeeper header: #include
-              &lt;zookeeper/zookeeper.h</p>
+              &lt;zookeeper/zookeeper.h&gt;</p>
           
 </li>
 

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

@@ -162,7 +162,7 @@
       <emphasis>znode</emphasis>. 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 allow ZooKeeper to validate the cache and to coordinate
+      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,
@@ -265,7 +265,7 @@
         <listitem>
           <para><emphasis role="bold">Version numbers</emphasis></para>
 
-          <para>Every change to a a node will cause an increase to one of the
+          <para>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
@@ -530,7 +530,7 @@
     <para> <emphasis role="bold">Added in 3.2.0 -- SessionMovedException</emphasis>. 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 be reestablished on a different server. The normal cause of this error is
+      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
@@ -539,7 +539,7 @@
       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
-      it's connection/session indefinitely).</para>
+      its connection/session indefinitely).</para>
 
     <para> <emphasis role="bold">Updating the list of servers</emphasis>.  We allow a client to 
       update the connection string by providing a new comma separated list of host:port pairs, 
@@ -639,13 +639,13 @@
     </itemizedlist>
 
     <para>Watches are maintained locally at the ZooKeeper server to which the
-    client is connected. This allows watches to be light weight to set,
+    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 existance of a znode not yet created will
+    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.</para>
 
     <section id="sc_WatchGuarantees">
@@ -1155,7 +1155,7 @@ authProvider.2=com.f.MyAuth2
               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
-              only guarantee is only present with successful return codes.
+              guarantee is only present with successful return codes.
               (This is called the <emphasis>monotonicity condition</emphasis> in Paxos.)</para>
             </listitem>
 
@@ -1173,7 +1173,7 @@ authProvider.2=com.f.MyAuth2
 
         <listitem>
           <para>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.)
+          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.</para>
         </listitem>
@@ -1437,7 +1437,7 @@ authProvider.2=com.f.MyAuth2
         <orderedlist>
           <listitem>
             <para>Include ZooKeeper header: #include
-              &lt;zookeeper/zookeeper.h</para>
+              &lt;zookeeper/zookeeper.h&gt;</para>
           </listitem>
 
           <listitem>