ZOOKEEPER-766. forrest recipes docs don't mention the lock/queue recipe implementations available in the release (phunt via mahadev)

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

CHANGES.txt

@@ -56,6 +56,9 @@ IMPROVEMENTS:
   ZOOKEEPER-724. Improve junit test integration - log harness information 
   (phunt via mahadev)
 
+  ZOOKEEPER-766. forrest recipes docs don't mention the lock/queue recipe
+  implementations available in the release (phunt via mahadev)
+
 NEW FEATURES:
   ZOOKEEPER-729. Java client API to recursively delete a subtree. (Kay
   Kay via henry)

docs/recipes.html

@@ -517,7 +517,18 @@ document.write("Last Published: " + document.lastModified);
     the list obtained from the first <strong>getChildren(
     )</strong> call. If there are are no children in the queue node, the
     reader waits for a watch notification to check the queue again.</p>
-<a name="N10138"></a><a name="sc_recipes_priorityQueues"></a>
+<div class="note">
+<div class="label">Note</div>
+<div class="content">
+      
+<p>There now exists a Queue implementation in ZooKeeper
+      recipes directory. This is distributed with the release --
+      src/recipes/queue directory of the release artifact.
+      </p>
+    
+</div>
+</div>
+<a name="N1013E"></a><a name="sc_recipes_priorityQueues"></a>
 <h4>Priority Queues</h4>
 <p>To implement a priority queue, you need only make two simple
       changes to the generic <a href="#sc_recipes_Queues">queue
@@ -527,12 +538,23 @@ document.write("Last Published: " + document.lastModified);
       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.</p>
-<a name="N10147"></a><a name="sc_recipes_Locks"></a>
+<a name="N1014D"></a><a name="sc_recipes_Locks"></a>
 <h3 class="h4">Locks</h3>
 <p>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.</p>
+<div class="note">
+<div class="label">Note</div>
+<div class="content">
+      
+<p>There now exists a Lock implementation in ZooKeeper
+      recipes directory. This is distributed with the release --
+      src/recipes/lock directory of the release artifact.
+      </p>
+    
+</div>
+</div>
 <p>Clients wishing to obtain a lock do the following:</p>
 <ol>
       
@@ -615,7 +637,7 @@ document.write("Last Published: " + document.lastModified);
 </li>
     
 </ul>
-<a name="N101B3"></a><a name="Shared+Locks"></a>
+<a name="N101BF"></a><a name="Shared+Locks"></a>
 <h4>Shared Locks</h4>
 <p>You can implement shared locks by with a few changes to the lock
       protocol:</p>
@@ -777,7 +799,7 @@ document.write("Last Published: " + document.lastModified);
       
 </div>
 </div>
-<a name="N1027F"></a><a name="sc_recoverableSharedLocks"></a>
+<a name="N1028B"></a><a name="sc_recoverableSharedLocks"></a>
 <h4>Recoverable Shared Locks</h4>
 <p>With minor modifications to the Shared Lock protocol, you make
       shared locks revocable by modifying the shared lock protocol:</p>
@@ -799,7 +821,7 @@ document.write("Last Published: " + document.lastModified);
       Laser Beams</em> 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.</p>
-<a name="N102AB"></a><a name="sc_recipes_twoPhasedCommit"></a>
+<a name="N102B7"></a><a name="sc_recipes_twoPhasedCommit"></a>
 <h3 class="h4">Two-phased Commit</h3>
 <p>A two-phase commit protocol is an algorithm that lets all clients in
     a distributed system agree either to commit a transaction or abort.</p>
@@ -831,7 +853,7 @@ document.write("Last Published: " + document.lastModified);
 <p>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.</p>
-<a name="N102C4"></a><a name="sc_leaderElection"></a>
+<a name="N102D0"></a><a name="sc_leaderElection"></a>
 <h3 class="h4">Leader Election</h3>
 <p>A simple way of doing leader election with ZooKeeper is to use the
     <strong>SEQUENCE|EPHEMERAL</strong> flags when creating

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

@@ -267,6 +267,13 @@
     )</emphasis> call. If there are are no children in the queue node, the
     reader waits for a watch notification to check the queue again.</para>
 
+    <note>
+      <para>There now exists a Queue implementation in ZooKeeper
+      recipes directory. This is distributed with the release --
+      src/recipes/queue directory of the release artifact.
+      </para>
+    </note>
+
     <section id="sc_recipes_priorityQueues">
       <title>Priority Queues</title>
 
@@ -289,6 +296,13 @@
     can be implemented using ZooKeeeper. As with priority queues, first define
     a lock node.</para>
 
+    <note>
+      <para>There now exists a Lock implementation in ZooKeeper
+      recipes directory. This is distributed with the release --
+      src/recipes/lock directory of the release artifact.
+      </para>
+    </note>
+
     <para>Clients wishing to obtain a lock do the following:</para>
 
     <orderedlist>