[ https://issues.apache.org/jira/browse/MAPREDUCE-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885596#action_12885596 ]
Iyappan Srinivasan commented on MAPREDUCE-1871: ----------------------------------------------- testTaskTrackerInfoAll I don't think it is a good idea to wait for arbitrary delay, replace this with polling logic, add functionality if required using aspects. + //Waiting for 20 seconds to make sure that all the completed tasks + //are reflected in their corresponding Tasktracker boxes. + Thread.sleep(20000); The same comment holds good in testTaskTrackerInfoKilled and other places where arbitrary delay is used. - Replaced with Tasktracker heartbeat variable used as delay.Changed in all places. countLoop++ is a vestige variable has to be removed. - removed. FailedMapperClass still exists as part of inner class, move it to testjar, or reuse FailedMapper already available in testjar. - Removed. reusing FailedMapper. + public static TTClient getTTClientIns(MRCluster cluster, TaskInfo taskInfo) + throws IOException { Apologies that my previous comment was not clear and you did move the method to TTClient like I mentioned but my intention was different. I do not like static method in TTClient, I would rather have a non static method in MRCluster, the general guideline for building block, add the helper method to a class from which it uses most of the member variables, if you have helper methods as static method in test cases highly unlikely anyone will reuse it, please refrain from adding static method, getTTClientIns should be moved to MRCluster as non-static method, having more static methods gives C flavor of coding, with less emphasis on object oriented means. - Moved to MRCluster. + private int getInfoFromAllClients(String timePeriod, String taskType) + throws Exception { + List<TTClient> ttClients = cluster.getTTClients(); + LOG.info("ttClients.size() :" + ttClients.size()); + + int totalTasksCount = 0; + int totalTasksRanForJob = 0; + for ( int i = 0; i< ttClients.size(); i++) { + TTClient ttClient = (TTClient)ttClients.get(i); + TaskTrackerStatus ttStatus = ttClient.getStatus(); + int totalTasks = remoteJTClient.getTaskTrackerLevelStatistics( + ttStatus, timePeriod, taskType); + totalTasksCount += totalTasks; + } + return totalTasksCount; + } The above code can be refactored to use the new method which gets all the information in single shot, no looping through task trackers required in client side, will reduce the number of rpc calls. - Refactored and made a part of TTClient, with testcase just calling it.. > Create automated test scenario for "Collect information about number of tasks > succeeded / total per time unit for a tasktracker" > -------------------------------------------------------------------------------------------------------------------------------- > > Key: MAPREDUCE-1871 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-1871 > Project: Hadoop Map/Reduce > Issue Type: Test > Components: test > Reporter: Iyappan Srinivasan > Assignee: Iyappan Srinivasan > Attachments: 1871-ydist-security-patch.txt, > 1871-ydist-security-patch.txt, 1871-ydist-security-patch.txt, > 1871-ydist-security-patch.txt, MAPREDUCE-1871.patch, MAPREDUCE-1871.patch > > > Create automated test scenario for "Collect information about number of tasks > succeeded / total per time unit for a tasktracker" > 1) Verification of all the above mentioned fields with the specified TTs. > Total no. of tasks and successful tasks should be equal to the corresponding > no. of tasks specified in TTs logs > 2) Fail a task on tasktracker. Node UI should update the status of tasks on > that TT accordingly. > 3) Kill a task on tasktracker. Node UI should update the status of tasks on > that TT accordingly > 4) Positive Run simultaneous jobs and check if all the fields are populated > with proper values of tasks. Node UI should have correct valiues for all the > fields mentioned above. > 5) Check the fields across one hour window Fields related to hour should be > updated after every hour > 6) Check the fields across one day window fields related to hour should be > updated after every day > 7) Restart a TT and bring it back. UI should retain the fields values. > 8) Positive Run a bunch of jobs with 0 maps and 0 reduces simultanously. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.