[MAPREDUCE-3184] Improve handling of fetch failures when a tasktracker is not responding on HTTP

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 0.20.205.0
• Fix Version/s: 1.0.1
• Component/s: jobtracker
• Target Version/s: 1.0.1
• Hadoop Flags: Reviewed

Release Note

The TaskTracker now has a thread which monitors for a known Jetty bug in which the selector thread starts spinning and map output can no longer be served. If the bug is detected, the TaskTracker will shut itself down. This feature can be disabled by setting mapred.tasktracker.jetty.cpu.check.enabled to false.

• Assignee: Todd Lipcon
• Reporter: Todd Lipcon
• Created: 14/Oct/11 00:01
• Updated: 11/Mar/14 17:34
• Resolved: 27/Oct/11 03:53

Description

On a 100 node cluster, we had an issue where one of the TaskTrackers was hit by MAPREDUCE-2386 and stopped responding to fetches. The behavior observed was the following:

• every reducer would try to fetch the same map task, and fail after ~13 minutes.
• At that point, all reducers would report this failed fetch to the JT for the same task, and the task would be re-run.
• Meanwhile, the reducers would move on to the next map task that ran on the TT, and hang for another 13 minutes.
  The job essentially made no progress for hours, as each map task that ran on the bad node was serially marked failed.

To combat this issue, we should introduce a second type of failed fetch notification, used when the TT does not respond at all (ie SocketTimeoutException, etc). These fetch failure notifications should count against the TT at large, rather than a single task. If more than half of the reducers report such an issue for a given TT, then all of the tasks from that TT should be re-run.

Issue Links

• is related to: MAPREDUCE-5588 TaskTrackers get killed by JettyBugMonitor because of incredibly high cpu usage