Mailing-List: contact mapreduce-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mapreduce-issues@hadoop.apache.org
Date: Tue, 13 Mar 2012 13:11:39 +0000 (UTC)
From: "Harsh J (Created) (JIRA)" <jira@apache.org>
To: mapreduce-issues@hadoop.apache.org
Message-ID: 
 <583979537.7731.1331644299826.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Created] (MAPREDUCE-4001) Improve MAPREDUCE-3789's fix
 logic by looking at job's slot demands instead
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Improve MAPREDUCE-3789's fix logic by looking at job's slot demands instead
---------------------------------------------------------------------------

                 Key: MAPREDUCE-4001
                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-4001
             Project: Hadoop Map/Reduce
          Issue Type: Improvement
          Components: contrib/capacity-sched
    Affects Versions: 1.1.0
            Reporter: Harsh J
            Assignee: Harsh J
            Priority: Minor


In MAPREDUCE-3789, the fix had unfortunately only covered the first time assignment scenario, and the test had not really caught the mistake of using the condition of looking at available TT slots (instead of looking for how many slots a job's task demands).

We should change the condition of reservation in such a manner:

{code}
          if ((getPendingTasks(j) != 0 &&
               !hasSufficientReservedTaskTrackers(j)) &&
-                (taskTracker.getAvailableSlots(type) !=
+                !(j.getNumSlotsPerTask(type) >
                  getTTMaxSlotsForType(taskTrackerStatus, type))) {
{code}

I had not realized during the earlier ticket that j.getNumSlotsPerTask(type) did exist.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira