You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@tez.apache.org by "Jason Lowe (JIRA)" <ji...@apache.org> on 2016/11/02 21:20:58 UTC

[jira] [Updated] (TEZ-3508) TestTaskScheduler cleanup

     [ https://issues.apache.org/jira/browse/TEZ-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Lowe updated TEZ-3508:
----------------------------
    Attachment: TEZ-3508.001.patch

The motivation here is that I'm trying to develop a better fix for TEZ-Here's a patch that replaces the mocked AMRM client with one from the TestTaskSchedulerHelpers for all tests except testTaskSchedulerPreemption.  That test was the only one that fails when I do the replacement, and it's because I think it has a faulty premise.

testTaskSchedulerPreemption disables container reuse and creates 4 task requests, one at priority 2 and three and priority 6.  It then allocates four containers, two at priority 2 and two at priority 6.  After the allocation it verifies all 4 tasks were assigned.  The problem is when container reuse is disabled it will never allocate a task to a container that doesn't have the same priority, so it only allocates three containers when using a "real" AMRM client and the test fails.  I haven't had time to determine whether the entire test is invalid or already covered by the other preemption test, but the cleanups on all the other tests would be nice to get in.

> TestTaskScheduler cleanup
> -------------------------
>
>                 Key: TEZ-3508
>                 URL: https://issues.apache.org/jira/browse/TEZ-3508
>             Project: Apache Tez
>          Issue Type: Test
>            Reporter: Jason Lowe
>            Assignee: Jason Lowe
>         Attachments: TEZ-3508.001.patch
>
>
> TestTaskScheduler is very fragile, since it builds mocks of the AMRM client that is tied very specifically to the particulars of the way the YarnTaskScheduler is coded.  Any variance in that often leads to test failures because the mocks no longer accurately reflect what the real AMRM client does.
> It would be much simpler and more robust to leverage the AMRMClientForTest and AMRMAsyncClientForTest classes in TestTaskSchedulerHelpers rather than maintain fragile mocks attempting to emulate the behaviors of those classes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)