Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.19.2, 0.20.0
    • Component/s: None
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      This happened while trying to change the priority of a job from the scheduler servlet.

      1. FairSchedulerDeadLock.txt
        37 kB
        Vinod Kumar Vavilapalli
      2. hadoop-5154-for-19.patch
        8 kB
        Hemanth Yamijala
      3. hadoop-5154-v0.patch
        2 kB
        Matei Zaharia
      4. hadoop-5154-v1.patch
        2 kB
        Matei Zaharia
      5. hadoop-5154-v2.patch
        3 kB
        Matei Zaharia
      6. hadoop-5154-v3.patch
        2 kB
        Matei Zaharia
      7. hadoop-5154-v4.patch
        7 kB
        Matei Zaharia
      8. hadoop-5154-v5.patch
        8 kB
        Hemanth Yamijala

        Activity

        Hide
        Vinod Kumar Vavilapalli added a comment -

        Attached thread dump.

        Summary:
        JT UI (jobtracker.jsp)

        • Waiting for lock on JobTracker object

        FairScheduler.assignTasks

        • Locked JobTracker object
        • Waiting for lock on FairScheduler object

        FairScheduler update thread

        • Locked FairScheduler object
        • Waiting for lock on PoolManager object

        FairScheduler.update (from scheduler UI)

        • Locked PoolManager object
        • Waiting for lock on FairScheduler object
        Show
        Vinod Kumar Vavilapalli added a comment - Attached thread dump. Summary: JT UI (jobtracker.jsp) Waiting for lock on JobTracker object FairScheduler.assignTasks Locked JobTracker object Waiting for lock on FairScheduler object FairScheduler update thread Locked FairScheduler object Waiting for lock on PoolManager object FairScheduler.update (from scheduler UI) Locked PoolManager object Waiting for lock on FairScheduler object
        Hide
        Vinod Kumar Vavilapalli added a comment -

        It's actually a 2-way deadlock. The JT UI and FairScheduler.assignTasks also got locked up while trying to obtain the lock on JT object.

        Show
        Vinod Kumar Vavilapalli added a comment - It's actually a 2-way deadlock. The JT UI and FairScheduler.assignTasks also got locked up while trying to obtain the lock on JT object.
        Hide
        Matei Zaharia added a comment -

        Thanks for finding this. Here's a patch that should fix it. It makes the FairSchedulerServlet lock the scheduler rather than the poolManager, which is how the rest of the code works (JobTracker's assignTasks, job listener stuff, and update thread). I haven't added any unit tests because I don't know how one would write a unit test for this, but it's a pretty simple patch.

        Show
        Matei Zaharia added a comment - Thanks for finding this. Here's a patch that should fix it. It makes the FairSchedulerServlet lock the scheduler rather than the poolManager, which is how the rest of the code works (JobTracker's assignTasks, job listener stuff, and update thread). I haven't added any unit tests because I don't know how one would write a unit test for this, but it's a pretty simple patch.
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12399685/hadoop-5154-v0.patch
        against trunk revision 742171.

        +1 @author. The patch does not contain any @author tags.

        -1 tests included. The patch doesn't appear to include any new or modified tests.
        Please justify why no tests are needed for this patch.

        +1 javadoc. The javadoc tool did not generate any warning messages.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 findbugs. The patch does not introduce any new Findbugs warnings.

        +1 Eclipse classpath. The patch retains Eclipse classpath integrity.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        -1 core tests. The patch failed core unit tests.

        -1 contrib tests. The patch failed contrib unit tests.

        Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3815/testReport/
        Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3815/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
        Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3815/artifact/trunk/build/test/checkstyle-errors.html
        Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3815/console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12399685/hadoop-5154-v0.patch against trunk revision 742171. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no tests are needed for this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 Eclipse classpath. The patch retains Eclipse classpath integrity. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. -1 contrib tests. The patch failed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3815/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3815/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3815/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3815/console This message is automatically generated.
        Hide
        Tom White added a comment -

        A couple of comments:

        • The PoolManager instance is not used in the setPriority part of the code, so can be removed.
        • Is there a reason that you're not calling update() on the scheduler within the synchronized block?
        Show
        Tom White added a comment - A couple of comments: The PoolManager instance is not used in the setPriority part of the code, so can be removed. Is there a reason that you're not calling update() on the scheduler within the synchronized block?
        Hide
        Matei Zaharia added a comment -

        Here's a new patch taking into account Tom's comments. Tom, the reason I had moved the update outside of the loop was because I thought I might want to acquire a lock on the JobTracker in update later, which could cause a deadlock with assignTasks (which locks the JT and then the scheduler), but now I think that this is not necessary so there's no reason to do it.

        Show
        Matei Zaharia added a comment - Here's a new patch taking into account Tom's comments. Tom, the reason I had moved the update outside of the loop was because I thought I might want to acquire a lock on the JobTracker in update later, which could cause a deadlock with assignTasks (which locks the JT and then the scheduler), but now I think that this is not necessary so there's no reason to do it.
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12400154/hadoop-5154-v1.patch
        against trunk revision 744406.

        +1 @author. The patch does not contain any @author tags.

        -1 tests included. The patch doesn't appear to include any new or modified tests.
        Please justify why no tests are needed for this patch.

        +1 javadoc. The javadoc tool did not generate any warning messages.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 findbugs. The patch does not introduce any new Findbugs warnings.

        +1 Eclipse classpath. The patch retains Eclipse classpath integrity.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        +1 core tests. The patch passed core unit tests.

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3855/testReport/
        Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3855/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
        Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3855/artifact/trunk/build/test/checkstyle-errors.html
        Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3855/console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12400154/hadoop-5154-v1.patch against trunk revision 744406. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no tests are needed for this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 Eclipse classpath. The patch retains Eclipse classpath integrity. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3855/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3855/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3855/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3855/console This message is automatically generated.
        Hide
        Matei Zaharia added a comment -

        Updated this patch a little so it will continue working after we commit HADOOP-4665. In 4665 (the preemption patch), the update() method in the FairScheduler needs a lock on the JobTracker to be able to call killTasks. However, since the JobTracker locks itself before locking the FairScheduler in its assignTasks logic, the lock order has to be JobTracker then FairScheduler (otherwise we'd get a deadlock). Therefore update() also locks first the JT and then the FairScheduler. I've modified this patch to ensure that the two pieces of code that call scheduler.update() do the same.

        Show
        Matei Zaharia added a comment - Updated this patch a little so it will continue working after we commit HADOOP-4665 . In 4665 (the preemption patch), the update() method in the FairScheduler needs a lock on the JobTracker to be able to call killTasks. However, since the JobTracker locks itself before locking the FairScheduler in its assignTasks logic, the lock order has to be JobTracker then FairScheduler (otherwise we'd get a deadlock). Therefore update() also locks first the JT and then the FairScheduler. I've modified this patch to ensure that the two pieces of code that call scheduler.update() do the same.
        Hide
        Matei Zaharia added a comment -

        Marking this for 0.18.4 and above since it's a deadlock. The patch should work on all fair scheduler versions.

        Show
        Matei Zaharia added a comment - Marking this for 0.18.4 and above since it's a deadlock. The patch should work on all fair scheduler versions.
        Hide
        Hemanth Yamijala added a comment -

        Matei, couple of comments:

        • I see you are now locking on the JobTracker and then the scheduler. The Fairscheduler web UI has refresh turned on by default. I am wondering if this can cause excessive lock contention with the JT, which could affect the JT code - like scheduling, etc. Maybe the refresh should be turned off by default, and enabled with a large refresh period on demand ?
        • Doesn't showJobs also need synchronization on the JobTracker and scheduler ?
        Show
        Hemanth Yamijala added a comment - Matei, couple of comments: I see you are now locking on the JobTracker and then the scheduler. The Fairscheduler web UI has refresh turned on by default. I am wondering if this can cause excessive lock contention with the JT, which could affect the JT code - like scheduling, etc. Maybe the refresh should be turned off by default, and enabled with a large refresh period on demand ? Doesn't showJobs also need synchronization on the JobTracker and scheduler ?
        Hide
        Matei Zaharia added a comment -

        Hi Hemanth,

        The reason showJobs doesn't lock the JobTracker is because it only looks at information in the fair scheduler. I have the lock around the JT for the other two methods because update() will require a lock on the JT once preemption is introduced in order to safely call killTask() on the JobTracker without causing a deadlock. If you just lock the JT independently or the FS independently, you can't cause a deadlock, but the problem is that the assignTasks method in the JobTracker locks first the JT and then the FS and thus causes a problem. However, maybe a better solution is to forget the lock on the JT in this patch, and change the way killTasks is called so that it's not called with a lock around the FairScheduler. This could be done by adding the tasks to kill into a queue and having a second thread kill them. Since the preemption patch, HADOOP-4665 is not going into release 0.20, I'm going to do that for this patch and fix up the patch for HADOOP-4665 to ensure that you only need a lock on the FS when calling update().

        I can also turn off the refresh by default. How is it handled on the JobTracker's web UI? For some reason I thought that refreshed.

        Show
        Matei Zaharia added a comment - Hi Hemanth, The reason showJobs doesn't lock the JobTracker is because it only looks at information in the fair scheduler. I have the lock around the JT for the other two methods because update() will require a lock on the JT once preemption is introduced in order to safely call killTask() on the JobTracker without causing a deadlock. If you just lock the JT independently or the FS independently, you can't cause a deadlock, but the problem is that the assignTasks method in the JobTracker locks first the JT and then the FS and thus causes a problem. However, maybe a better solution is to forget the lock on the JT in this patch, and change the way killTasks is called so that it's not called with a lock around the FairScheduler. This could be done by adding the tasks to kill into a queue and having a second thread kill them. Since the preemption patch, HADOOP-4665 is not going into release 0.20, I'm going to do that for this patch and fix up the patch for HADOOP-4665 to ensure that you only need a lock on the FS when calling update(). I can also turn off the refresh by default. How is it handled on the JobTracker's web UI? For some reason I thought that refreshed.
        Hide
        Matei Zaharia added a comment -

        Here's a patch with the changes in my previous comment.

        Show
        Matei Zaharia added a comment - Here's a patch with the changes in my previous comment.
        Hide
        Hemanth Yamijala added a comment -

        The reason showJobs doesn't lock the JobTracker is because it only looks at information in the fair scheduler.

        Matei, we access JobTracker.runningJobs(). This is accessing the jobs data structure in an unsynchronized manner. I see there's a JobTracker.getRunningJobs() which is providing synchronized access.

        I also meant that the scheduler instance is not being locked when accessing APIs in the scheduler. Is that not required as well ?

        How is it (refresh) handled on the JobTracker's web UI? For some reason I thought that refreshed.

        The JobTracker web page is not refreshed. The Job and task details web pages are, and I see that the Job details web page does not synchronize access to the jobs data structure as well. But that is still a bug. smile.

        Show
        Hemanth Yamijala added a comment - The reason showJobs doesn't lock the JobTracker is because it only looks at information in the fair scheduler. Matei, we access JobTracker.runningJobs() . This is accessing the jobs data structure in an unsynchronized manner. I see there's a JobTracker.getRunningJobs() which is providing synchronized access. I also meant that the scheduler instance is not being locked when accessing APIs in the scheduler. Is that not required as well ? How is it (refresh) handled on the JobTracker's web UI? For some reason I thought that refreshed. The JobTracker web page is not refreshed. The Job and task details web pages are, and I see that the Job details web page does not synchronize access to the jobs data structure as well. But that is still a bug. smile .
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12400443/hadoop-5154-v3.patch
        against trunk revision 745705.

        +1 @author. The patch does not contain any @author tags.

        -1 tests included. The patch doesn't appear to include any new or modified tests.
        Please justify why no tests are needed for this patch.

        +1 javadoc. The javadoc tool did not generate any warning messages.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 findbugs. The patch does not introduce any new Findbugs warnings.

        +1 Eclipse classpath. The patch retains Eclipse classpath integrity.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        -1 core tests. The patch failed core unit tests.

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3881/testReport/
        Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3881/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
        Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3881/artifact/trunk/build/test/checkstyle-errors.html
        Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3881/console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12400443/hadoop-5154-v3.patch against trunk revision 745705. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no tests are needed for this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 Eclipse classpath. The patch retains Eclipse classpath integrity. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3881/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3881/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3881/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3881/console This message is automatically generated.
        Hide
        Matei Zaharia added a comment -

        We can change runningJobs to getRunningJobs. Where do you see scheduler APIs being used without a lock though?

        Show
        Matei Zaharia added a comment - We can change runningJobs to getRunningJobs. Where do you see scheduler APIs being used without a lock though?
        Hide
        Hemanth Yamijala added a comment -

        We access scheduler.infos and scheduler.getPoolManager. Since infos is being modified in the scheduler code protected by the FairScheduler instance, this leads to inconsistent access. Likewise, access to pool manager is being synchronized on the scheduler instance in other methods. Basically, I am just looking at showJobs as being equivalent to showPools, and hence should have the same synchronization constructs.

        If you are modifying the patch to call getRunningJobs and introducing the synchronization around the scheduler, please make sure that there's no inversion in the order of locking between the scheduler and job tracker instances.

        Show
        Hemanth Yamijala added a comment - We access scheduler.infos and scheduler.getPoolManager. Since infos is being modified in the scheduler code protected by the FairScheduler instance, this leads to inconsistent access. Likewise, access to pool manager is being synchronized on the scheduler instance in other methods. Basically, I am just looking at showJobs as being equivalent to showPools, and hence should have the same synchronization constructs. If you are modifying the patch to call getRunningJobs and introducing the synchronization around the scheduler, please make sure that there's no inversion in the order of locking between the scheduler and job tracker instances.
        Hide
        Matei Zaharia added a comment -

        Updated patch to take into account your comments. I chose to call getRunningJobs before locking the scheduler (thus locking the JT alone, which is fine). It returns a new list so it should be okay to iterate through this list later.

        Show
        Matei Zaharia added a comment - Updated patch to take into account your comments. I chose to call getRunningJobs before locking the scheduler (thus locking the JT alone, which is fine). It returns a new list so it should be okay to iterate through this list later.
        Hide
        Matei Zaharia added a comment -

        Marking this for 19.2 instead of 18.4 because there's no fair scheduler in 18.4.

        Show
        Matei Zaharia added a comment - Marking this for 19.2 instead of 18.4 because there's no fair scheduler in 18.4.
        Hide
        Hemanth Yamijala added a comment -

        Matei, this looks good. Thanks for the changes.

        I made one small change to make access to the useFifo variable also synchronized, and uploaded a patch with this change alone. All other changes are from your patch. (I took this liberty because we are just trying to stabilize the 0.20 release soon, and would very much like this patch into the branch ASAP.) I verified that changes to the scheduling mode from the web ui is working with this change. If you are fine with these changes, I think it is good to go.

        Show
        Hemanth Yamijala added a comment - Matei, this looks good. Thanks for the changes. I made one small change to make access to the useFifo variable also synchronized, and uploaded a patch with this change alone. All other changes are from your patch. (I took this liberty because we are just trying to stabilize the 0.20 release soon, and would very much like this patch into the branch ASAP.) I verified that changes to the scheduling mode from the web ui is working with this change. If you are fine with these changes, I think it is good to go.
        Hide
        Hemanth Yamijala added a comment -

        Running through Hudson with the new patch

        Show
        Hemanth Yamijala added a comment - Running through Hudson with the new patch
        Hide
        Matei Zaharia added a comment -

        +1, looks good to me.

        Show
        Matei Zaharia added a comment - +1, looks good to me.
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12400844/hadoop-5154-v5.patch
        against trunk revision 747332.

        +1 @author. The patch does not contain any @author tags.

        -1 tests included. The patch doesn't appear to include any new or modified tests.
        Please justify why no tests are needed for this patch.

        +1 javadoc. The javadoc tool did not generate any warning messages.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 findbugs. The patch does not introduce any new Findbugs warnings.

        +1 Eclipse classpath. The patch retains Eclipse classpath integrity.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        -1 core tests. The patch failed core unit tests.

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3912/testReport/
        Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3912/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
        Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3912/artifact/trunk/build/test/checkstyle-errors.html
        Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3912/console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12400844/hadoop-5154-v5.patch against trunk revision 747332. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no tests are needed for this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 Eclipse classpath. The patch retains Eclipse classpath integrity. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3912/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3912/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3912/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3912/console This message is automatically generated.
        Hide
        Hemanth Yamijala added a comment -

        As explained above, there are no test cases in this patch, because it is a fix for a deadlock. The -1 on core tests is unrelated. I will commit this patch.

        Show
        Hemanth Yamijala added a comment - As explained above, there are no test cases in this patch, because it is a fix for a deadlock. The -1 on core tests is unrelated. I will commit this patch.
        Hide
        Hemanth Yamijala added a comment -

        This patch applies to the Hadoop 0.19 branch. The earlier one did not.

        I've run ant test-patch, test cases for fairscheduler, and also sanity tested the servlet on a 4 node cluster, changing priorities, switching scheduling modes etc.

        The patch was not different in content from the earlier one, only merged for the 0.19 branch. So, I am committing this.

        Show
        Hemanth Yamijala added a comment - This patch applies to the Hadoop 0.19 branch. The earlier one did not. I've run ant test-patch, test cases for fairscheduler, and also sanity tested the servlet on a 4 node cluster, changing priorities, switching scheduling modes etc. The patch was not different in content from the earlier one, only merged for the 0.19 branch. So, I am committing this.
        Hide
        Hemanth Yamijala added a comment -

        I just committed this to trunk and the 0.20 and 0.19 branches. Thanks, Matei !

        Show
        Hemanth Yamijala added a comment - I just committed this to trunk and the 0.20 and 0.19 branches. Thanks, Matei !
        Hide
        Hudson added a comment -

        Integrated in Hadoop-trunk #766 (See http://hudson.zones.apache.org/hudson/job/Hadoop-trunk/766/)
        . Fixes a deadlock in the fairshare scheduler. Contributed by Matei Zaharia.

        Show
        Hudson added a comment - Integrated in Hadoop-trunk #766 (See http://hudson.zones.apache.org/hudson/job/Hadoop-trunk/766/ ) . Fixes a deadlock in the fairshare scheduler. Contributed by Matei Zaharia.

          People

          • Assignee:
            Matei Zaharia
            Reporter:
            Vinod Kumar Vavilapalli
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development