[ https://issues.apache.org/jira/browse/MAPREDUCE-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13963048#comment-13963048 ]
Eric Payne commented on MAPREDUCE-4937: --------------------------------------- When size of the meta info file exceeds the value specified by the mapreduce.jobtracker.split.metainfo.maxsize property set for a job, SplitMetaInfoReader.readSplitMetaInfo() throws an IOException. And, JobImpl$InitTransition.transition() is trying to catch an IOException. However, JobImpl$InitTransition.createSplits(), which is called in between JobImpl$InitTransition.transition() and SplitMetaInfoReader.readSplitMetaInfo(), catches the IOException, and instead throws a YarnRuntimeException. Since this runtime exception is not expected or caught by JobImpl anywhere, the proper diagnostic is not set. The result is that on the Job UI for the failed job, a cryptic message is displayed: AM Container for appattempt_1396371248625_0009_000003 exited with exitCode: 1 due to: Exception from container-launch: org.apache.hadoop.util.Shell$ExitCodeException: ... > MR AM handles an oversized split metainfo file poorly > ----------------------------------------------------- > > Key: MAPREDUCE-4937 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-4937 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: mr-am > Affects Versions: 2.0.2-alpha, 0.23.5 > Reporter: Jason Lowe > Assignee: Eric Payne > > When an job runs with a split metainfo file that's larger than it has been > configured to handle then it just crashes. This leaves the user with a > less-than-ideal debug session since there are no useful diagnostic messages > sent to the client for this failure. In addition it crashes before > registering/unregistering with the RM and crashes without generating history, > so the proxy URL is not very useful and there's no archived configuration to > check to see what setting the AM was using when it encountered the error. > The AM should handle this error case more gracefully and treat the failure as > it does any other failed job, with a proper unregistration from the RM and > with history. -- This message was sent by Atlassian JIRA (v6.2#6252)