HADOOP-4836. Correct typos in mapred related documentation. (Jorda Polo via szetszwo)

git-svn-id: https://svn.apache.org/repos/asf/hadoop/core/branches/branch-0.19@725855 13f79535-47bb-0310-9956-ffa450edef68

CHANGES.txt

@@ -27,6 +27,9 @@ Release 0.19.1 - Unreleased
     HADOOP-4731. Fix capacity scheduler to correctly remove job on completion 
     from waiting queue. (Amar Kamat via yhemanth)
 
+    HADOOP-4836. Correct typos in mapred related documentation.  (Jordà Polo
+    via szetszwo)
+
 Release 0.19.0 - 2008-11-18
 
   INCOMPATIBLE CHANGES

docs/capacity_scheduler.html

@@ -261,7 +261,7 @@ document.write("Last Published: " + document.lastModified);
 <li>
           Queues are guaranteed a fraction of the capacity of the grid (their 
  	      'guaranteed capacity') in the sense that a certain capacity of 
- 	      resources will be at their disposal. All jobs submitted to the a 
+ 	      resources will be at their disposal. All jobs submitted to a 
  	      queue will have access to the capacity guaranteed to the queue.
         </li>
         

docs/changes.html

@@ -716,7 +716,7 @@ via acmurthy)</li>
     </ol>
   </li>
   <li><a href="javascript:toggleList('release_0.18.3_-_unreleased_._bug_fixes_')">  BUG FIXES
-</a>&nbsp;&nbsp;&nbsp;(26)
+</a>&nbsp;&nbsp;&nbsp;(27)
     <ol id="release_0.18.3_-_unreleased_._bug_fixes_">
       <li><a href="http://issues.apache.org/jira/browse/HADOOP-4499">HADOOP-4499</a>. DFSClient should invoke checksumOk only once.<br />(Raghu Angadi)</li>
       <li><a href="http://issues.apache.org/jira/browse/HADOOP-4597">HADOOP-4597</a>. Calculate mis-replicated blocks when safe-mode is turned
@@ -759,6 +759,8 @@ map/reduce job failed to prompt temporary output.<br />(hairong)</li>
 receiver's tmp data directory.<br />(hairong)</li>
       <li><a href="http://issues.apache.org/jira/browse/HADOOP-4613">HADOOP-4613</a>. Fix block browsing on Web UI.<br />(Johan Oskarsson via shv)</li>
       <li><a href="http://issues.apache.org/jira/browse/HADOOP-4806">HADOOP-4806</a>. HDFS rename should not use src path as a regular expression.<br />(szetszwo)</li>
+      <li><a href="http://issues.apache.org/jira/browse/HADOOP-4795">HADOOP-4795</a>. Prevent lease monitor getting into an infinite loop when
+leases and the namespace tree does not match.<br />(szetszwo)</li>
     </ol>
   </li>
 </ul>

docs/mapred_tutorial.html

@@ -1854,7 +1854,7 @@ document.write("Last Published: " + document.lastModified);
         
 <li>
 <span class="codefrag">${mapred.local.dir}/taskTracker/jobcache/$jobid/$taskid</span>
-        : The task direcrory for each task attempt. Each task directory
+        : The task directory for each task attempt. Each task directory
         again has the following structure :
         <ul>
         

src/contrib/capacity-scheduler/src/java/org/apache/hadoop/mapred/CapacityTaskScheduler.java

@@ -78,7 +78,7 @@ class CapacityTaskScheduler extends TaskScheduler {
     // This time is equal to the time when the object was created, plus
     // the reclaim-time SLA for the queue.  
     public long whenToExpire;
-    // we also keep track of when to kill tasks, im millisecs. This is a 
+    // we also keep track of when to kill tasks, in millisecs. This is a 
     // fraction of 'whenToExpire', but we store it here so we don't 
     // recompute it every time. 
     public long whenToKill;
@@ -148,7 +148,7 @@ class CapacityTaskScheduler extends TaskScheduler {
      * created, it is placed in one queue. Once we kill tasks to recover 
      * resources for that object, it is placed in an expiry queue. we need
      * to do this to prevent creating spurious ResourceReclaim objects. We 
-     * keep a count of total resources that are being reclaimed. Thsi count 
+     * keep a count of total resources that are being reclaimed. This count 
      * is decremented when an object expires. 
      */
     
@@ -729,13 +729,13 @@ class CapacityTaskScheduler extends TaskScheduler {
        * update all our QSI objects.
        * This involves updating each qsi structure. This operation depends
        * on the number of running jobs in a queue, and some waiting jobs. If it
-       * becomes expensive, do it once every few hearbeats only.
+       * becomes expensive, do it once every few heartbeats only.
        */ 
       updateQSIObjects();
       LOG.debug("After updating QSI objects:");
       printQSIs();
       /*
-       * sort list of qeues first, as we want queues that need the most to
+       * sort list of queues first, as we want queues that need the most to
        * get first access. If this is expensive, sort every few heartbeats.
        * We're only sorting a collection of queues - there shouldn't be many.
        */

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

@@ -42,7 +42,7 @@
         <li>
           Queues are guaranteed a fraction of the capacity of the grid (their 
  	      'guaranteed capacity') in the sense that a certain capacity of 
- 	      resources will be at their disposal. All jobs submitted to the a 
+ 	      resources will be at their disposal. All jobs submitted to a 
  	      queue will have access to the capacity guaranteed to the queue.
         </li>
         <li>

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

@@ -1289,7 +1289,7 @@
         : The job.xml file, the generic job configuration, localized for 
         the job. </li>
         <li><code>${mapred.local.dir}/taskTracker/jobcache/$jobid/$taskid</code>
-        : The task direcrory for each task attempt. Each task directory
+        : The task directory for each task attempt. Each task directory
         again has the following structure :
         <ul>
         <li><code>${mapred.local.dir}/taskTracker/jobcache/$jobid/$taskid/job.xml</code>

src/mapred/org/apache/hadoop/mapred/jobcontrol/Job.java

@@ -33,12 +33,12 @@ import org.apache.hadoop.util.StringUtils;
 
 /** This class encapsulates a MapReduce job and its dependency. It monitors 
  *  the states of the depending jobs and updates the state of this job.
- *  A job stats in the WAITING state. If it does not have any deoending jobs, or
+ *  A job starts in the WAITING state. If it does not have any depending jobs, or
  *  all of the depending jobs are in SUCCESS state, then the job state will become
  *  READY. If any depending jobs fail, the job will fail too. 
  *  When in READY state, the job can be submitted to Hadoop for execution, with
  *  the state changing into RUNNING state. From RUNNING state, the job can get into 
- *  SUCCESS or FAILED state, depending the status of the jon execution.
+ *  SUCCESS or FAILED state, depending the status of the job execution.
  *  
  */