[jira] [Commented] (MAPREDUCE-5145) Change default max-attempts to be more than one for MR jobs as well
[ https://issues.apache.org/jira/browse/MAPREDUCE-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646501#comment-13646501 ] Hudson commented on MAPREDUCE-5145: --- Integrated in Hadoop-Yarn-trunk #200 (See [https://builds.apache.org/job/Hadoop-Yarn-trunk/200/]) MAPREDUCE-5145. Changed default max-attempts to be more than one for MR jobs inline with YARN. Contributed by Zhijie Shen. (Revision 1477889) Result = SUCCESS vinodkv : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477889 Files : * /hadoop/common/trunk/hadoop-mapreduce-project/CHANGES.txt * /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/test/java/org/apache/hadoop/mapreduce/v2/app/TestStagingCleanup.java * /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/MRJobConfig.java * /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/resources/mapred-default.xml > Change default max-attempts to be more than one for MR jobs as well > --- > > Key: MAPREDUCE-5145 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5145 > Project: Hadoop Map/Reduce > Issue Type: Bug >Reporter: Zhijie Shen >Assignee: Zhijie Shen > Fix For: 2.0.5-beta > > Attachments: MAPREDUCE-5145.1.patch > > > We need to give the AM of MR jobs the chance to retry. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5018) Support raw binary data with Hadoop streaming
[ https://issues.apache.org/jira/browse/MAPREDUCE-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646537#comment-13646537 ] PrateekM commented on MAPREDUCE-5018: - Hi Jay, If its not splittable, how are you going to gain the benefit of using hadoop's infrastructure? The infrastructure would be busy making network IOs to build up the binary file from replicated sources and passing it a single mapper? > Support raw binary data with Hadoop streaming > - > > Key: MAPREDUCE-5018 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5018 > Project: Hadoop Map/Reduce > Issue Type: New Feature > Components: contrib/streaming >Reporter: Jay Hacker >Priority: Minor > Attachments: justbytes.jar, MAPREDUCE-5018.patch, mapstream > > > People often have a need to run older programs over many files, and turn to > Hadoop streaming as a reliable, performant batch system. There are good > reasons for this: > 1. Hadoop is convenient: they may already be using it for mapreduce jobs, and > it is easy to spin up a cluster in the cloud. > 2. It is reliable: HDFS replicates data and the scheduler retries failed jobs. > 3. It is reasonably performant: it moves the code to the data, maintaining > locality, and scales with the number of nodes. > Historically Hadoop is of course oriented toward processing key/value pairs, > and so needs to interpret the data passing through it. Unfortunately, this > makes it difficult to use Hadoop streaming with programs that don't deal in > key/value pairs, or with binary data in general. For example, something as > simple as running md5sum to verify the integrity of files will not give the > correct result, due to Hadoop's interpretation of the data. > There have been several attempts at binary serialization schemes for Hadoop > streaming, such as TypedBytes (HADOOP-1722); however, these are still aimed > at efficiently encoding key/value pairs, and not passing data through > unmodified. Even the "RawBytes" serialization scheme adds length fields to > the data, rendering it not-so-raw. > I often have a need to run a Unix filter on files stored in HDFS; currently, > the only way I can do this on the raw data is to copy the data out and run > the filter on one machine, which is inconvenient, slow, and unreliable. It > would be very convenient to run the filter as a map-only job, allowing me to > build on existing (well-tested!) building blocks in the Unix tradition > instead of reimplementing them as mapreduce programs. > However, most existing tools don't know about file splits, and so want to > process whole files; and of course many expect raw binary input and output. > The solution is to run a map-only job with an InputFormat and OutputFormat > that just pass raw bytes and don't split. It turns out to be a little more > complicated with streaming; I have attached a patch with the simplest > solution I could come up with. I call the format "JustBytes" (as "RawBytes" > was already taken), and it should be usable with most recent versions of > Hadoop. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5145) Change default max-attempts to be more than one for MR jobs as well
[ https://issues.apache.org/jira/browse/MAPREDUCE-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646547#comment-13646547 ] Hudson commented on MAPREDUCE-5145: --- Integrated in Hadoop-Hdfs-trunk #1389 (See [https://builds.apache.org/job/Hadoop-Hdfs-trunk/1389/]) MAPREDUCE-5145. Changed default max-attempts to be more than one for MR jobs inline with YARN. Contributed by Zhijie Shen. (Revision 1477889) Result = FAILURE vinodkv : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477889 Files : * /hadoop/common/trunk/hadoop-mapreduce-project/CHANGES.txt * /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/test/java/org/apache/hadoop/mapreduce/v2/app/TestStagingCleanup.java * /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/MRJobConfig.java * /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/resources/mapred-default.xml > Change default max-attempts to be more than one for MR jobs as well > --- > > Key: MAPREDUCE-5145 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5145 > Project: Hadoop Map/Reduce > Issue Type: Bug >Reporter: Zhijie Shen >Assignee: Zhijie Shen > Fix For: 2.0.5-beta > > Attachments: MAPREDUCE-5145.1.patch > > > We need to give the AM of MR jobs the chance to retry. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5145) Change default max-attempts to be more than one for MR jobs as well
[ https://issues.apache.org/jira/browse/MAPREDUCE-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646600#comment-13646600 ] Hudson commented on MAPREDUCE-5145: --- Integrated in Hadoop-Mapreduce-trunk #1416 (See [https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1416/]) MAPREDUCE-5145. Changed default max-attempts to be more than one for MR jobs inline with YARN. Contributed by Zhijie Shen. (Revision 1477889) Result = FAILURE vinodkv : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1477889 Files : * /hadoop/common/trunk/hadoop-mapreduce-project/CHANGES.txt * /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/test/java/org/apache/hadoop/mapreduce/v2/app/TestStagingCleanup.java * /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/MRJobConfig.java * /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/resources/mapred-default.xml > Change default max-attempts to be more than one for MR jobs as well > --- > > Key: MAPREDUCE-5145 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5145 > Project: Hadoop Map/Reduce > Issue Type: Bug >Reporter: Zhijie Shen >Assignee: Zhijie Shen > Fix For: 2.0.5-beta > > Attachments: MAPREDUCE-5145.1.patch > > > We need to give the AM of MR jobs the chance to retry. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-50) NPE in heartbeat when the configured topology script doesn't exist
[
https://issues.apache.org/jira/browse/MAPREDUCE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646670#comment-13646670
]
Ivan Mitic commented on MAPREDUCE-50:
-
Hi Steve, Vinod,
I've run into the similar problem to this one. In my case, JobTracker started
failing jobs because the network topology resolution started failing for a
single node in the cluster:
{code}
2013-04-27 08:33:08,204 ERROR org.apache.hadoop.mapred.JobTracker: Job
initialization failed:
java.lang.NullPointerException
at
org.apache.hadoop.mapred.JobTracker.resolveAndAddToTopology(JobTracker.java:3205)
at
org.apache.hadoop.mapred.JobInProgress.createCache(JobInProgress.java:550)
at
org.apache.hadoop.mapred.JobInProgress.initTasks(JobInProgress.java:734)
at org.apache.hadoop.mapred.JobTracker.initJob(JobTracker.java:4214)
at
org.apache.hadoop.mapred.EagerTaskInitializationListener$InitJob.run(EagerTaskInitializationListener.java:79)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
{code}
What happens is that some input split blocks are located on the datanode with
the same IP/hostname as the TT. As a side effect this results in many of the
customer jobs to fail during initialization.
NN on the other hand has a fallback logic that defaults to /default-rack, and
this inconsistency actually makes this problem more severe :)
{code}
2013-04-27 04:36:47,185 ERROR
org.apache.hadoop.hdfs.server.namenode.FSNamesystem: The resolve call returned
null! Using /default-rack for host [100.64.34.3]
2013-04-27 04:36:47,185 INFO org.apache.hadoop.net.NetworkTopology: Adding a
new node: /default-rack/100.64.34.3:50010
{code}
In terms of the fix, my proposal would be to add the same fallback logic to the
JobTracker. In our case, we actually had a network topology script that worked
fine for a year or so, and now started failing for a single node for a reason
we cannot explain yet.
Let me know what you think. I'll take up this Jira if you don't mind.
> NPE in heartbeat when the configured topology script doesn't exist
> --
>
> Key: MAPREDUCE-50
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-50
> Project: Hadoop Map/Reduce
> Issue Type: Bug
>Affects Versions: 1.0.3
>Reporter: Vinod Kumar Vavilapalli
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (MAPREDUCE-50) NPE in heartbeat when the configured topology script doesn't exist
[ https://issues.apache.org/jira/browse/MAPREDUCE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Mitic reassigned MAPREDUCE-50: --- Assignee: Ivan Mitic > NPE in heartbeat when the configured topology script doesn't exist > -- > > Key: MAPREDUCE-50 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-50 > Project: Hadoop Map/Reduce > Issue Type: Bug >Affects Versions: 1.0.3 >Reporter: Vinod Kumar Vavilapalli >Assignee: Ivan Mitic > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MAPREDUCE-5202) Revert MAPREDUCE-4397 to avoid using incorrect config files
Owen O'Malley created MAPREDUCE-5202: Summary: Revert MAPREDUCE-4397 to avoid using incorrect config files Key: MAPREDUCE-5202 URL: https://issues.apache.org/jira/browse/MAPREDUCE-5202 Project: Hadoop Map/Reduce Issue Type: Bug Reporter: Owen O'Malley Assignee: Owen O'Malley MAPREDUCE-4397 added the capability to switch the location of the taskcontroller.cfg file, which weakens security. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5036) Default shuffle handler port should not be 8080
[ https://issues.apache.org/jira/browse/MAPREDUCE-5036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646696#comment-13646696 ] Tom White commented on MAPREDUCE-5036: -- +1 this looks fine to me. > Default shuffle handler port should not be 8080 > --- > > Key: MAPREDUCE-5036 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5036 > Project: Hadoop Map/Reduce > Issue Type: Improvement >Affects Versions: 2.0.3-alpha >Reporter: Sandy Ryza >Assignee: Sandy Ryza > Attachments: MAPREDUCE-5036.patch > > > The shuffle handler port (mapreduce.shuffle.port) defaults to 8080. This is > a pretty common port for web services, and is likely to cause unnecessary > port conflicts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5036) Default shuffle handler port should not be 8080
[ https://issues.apache.org/jira/browse/MAPREDUCE-5036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646699#comment-13646699 ] Arpit Gupta commented on MAPREDUCE-5036: we might want to pick a different default since oozie console also uses port 11000 > Default shuffle handler port should not be 8080 > --- > > Key: MAPREDUCE-5036 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5036 > Project: Hadoop Map/Reduce > Issue Type: Improvement >Affects Versions: 2.0.3-alpha >Reporter: Sandy Ryza >Assignee: Sandy Ryza > Attachments: MAPREDUCE-5036.patch > > > The shuffle handler port (mapreduce.shuffle.port) defaults to 8080. This is > a pretty common port for web services, and is likely to cause unnecessary > port conflicts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5036) Default shuffle handler port should not be 8080
[ https://issues.apache.org/jira/browse/MAPREDUCE-5036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646703#comment-13646703 ] Arpit Gupta commented on MAPREDUCE-5036: ignore my last comment the default is actually 8080 in oozie. > Default shuffle handler port should not be 8080 > --- > > Key: MAPREDUCE-5036 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5036 > Project: Hadoop Map/Reduce > Issue Type: Improvement >Affects Versions: 2.0.3-alpha >Reporter: Sandy Ryza >Assignee: Sandy Ryza > Attachments: MAPREDUCE-5036.patch > > > The shuffle handler port (mapreduce.shuffle.port) defaults to 8080. This is > a pretty common port for web services, and is likely to cause unnecessary > port conflicts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5202) Revert MAPREDUCE-4397 to avoid using incorrect config files
[ https://issues.apache.org/jira/browse/MAPREDUCE-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646753#comment-13646753 ] Vinod Kumar Vavilapalli commented on MAPREDUCE-5202: May be you should leave a comment on MAPREDUCE-4397.. > Revert MAPREDUCE-4397 to avoid using incorrect config files > --- > > Key: MAPREDUCE-5202 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5202 > Project: Hadoop Map/Reduce > Issue Type: Bug >Reporter: Owen O'Malley >Assignee: Owen O'Malley > > MAPREDUCE-4397 added the capability to switch the location of the > taskcontroller.cfg file, which weakens security. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MAPREDUCE-5202) Revert MAPREDUCE-4397 to avoid using incorrect config files
[ https://issues.apache.org/jira/browse/MAPREDUCE-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen O'Malley resolved MAPREDUCE-5202. -- Resolution: Fixed I reverted the previous patch on branch-1, branch-1.1, and branch-1.2. > Revert MAPREDUCE-4397 to avoid using incorrect config files > --- > > Key: MAPREDUCE-5202 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5202 > Project: Hadoop Map/Reduce > Issue Type: Bug >Reporter: Owen O'Malley >Assignee: Owen O'Malley > > MAPREDUCE-4397 added the capability to switch the location of the > taskcontroller.cfg file, which weakens security. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-4397) Introduce HADOOP_SECURITY_CONF_DIR for task-controller
[ https://issues.apache.org/jira/browse/MAPREDUCE-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646757#comment-13646757 ] Owen O'Malley commented on MAPREDUCE-4397: -- This patch weakens security, so it has been reverted by MAPREDUCE-5202. > Introduce HADOOP_SECURITY_CONF_DIR for task-controller > -- > > Key: MAPREDUCE-4397 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-4397 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: task-controller >Reporter: Luke Lu >Assignee: Yu Gao > Fix For: 1.1.2 > > Attachments: mapreduce-4397-branch-1.patch, test-patch.result > > > The linux task controller currently hard codes the directory in which to look > for its config file at compile time (via the HADOOP_CONF_DIR macro). Adding a > new environment variable to look for task-controller's conf dir (with strict > permission checks) would make installation much more flexible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-4397) Introduce HADOOP_SECURITY_CONF_DIR for task-controller
[ https://issues.apache.org/jira/browse/MAPREDUCE-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646767#comment-13646767 ] Vinod Kumar Vavilapalli commented on MAPREDUCE-4397: One problem is that this is shipped in 1.1.2, so mark MAPREDUCE-5202 as incompatible? I didn't look at MAPREDUCE-4219 unfortunately, but that sets the path to be relative to the binary for YARN, is that an issue too? I think the fundamental point of this and MAPREDUCE-4219 is easy relocation of the conf by the installers, do we have solution for that? > Introduce HADOOP_SECURITY_CONF_DIR for task-controller > -- > > Key: MAPREDUCE-4397 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-4397 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: task-controller >Reporter: Luke Lu >Assignee: Yu Gao > Fix For: 1.1.2 > > Attachments: mapreduce-4397-branch-1.patch, test-patch.result > > > The linux task controller currently hard codes the directory in which to look > for its config file at compile time (via the HADOOP_CONF_DIR macro). Adding a > new environment variable to look for task-controller's conf dir (with strict > permission checks) would make installation much more flexible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MAPREDUCE-5159) Aggregatewordcount and aggregatewordhist in hadoop-1 examples are not binary compatible with hadoop-2 mapred.lib.aggregate
[ https://issues.apache.org/jira/browse/MAPREDUCE-5159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhijie Shen updated MAPREDUCE-5159: --- Attachment: MAPREDUCE-5159.1.patch In the patch, I've added the functions that mapred.lib.aggregate.ValueAggregateJob has in hadoop 1.x, but it doesn't have in hadoop 2.x back to the class. I've done the binary compatibility tests locally. Both aggregatewordcount and aggregatewordhist work without exceptions. The issue described in MAPREDUCE-5160 is gone as well. > Aggregatewordcount and aggregatewordhist in hadoop-1 examples are not binary > compatible with hadoop-2 mapred.lib.aggregate > -- > > Key: MAPREDUCE-5159 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5159 > Project: Hadoop Map/Reduce > Issue Type: Sub-task >Reporter: Zhijie Shen >Assignee: Zhijie Shen > Attachments: MAPREDUCE-5159.1.patch > > > Both examples in hadoop-1 use > org.apache.hadoop.mapred.lib.aggregate.ValueAggregatorJob.createValueAggregatorJob(String > args[], Class caller), which no longer exists after upgrading to > hadoop-2. Therefore, they cannot not find the accordant function with their > function signature in the binary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MAPREDUCE-5159) Aggregatewordcount and aggregatewordhist in hadoop-1 examples are not binary compatible with hadoop-2 mapred.lib.aggregate
[ https://issues.apache.org/jira/browse/MAPREDUCE-5159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhijie Shen updated MAPREDUCE-5159: --- Status: Patch Available (was: Open) > Aggregatewordcount and aggregatewordhist in hadoop-1 examples are not binary > compatible with hadoop-2 mapred.lib.aggregate > -- > > Key: MAPREDUCE-5159 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5159 > Project: Hadoop Map/Reduce > Issue Type: Sub-task >Reporter: Zhijie Shen >Assignee: Zhijie Shen > Attachments: MAPREDUCE-5159.1.patch > > > Both examples in hadoop-1 use > org.apache.hadoop.mapred.lib.aggregate.ValueAggregatorJob.createValueAggregatorJob(String > args[], Class caller), which no longer exists after upgrading to > hadoop-2. Therefore, they cannot not find the accordant function with their > function signature in the binary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5160) Aggregatewordcount and aggregatewordhist in hadoop-1 examples can not find their inner classes when running on Yarn
[ https://issues.apache.org/jira/browse/MAPREDUCE-5160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646867#comment-13646867 ] Zhijie Shen commented on MAPREDUCE-5160: The issue seems to be gone given the patch of MAPREDUCE-5159 is applied. Will close this ticket when MAPREDUCE-5159 is fixed. > Aggregatewordcount and aggregatewordhist in hadoop-1 examples can not find > their inner classes when running on Yarn > --- > > Key: MAPREDUCE-5160 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5160 > Project: Hadoop Map/Reduce > Issue Type: Sub-task >Reporter: Zhijie Shen >Assignee: Zhijie Shen > > Aggregatewordcount and Aggregatewordhist of hadoop-1 cannot run on hadoop-2 > due to > org.apache.hadoop.mapred.lib.aggregate.ValueAggregatorJob.createValueAggregatorJob(String > args[], Class caller) is not available on hadoop-2 (see MAPREDUCE-5159). > After I changed Aggregatewordcount and Aggregatewordhist to use > createValueAggregatorJob(String args[], Class ValueAggregatorDescriptor>[] descriptors), which is available on hadoop-2, > the two examples could be accepted and run on Yarn. > However, the two examples still failed, because their inner classes, > WordCountPlugInClass and AggregateWordHistogramPlugin, cannot be found in > runtime, respectively. Both the plugin classes extend > org.apache.hadoop.mapred.lib.aggregate.ValueAggregatorBaseDescriptor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5159) Aggregatewordcount and aggregatewordhist in hadoop-1 examples are not binary compatible with hadoop-2 mapred.lib.aggregate
[
https://issues.apache.org/jira/browse/MAPREDUCE-5159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646877#comment-13646877
]
Hadoop QA commented on MAPREDUCE-5159:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12581401/MAPREDUCE-5159.1.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/3567//testReport/
Console output:
https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/3567//console
This message is automatically generated.
> Aggregatewordcount and aggregatewordhist in hadoop-1 examples are not binary
> compatible with hadoop-2 mapred.lib.aggregate
> --
>
> Key: MAPREDUCE-5159
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-5159
> Project: Hadoop Map/Reduce
> Issue Type: Sub-task
>Reporter: Zhijie Shen
>Assignee: Zhijie Shen
> Attachments: MAPREDUCE-5159.1.patch
>
>
> Both examples in hadoop-1 use
> org.apache.hadoop.mapred.lib.aggregate.ValueAggregatorJob.createValueAggregatorJob(String
> args[], Class caller), which no longer exists after upgrading to
> hadoop-2. Therefore, they cannot not find the accordant function with their
> function signature in the binary.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5202) Revert MAPREDUCE-4397 to avoid using incorrect config files
[ https://issues.apache.org/jira/browse/MAPREDUCE-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646884#comment-13646884 ] Ted Yu commented on MAPREDUCE-5202: --- Does this mean hadoop 1.1.3 would be released soon ? > Revert MAPREDUCE-4397 to avoid using incorrect config files > --- > > Key: MAPREDUCE-5202 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5202 > Project: Hadoop Map/Reduce > Issue Type: Bug >Reporter: Owen O'Malley >Assignee: Owen O'Malley > > MAPREDUCE-4397 added the capability to switch the location of the > taskcontroller.cfg file, which weakens security. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5198) Race condition in cleanup during task tracker renint with LinuxTaskController
[
https://issues.apache.org/jira/browse/MAPREDUCE-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13646955#comment-13646955
]
Karthik Kambatla commented on MAPREDUCE-5198:
-
Thanks Arpit.
> Race condition in cleanup during task tracker renint with LinuxTaskController
> -
>
> Key: MAPREDUCE-5198
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-5198
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: tasktracker
>Affects Versions: 1.2.0
>Reporter: Arpit Gupta
>Assignee: Arpit Gupta
> Fix For: 1.2.0
>
> Attachments: MAPREDUCE-5198.patch
>
>
> This was noticed when job tracker would be restarted while jobs were running
> and would ask the task tracker to reinitialize.
> Tasktracker would fail with an error like
> {code}
> 013-04-27 20:19:09,627 INFO org.apache.hadoop.mapred.TaskTracker: Good mapred
> local directories are:
> /grid/0/hdp/mapred/local,/grid/1/hdp/mapred/local,/grid/2/hdp/mapred/local,/grid/3/hdp/mapred/local,/grid/4/hdp/mapred/local,/grid/5/hdp/mapred/local
> 2013-04-27 20:19:09,628 INFO org.apache.hadoop.ipc.Server: IPC Server handler
> 3 on 42075 caught: java.nio.channels.ClosedChannelException
> at
> sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:133)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:324)
> at org.apache.hadoop.ipc.Server.channelWrite(Server.java:1717)
> at org.apache.hadoop.ipc.Server.access$2000(Server.java:98)
> at
> org.apache.hadoop.ipc.Server$Responder.processResponse(Server.java:744)
> at org.apache.hadoop.ipc.Server$Responder.doRespond(Server.java:808)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:1433)
> 2013-04-27 20:19:09,628 INFO org.apache.hadoop.ipc.Server: IPC Server handler
> 3 on 42075: exiting
> 2013-04-27 20:19:10,414 ERROR org.apache.hadoop.mapred.TaskTracker: Got fatal
> exception while reinitializing TaskTracker:
> org.apache.hadoop.util.Shell$ExitCodeException:
> at org.apache.hadoop.util.Shell.runCommand(Shell.java:255)
> at org.apache.hadoop.util.Shell.run(Shell.java:182)
> at
> org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:375)
> at
> org.apache.hadoop.mapred.LinuxTaskController.deleteAsUser(LinuxTaskController.java:281)
> at
> org.apache.hadoop.mapred.TaskTracker.deleteUserDirectories(TaskTracker.java:779)
> at org.apache.hadoop.mapred.TaskTracker.initialize(TaskTracker.java:816)
> at org.apache.hadoop.mapred.TaskTracker.run(TaskTracker.java:2704)
> at org.apache.hadoop.mapred.TaskTracker.main(TaskTracker.java:3934)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MAPREDUCE-5193) A few MR tests use block sizes which are smaller than the default minimum block size
[
https://issues.apache.org/jira/browse/MAPREDUCE-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Wang updated MAPREDUCE-5193:
---
Attachment: mapreduce-5193-1.patch
ATM told me it was okay to poach this, so here's a patch. It sets the min block
size to 0 in the /src/test/resource {{hdfs-site.xml}}, which is the same fix we
used for the HDFS tests.
I ran the failed tests from the MAPREDUCE-5156 patch successfully. Looking at
the daily build, most of the other components are fine. I also ran the tests in
the skipped components {{hs-plugin}} and examples successfully, so hopefully
it'll fix everything.
> A few MR tests use block sizes which are smaller than the default minimum
> block size
>
>
> Key: MAPREDUCE-5193
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-5193
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.5-beta
>Reporter: Aaron T. Myers
>Assignee: Aaron T. Myers
> Attachments: MAPREDUCE-5156.1.patch, mapreduce-5193-1.patch
>
>
> HDFS-4305 introduced a new configurable minimum block size of 1MB. A few MR
> tests deliberately set much smaller block sizes. This JIRA is to update those
> tests to fix these failing tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5193) A few MR tests use block sizes which are smaller than the default minimum block size
[
https://issues.apache.org/jira/browse/MAPREDUCE-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13647066#comment-13647066
]
Hadoop QA commented on MAPREDUCE-5193:
--
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12581431/mapreduce-5193-1.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/3568//testReport/
Console output:
https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/3568//console
This message is automatically generated.
> A few MR tests use block sizes which are smaller than the default minimum
> block size
>
>
> Key: MAPREDUCE-5193
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-5193
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.5-beta
>Reporter: Aaron T. Myers
>Assignee: Aaron T. Myers
> Attachments: MAPREDUCE-5156.1.patch, mapreduce-5193-1.patch
>
>
> HDFS-4305 introduced a new configurable minimum block size of 1MB. A few MR
> tests deliberately set much smaller block sizes. This JIRA is to update those
> tests to fix these failing tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5186) mapreduce.job.max.split.locations causes some splits created by CombineFileInputFormat to fail
[ https://issues.apache.org/jira/browse/MAPREDUCE-5186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13647117#comment-13647117 ] Sangjin Lee commented on MAPREDUCE-5186: I think CombineFileInputFormat needs to consider the max split locations value to change the way how the splits are formed. Having said that, however, trying to create splits to conform to the limit of 10 locations would have a major impact on how CombineFileInputFormat works. How critical is it to limit the split locations? Is the default value (10) reasonable? > mapreduce.job.max.split.locations causes some splits created by > CombineFileInputFormat to fail > -- > > Key: MAPREDUCE-5186 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5186 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: mrv1, mrv2 >Affects Versions: 2.0.4-alpha >Reporter: Sangjin Lee > > CombineFileInputFormat can easily create splits that can come from many > different locations (during the last pass of creating "global" splits). > However, we observe that this often runs afoul of the > mapreduce.job.max.split.locations check that's done by JobSplitWriter. > The default value for mapreduce.job.max.split.locations is 10, and with any > decent size cluster, CombineFileInputFormat creates splits that are well > above this limit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Moved] (MAPREDUCE-5203) Make AM of M/R Use NMClient
[ https://issues.apache.org/jira/browse/MAPREDUCE-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kumar Vavilapalli moved YARN-640 to MAPREDUCE-5203: - Key: MAPREDUCE-5203 (was: YARN-640) Project: Hadoop Map/Reduce (was: Hadoop YARN) > Make AM of M/R Use NMClient > --- > > Key: MAPREDUCE-5203 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5203 > Project: Hadoop Map/Reduce > Issue Type: Bug >Reporter: Zhijie Shen >Assignee: Zhijie Shen > > YARN-422 adds NMClient. AM of mapreduce should use it instead of using the > raw ContainerManager proxy directly. ContainerLauncherImpl needs to be > changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (MAPREDUCE-5193) A few MR tests use block sizes which are smaller than the default minimum block size
[ https://issues.apache.org/jira/browse/MAPREDUCE-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron T. Myers reassigned MAPREDUCE-5193: - Assignee: Andrew Wang (was: Aaron T. Myers) > A few MR tests use block sizes which are smaller than the default minimum > block size > > > Key: MAPREDUCE-5193 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5193 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: test >Affects Versions: 2.0.5-beta >Reporter: Aaron T. Myers >Assignee: Andrew Wang > Attachments: MAPREDUCE-5156.1.patch, mapreduce-5193-1.patch > > > HDFS-4305 introduced a new configurable minimum block size of 1MB. A few MR > tests deliberately set much smaller block sizes. This JIRA is to update those > tests to fix these failing tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5193) A few MR tests use block sizes which are smaller than the default minimum block size
[ https://issues.apache.org/jira/browse/MAPREDUCE-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13647186#comment-13647186 ] Aaron T. Myers commented on MAPREDUCE-5193: --- Thanks a lot for taking up this issue in my stead, Andrew. +1, the patch looks good to me. I'm going to commit this momentarily. > A few MR tests use block sizes which are smaller than the default minimum > block size > > > Key: MAPREDUCE-5193 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5193 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: test >Affects Versions: 2.0.5-beta >Reporter: Aaron T. Myers >Assignee: Andrew Wang > Attachments: MAPREDUCE-5156.1.patch, mapreduce-5193-1.patch > > > HDFS-4305 introduced a new configurable minimum block size of 1MB. A few MR > tests deliberately set much smaller block sizes. This JIRA is to update those > tests to fix these failing tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MAPREDUCE-5193) A few MR tests use block sizes which are smaller than the default minimum block size
[ https://issues.apache.org/jira/browse/MAPREDUCE-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron T. Myers updated MAPREDUCE-5193: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) I've just committed this to trunk and branch-2. Thanks a lot for the contribution, Andrew. > A few MR tests use block sizes which are smaller than the default minimum > block size > > > Key: MAPREDUCE-5193 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5193 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: test >Affects Versions: 2.0.5-beta >Reporter: Aaron T. Myers >Assignee: Andrew Wang > Attachments: MAPREDUCE-5156.1.patch, mapreduce-5193-1.patch > > > HDFS-4305 introduced a new configurable minimum block size of 1MB. A few MR > tests deliberately set much smaller block sizes. This JIRA is to update those > tests to fix these failing tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5193) A few MR tests use block sizes which are smaller than the default minimum block size
[ https://issues.apache.org/jira/browse/MAPREDUCE-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13647192#comment-13647192 ] Hudson commented on MAPREDUCE-5193: --- Integrated in Hadoop-trunk-Commit #3709 (See [https://builds.apache.org/job/Hadoop-trunk-Commit/3709/]) MAPREDUCE-5193. A few MR tests use block sizes which are smaller than the default minimum block size. Contributed by Andrew Wang. (Revision 1478250) Result = SUCCESS atm : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1478250 Files : * /hadoop/common/trunk/hadoop-mapreduce-project/CHANGES.txt * /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/test/resources/hdfs-site.xml > A few MR tests use block sizes which are smaller than the default minimum > block size > > > Key: MAPREDUCE-5193 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5193 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: test >Affects Versions: 2.0.5-beta >Reporter: Aaron T. Myers >Assignee: Andrew Wang > Attachments: MAPREDUCE-5156.1.patch, mapreduce-5193-1.patch > > > HDFS-4305 introduced a new configurable minimum block size of 1MB. A few MR > tests deliberately set much smaller block sizes. This JIRA is to update those > tests to fix these failing tests. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-4366) mapred metrics shows negative count of waiting maps and reduces
[ https://issues.apache.org/jira/browse/MAPREDUCE-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13647200#comment-13647200 ] Sandy Ryza commented on MAPREDUCE-4366: --- Oof this was a grueling one, but I think I've figured out the problem. At the start of a job, waiting tasks is incremented by the number of tasks, but then decremented each time an attempt launches, even if the attempt is speculative. Also, waiting tasks was incremented whenever a task failed, even if it was a speculative one that failed after a job had completed. This could cause a positive number of waiting tasks to stick around after the job completed. Uploading a patch that fully excludes speculative tasks from waiting tasks. > mapred metrics shows negative count of waiting maps and reduces > --- > > Key: MAPREDUCE-4366 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-4366 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: jobtracker >Affects Versions: 1.0.2 >Reporter: Thomas Graves >Assignee: Thomas Graves > > Negative waiting_maps and waiting_reduces count is observed in the mapred > metrics. MAPREDUCE-1238 partially fixed this but it appears there is still > issues as we are seeing it, but not as bad. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-4366) mapred metrics shows negative count of waiting maps and reduces
[ https://issues.apache.org/jira/browse/MAPREDUCE-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13647208#comment-13647208 ] Sandy Ryza commented on MAPREDUCE-4366: --- Verified this on a cluster with a job that triggers speculative execution and ran TestJobInProgress > mapred metrics shows negative count of waiting maps and reduces > --- > > Key: MAPREDUCE-4366 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-4366 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: jobtracker >Affects Versions: 1.0.2 >Reporter: Thomas Graves >Assignee: Thomas Graves > > Negative waiting_maps and waiting_reduces count is observed in the mapred > metrics. MAPREDUCE-1238 partially fixed this but it appears there is still > issues as we are seeing it, but not as bad. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MAPREDUCE-5204) Handle YarnRemoteException separately from IOException in MR api
Xuan Gong created MAPREDUCE-5204: Summary: Handle YarnRemoteException separately from IOException in MR api Key: MAPREDUCE-5204 URL: https://issues.apache.org/jira/browse/MAPREDUCE-5204 Project: Hadoop Map/Reduce Issue Type: Bug Reporter: Xuan Gong Assignee: Xuan Gong YarnRemoteException is not rooted as IOException, so in MR api, we need to handle them separately from IOException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MAPREDUCE-5204) Handle YarnRemoteException separately from IOException in MR api
[ https://issues.apache.org/jira/browse/MAPREDUCE-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xuan Gong updated MAPREDUCE-5204: - Attachment: MR-5204.1.patch > Handle YarnRemoteException separately from IOException in MR api > - > > Key: MAPREDUCE-5204 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5204 > Project: Hadoop Map/Reduce > Issue Type: Bug >Reporter: Xuan Gong >Assignee: Xuan Gong > Attachments: MR-5204.1.patch > > > YarnRemoteException is not rooted as IOException, so in MR api, we need to > handle them separately from IOException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
