[jira] Resolved: (MAPREDUCE-2259) Hadoop Streaming JAR location might be updated
[ https://issues.apache.org/jira/browse/MAPREDUCE-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Todd Lipcon resolved MAPREDUCE-2259. Resolution: Duplicate This was addressed already by MAPREDUCE-1772 > Hadoop Streaming JAR location might be updated > -- > > Key: MAPREDUCE-2259 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2259 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: documentation > Environment: N/A >Reporter: minoru nishikubo >Priority: Trivial > Attachments: streaming.xml.patch > > > examples in docs/streaming.html: > $HADOOP_HOME/hadoop-streaming.jar > might be updated to > $HADOOP_HOME/contrib/streaming/hadoop-$HADOOP-VERSION-streaming.jar > for someone could not find the streaming archive. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MAPREDUCE-2255) correct example code in /api/org/apache/hadoop/util/Tool.html
[ https://issues.apache.org/jira/browse/MAPREDUCE-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Todd Lipcon resolved MAPREDUCE-2255. Resolution: Duplicate Yes, it looks like this was fixed in HADOOP-6504. Resolving as dup. > correct example code in /api/org/apache/hadoop/util/Tool.html > - > > Key: MAPREDUCE-2255 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2255 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: documentation >Affects Versions: 0.20.2 > Environment: None >Reporter: minoru nishikubo >Priority: Trivial > Attachments: Tool.html.patch, Tool.java.patch > > > a trivial mistake(?) in example code. But I wondered where Sort() was come > from for a few days. > < int res = ToolRunner.run(new Configuration(), new Sort(), args); > --- > > int res = ToolRunner.run(new Configuration(), new MyApp(), args); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2264) Job status exceeds 100% in some cases
[ https://issues.apache.org/jira/browse/MAPREDUCE-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981631#action_12981631 ] Ravi Gummadi commented on MAPREDUCE-2264: - BTW, Which version of hadoop are you using ? Does it already include the fixes/patches of HADOOP-5210 and HADOOP-5572 ? > Job status exceeds 100% in some cases > -- > > Key: MAPREDUCE-2264 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2264 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: jobtracker >Reporter: Adam Kramer > > I'm looking now at my jobtracker's list of running reduce tasks. One of them > is 120.05% complete, the other is 107.28% complete. > I understand that these numbers are estimates, but there is no case in which > an estimate of 100% for a non-complete task is better than an estimate of > 99.99%, nor is there any case in which an estimate greater than 100% is valid. > I suggest that whatever logic is computing these set 99.99% as a hard maximum. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2264) Job status exceeds 100% in some cases
[ https://issues.apache.org/jira/browse/MAPREDUCE-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981630#action_12981630 ] Ravi Gummadi commented on MAPREDUCE-2264: - Is this an issue at job level progress only ? Are task progress percentages for all tasks under 100% ? If a particular task's progress is shown as > 100%, please provide the info of which phase that task is in when you see progress > 100%. > Job status exceeds 100% in some cases > -- > > Key: MAPREDUCE-2264 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2264 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: jobtracker >Reporter: Adam Kramer > > I'm looking now at my jobtracker's list of running reduce tasks. One of them > is 120.05% complete, the other is 107.28% complete. > I understand that these numbers are estimates, but there is no case in which > an estimate of 100% for a non-complete task is better than an estimate of > 99.99%, nor is there any case in which an estimate greater than 100% is valid. > I suggest that whatever logic is computing these set 99.99% as a hard maximum. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2264) Job status exceeds 100% in some cases
[ https://issues.apache.org/jira/browse/MAPREDUCE-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981623#action_12981623 ] Liyin Liang commented on MAPREDUCE-2264: I think [HADOOP-5210|https://issues.apache.org/jira/browse/HADOOP-5210] has fixed this bug. > Job status exceeds 100% in some cases > -- > > Key: MAPREDUCE-2264 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2264 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: jobtracker >Reporter: Adam Kramer > > I'm looking now at my jobtracker's list of running reduce tasks. One of them > is 120.05% complete, the other is 107.28% complete. > I understand that these numbers are estimates, but there is no case in which > an estimate of 100% for a non-complete task is better than an estimate of > 99.99%, nor is there any case in which an estimate greater than 100% is valid. > I suggest that whatever logic is computing these set 99.99% as a hard maximum. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2255) correct example code in /api/org/apache/hadoop/util/Tool.html
[ https://issues.apache.org/jira/browse/MAPREDUCE-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981613#action_12981613 ] minoru nishikubo commented on MAPREDUCE-2255: - > Hi Minoru. First, thanks for helping to contribute! Would you mind uploading > a single patch file taken from the root of the SVN checkout (eg using svn > diff)? Please see the "Creating a patch" section in > http://wiki.apache.org/hadoop/HowToContribute if you need a pointer. Hello Todd! Thank you for your kindness!! I setup subversion and checked out the source from trunk, someone (perhaps you?) already fixed the source. > correct example code in /api/org/apache/hadoop/util/Tool.html > - > > Key: MAPREDUCE-2255 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2255 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: documentation >Affects Versions: 0.20.2 > Environment: None >Reporter: minoru nishikubo >Priority: Trivial > Attachments: Tool.html.patch, Tool.java.patch > > > a trivial mistake(?) in example code. But I wondered where Sort() was come > from for a few days. > < int res = ToolRunner.run(new Configuration(), new Sort(), args); > --- > > int res = ToolRunner.run(new Configuration(), new MyApp(), args); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MAPREDUCE-2264) Job status exceeds 100% in some cases
Job status exceeds 100% in some cases -- Key: MAPREDUCE-2264 URL: https://issues.apache.org/jira/browse/MAPREDUCE-2264 Project: Hadoop Map/Reduce Issue Type: Bug Components: jobtracker Reporter: Adam Kramer I'm looking now at my jobtracker's list of running reduce tasks. One of them is 120.05% complete, the other is 107.28% complete. I understand that these numbers are estimates, but there is no case in which an estimate of 100% for a non-complete task is better than an estimate of 99.99%, nor is there any case in which an estimate greater than 100% is valid. I suggest that whatever logic is computing these set 99.99% as a hard maximum. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2239) BlockPlacementPolicyRaid should call getBlockLocations only when necessary
[ https://issues.apache.org/jira/browse/MAPREDUCE-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Chen updated MAPREDUCE-2239: -- Status: Open (was: Patch Available) > BlockPlacementPolicyRaid should call getBlockLocations only when necessary > -- > > Key: MAPREDUCE-2239 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2239 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: contrib/raid >Affects Versions: 0.23.0 >Reporter: Scott Chen >Assignee: Scott Chen > Fix For: 0.23.0 > > Attachments: MAPREDUCE-2239-1.txt, MAPREDUCE-2239.txt > > > Currently BlockPlacementPolicyRaid calls getBlockLocations for every > chooseTarget(). > This puts pressure on NameNode. We should avoid calling if this file is not > raided or a parity file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2239) BlockPlacementPolicyRaid should call getBlockLocations only when necessary
[ https://issues.apache.org/jira/browse/MAPREDUCE-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Chen updated MAPREDUCE-2239: -- Status: Patch Available (was: Open) > BlockPlacementPolicyRaid should call getBlockLocations only when necessary > -- > > Key: MAPREDUCE-2239 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2239 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: contrib/raid >Affects Versions: 0.23.0 >Reporter: Scott Chen >Assignee: Scott Chen > Fix For: 0.23.0 > > Attachments: MAPREDUCE-2239-1.txt, MAPREDUCE-2239.txt > > > Currently BlockPlacementPolicyRaid calls getBlockLocations for every > chooseTarget(). > This puts pressure on NameNode. We should avoid calling if this file is not > raided or a parity file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2239) BlockPlacementPolicyRaid should call getBlockLocations only when necessary
[ https://issues.apache.org/jira/browse/MAPREDUCE-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981606#action_12981606 ] Scott Chen commented on MAPREDUCE-2239: --- Good catch. I have changed it to debug. > BlockPlacementPolicyRaid should call getBlockLocations only when necessary > -- > > Key: MAPREDUCE-2239 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2239 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: contrib/raid >Affects Versions: 0.23.0 >Reporter: Scott Chen >Assignee: Scott Chen > Fix For: 0.23.0 > > Attachments: MAPREDUCE-2239-1.txt, MAPREDUCE-2239.txt > > > Currently BlockPlacementPolicyRaid calls getBlockLocations for every > chooseTarget(). > This puts pressure on NameNode. We should avoid calling if this file is not > raided or a parity file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2239) BlockPlacementPolicyRaid should call getBlockLocations only when necessary
[ https://issues.apache.org/jira/browse/MAPREDUCE-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Chen updated MAPREDUCE-2239: -- Attachment: MAPREDUCE-2239-1.txt > BlockPlacementPolicyRaid should call getBlockLocations only when necessary > -- > > Key: MAPREDUCE-2239 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2239 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: contrib/raid >Affects Versions: 0.23.0 >Reporter: Scott Chen >Assignee: Scott Chen > Fix For: 0.23.0 > > Attachments: MAPREDUCE-2239-1.txt, MAPREDUCE-2239.txt > > > Currently BlockPlacementPolicyRaid calls getBlockLocations for every > chooseTarget(). > This puts pressure on NameNode. We should avoid calling if this file is not > raided or a parity file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2239) BlockPlacementPolicyRaid should call getBlockLocations only when necessary
[ https://issues.apache.org/jira/browse/MAPREDUCE-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981583#action_12981583 ] Ramkumar Vadali commented on MAPREDUCE-2239: Do you need to change FSNamesystem.LOG.debug -> FSNamesystem.LOG.info? > BlockPlacementPolicyRaid should call getBlockLocations only when necessary > -- > > Key: MAPREDUCE-2239 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2239 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: contrib/raid >Affects Versions: 0.23.0 >Reporter: Scott Chen >Assignee: Scott Chen > Fix For: 0.23.0 > > Attachments: MAPREDUCE-2239.txt > > > Currently BlockPlacementPolicyRaid calls getBlockLocations for every > chooseTarget(). > This puts pressure on NameNode. We should avoid calling if this file is not > raided or a parity file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2239) BlockPlacementPolicyRaid should call getBlockLocations only when necessary
[ https://issues.apache.org/jira/browse/MAPREDUCE-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Chen updated MAPREDUCE-2239: -- Status: Patch Available (was: Open) > BlockPlacementPolicyRaid should call getBlockLocations only when necessary > -- > > Key: MAPREDUCE-2239 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2239 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: contrib/raid >Affects Versions: 0.23.0 >Reporter: Scott Chen >Assignee: Scott Chen > Fix For: 0.23.0 > > Attachments: MAPREDUCE-2239.txt > > > Currently BlockPlacementPolicyRaid calls getBlockLocations for every > chooseTarget(). > This puts pressure on NameNode. We should avoid calling if this file is not > raided or a parity file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2239) BlockPlacementPolicyRaid should call getBlockLocations only when necessary
[ https://issues.apache.org/jira/browse/MAPREDUCE-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Chen updated MAPREDUCE-2239: -- Attachment: MAPREDUCE-2239.txt > BlockPlacementPolicyRaid should call getBlockLocations only when necessary > -- > > Key: MAPREDUCE-2239 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2239 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: contrib/raid >Affects Versions: 0.23.0 >Reporter: Scott Chen >Assignee: Scott Chen > Fix For: 0.23.0 > > Attachments: MAPREDUCE-2239.txt > > > Currently BlockPlacementPolicyRaid calls getBlockLocations for every > chooseTarget(). > This puts pressure on NameNode. We should avoid calling if this file is not > raided or a parity file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2256) FairScheduler fairshare preemption from multiple pools may preempt all tasks from one pool causing that pool to go below fairshare.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981566#action_12981566 ] Matei Zaharia commented on MAPREDUCE-2256: -- Agreed on putting it in 0.22. > FairScheduler fairshare preemption from multiple pools may preempt all tasks > from one pool causing that pool to go below fairshare. > --- > > Key: MAPREDUCE-2256 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2256 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: contrib/fair-share >Affects Versions: 0.21.1, 0.22.0 >Reporter: Priyo Mustafi >Assignee: Priyo Mustafi > Fix For: 0.22.0 > > Attachments: mapreduce-2256_0_22.txt > > > Scenarios: > You have a cluster with 600 map slots and 3 pools. Fairshare for each pool > is 200 to start with. Fairsharepreemption timeout is 5 mins. > 1) Pool1 schedules 300 map tasks first > 2) Pool2 then schedules another 300 map tasks > 3) Pool3 demands 300 map tasks but doesn't get any slot as all slots are > taken. > 4) After 5 mins pool3 should preempt 200 map-slots. Instead of peempting > 100 slots each from pool1 and pool2, the bug would cause it to preempt all > 200 slots from pool2 (last started) causing it to go below fairshare. This > is happening because the preemptTask method is not reducing the tasks left > from a pool while preempting the tasks. > The above scenario could be an extreme case but some amount of excess > preemption would happen because of this bug. > The patch I created was for 0.22.0 but the code fix should work on 0.21 as > well as looks like it has the same bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MAPREDUCE-2263) MapReduce side of HADOOP-6904
MapReduce side of HADOOP-6904 - Key: MAPREDUCE-2263 URL: https://issues.apache.org/jira/browse/MAPREDUCE-2263 Project: Hadoop Map/Reduce Issue Type: Improvement Reporter: Hairong Kuang Assignee: Hairong Kuang Fix For: 0.23.0 Make changes in Map/Reduce to incorporate HADOOP-6904. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2238) Undeletable build directories
[ https://issues.apache.org/jira/browse/MAPREDUCE-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Todd Lipcon updated MAPREDUCE-2238: --- Attachment: mapreduce-2238.txt I don't know that this is the issue, but the new setPermissions code is definitely prone to races. If two threads tried to setPermissions on the same directory at once, it could definitely end up with an incorrect result. This patch makes setPermissions threadsafe at least against other invocations of the same method. Worth a shot to apply this and see if the problems go away? > Undeletable build directories > -- > > Key: MAPREDUCE-2238 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2238 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: build, test >Affects Versions: 0.23.0 >Reporter: Eli Collins > Attachments: mapreduce-2238.txt > > > The MR hudson job is failing, looks like it's due to a test chmod'ing a build > directory so the checkout can't clean the build dir. > https://hudson.apache.org/hudson/job/Hadoop-Mapreduce-trunk/549/console > Building remotely on hadoop7 > hudson.util.IOException2: remote file operation failed: > /grid/0/hudson/hudson-slave/workspace/Hadoop-Mapreduce-trunk at > hudson.remoting.Channel@2545938c:hadoop7 > at hudson.FilePath.act(FilePath.java:749) > at hudson.FilePath.act(FilePath.java:735) > at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:589) > at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:537) > at hudson.model.AbstractProject.checkout(AbstractProject.java:1116) > at > hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:479) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:411) > at hudson.model.Run.run(Run.java:1324) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:139) > Caused by: java.io.IOException: Unable to delete > /grid/0/hudson/hudson-slave/workspace/Hadoop-Mapreduce-trunk/trunk/build/test/logs/userlogs/job_20101230131139886_0001/attempt_20101230131139886_0001_m_00_0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2238) Undeletable build directories
[ https://issues.apache.org/jira/browse/MAPREDUCE-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981520#action_12981520 ] Todd Lipcon commented on MAPREDUCE-2238: Saw this again on a build here. This time the undeletable userlog directory was created by TestMiniMRWithDFSWithDistinctUsers. > Undeletable build directories > -- > > Key: MAPREDUCE-2238 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2238 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: build, test >Affects Versions: 0.23.0 >Reporter: Eli Collins > > The MR hudson job is failing, looks like it's due to a test chmod'ing a build > directory so the checkout can't clean the build dir. > https://hudson.apache.org/hudson/job/Hadoop-Mapreduce-trunk/549/console > Building remotely on hadoop7 > hudson.util.IOException2: remote file operation failed: > /grid/0/hudson/hudson-slave/workspace/Hadoop-Mapreduce-trunk at > hudson.remoting.Channel@2545938c:hadoop7 > at hudson.FilePath.act(FilePath.java:749) > at hudson.FilePath.act(FilePath.java:735) > at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:589) > at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:537) > at hudson.model.AbstractProject.checkout(AbstractProject.java:1116) > at > hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:479) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:411) > at hudson.model.Run.run(Run.java:1324) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:139) > Caused by: java.io.IOException: Unable to delete > /grid/0/hudson/hudson-slave/workspace/Hadoop-Mapreduce-trunk/trunk/build/test/logs/userlogs/job_20101230131139886_0001/attempt_20101230131139886_0001_m_00_0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-1853) MultipleOutputs does not cache TaskAttemptContext
[
https://issues.apache.org/jira/browse/MAPREDUCE-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981505#action_12981505
]
David Rosenstrauch commented on MAPREDUCE-1853:
---
Is there any workaround to this issue for those of us who are still running
0.20?
I have a job that very much lends itself to using the MultipleOutputs
functionality, but I can't use it if a bug like this crushes the job's
performance.
Anyone have any alternate suggestions?
> MultipleOutputs does not cache TaskAttemptContext
> -
>
> Key: MAPREDUCE-1853
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-1853
> Project: Hadoop Map/Reduce
> Issue Type: Bug
>Affects Versions: 0.21.0, 0.22.0
> Environment: OSX 10.6
> java6
>Reporter: Torsten Curdt
>Priority: Critical
> Fix For: 0.21.0, 0.22.0
>
> Attachments: cache-task-attempts.diff
>
>
> In MultipleOutputs there is
> [code]
> private TaskAttemptContext getContext(String nameOutput) throws IOException {
> // The following trick leverages the instantiation of a record writer via
> // the job thus supporting arbitrary output formats.
> Job job = new Job(context.getConfiguration());
> job.setOutputFormatClass(getNamedOutputFormatClass(context, nameOutput));
> job.setOutputKeyClass(getNamedOutputKeyClass(context, nameOutput));
> job.setOutputValueClass(getNamedOutputValueClass(context, nameOutput));
> TaskAttemptContext taskContext =
> new TaskAttemptContextImpl(job.getConfiguration(),
> context.getTaskAttemptID());
> return taskContext;
> }
> [code]
> so for every reduce call it creates a new Job instance ...which creates a new
> LocalJobRunner.
> That does not sound like a good idea.
> You end up with a flood of "jvm.JvmMetrics: Cannot initialize JVM Metrics
> with processName=JobTracker, sessionId= - already initialized"
> This should probably also be added to 0.22.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-1387) Incorrect synchronization of {map|reduce|cleanup|setup} tasks in JobInProgress
[
https://issues.apache.org/jira/browse/MAPREDUCE-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981502#action_12981502
]
Priyo Mustafi commented on MAPREDUCE-1387:
--
Is this issue covered under
https://issues.apache.org/jira/browse/MAPREDUCE-2193 ?
> Incorrect synchronization of {map|reduce|cleanup|setup} tasks in JobInProgress
> --
>
> Key: MAPREDUCE-1387
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-1387
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: jobtracker
>Reporter: Amar Kamat
>
> JobInProgress.maps[], JobInProgress.reduces[], JobInProgress.setup[] and
> JobInProgress.cleanup[] are incorrectly synchronized resulting into findbugs
> warnings. Except the getter apis (i.e getMapTasks(), getReduceTasks(),
> getSetupTasks() and getCleanupTasks()), these structures are always accessed
> in synchronized methods.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2256) FairScheduler fairshare preemption from multiple pools may preempt all tasks from one pool causing that pool to go below fairshare.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Priyo Mustafi updated MAPREDUCE-2256: - Fix Version/s: 0.22.0 This is an important bug in the FairScheduler. I think this needs to be fixed in 0.22 > FairScheduler fairshare preemption from multiple pools may preempt all tasks > from one pool causing that pool to go below fairshare. > --- > > Key: MAPREDUCE-2256 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2256 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: contrib/fair-share >Affects Versions: 0.21.1, 0.22.0 >Reporter: Priyo Mustafi >Assignee: Priyo Mustafi > Fix For: 0.22.0 > > Attachments: mapreduce-2256_0_22.txt > > > Scenarios: > You have a cluster with 600 map slots and 3 pools. Fairshare for each pool > is 200 to start with. Fairsharepreemption timeout is 5 mins. > 1) Pool1 schedules 300 map tasks first > 2) Pool2 then schedules another 300 map tasks > 3) Pool3 demands 300 map tasks but doesn't get any slot as all slots are > taken. > 4) After 5 mins pool3 should preempt 200 map-slots. Instead of peempting > 100 slots each from pool1 and pool2, the bug would cause it to preempt all > 200 slots from pool2 (last started) causing it to go below fairshare. This > is happening because the preemptTask method is not reducing the tasks left > from a pool while preempting the tasks. > The above scenario could be an extreme case but some amount of excess > preemption would happen because of this bug. > The patch I created was for 0.22.0 but the code fix should work on 0.21 as > well as looks like it has the same bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2254) Allow setting of end-of-record delimiter for TextInputFormat
[ https://issues.apache.org/jira/browse/MAPREDUCE-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981447#action_12981447 ] Ahmed Radwan commented on MAPREDUCE-2254: - Hi Todd. I agree that the changes can directly go to the LineReader. My motive was keeping the LineReader mostly unchanged, in case it is used in other contexts. The LineReader breaks the input stream using new lines, which is totally fine and it exactly does what its name suggests. This is why I thought of encapsulating the changes within the RecordReader (where conceptually these changes are required). However, I see your point that it looks a little weird. I can move the changes to LineReader but then its name will not convey its functionality, and if we rename it, this can cause other problems. What do you think? > Allow setting of end-of-record delimiter for TextInputFormat > > > Key: MAPREDUCE-2254 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2254 > Project: Hadoop Map/Reduce > Issue Type: Improvement >Reporter: Ahmed Radwan > Attachments: MAPREDUCE-2245.patch > > > It will be useful to allow setting the end-of-record delimiter for > TextInputFormat. The current implementation hardcodes '\n', '\r' or '\r\n' as > the only possible record delimiters. This is a problem if users have embedded > newlines in their data fields (which is pretty common). This is also a > problem for other tools using this TextInputFormat (See for example: > https://issues.apache.org/jira/browse/PIG-836 and > https://issues.cloudera.org/browse/SQOOP-136). > I have wrote a patch to address this issue. This patch allows users to > specify any custom end-of-record delimiter using a new added configuration > property. For backward compatibility, if this new configuration property is > absent, then the same exact previous delimiters are used (i.e., '\n', '\r' or > '\r\n'). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2262) Capacity Scheduler unit tests fail with class not found
[ https://issues.apache.org/jira/browse/MAPREDUCE-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen O'Malley updated MAPREDUCE-2262: - Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this to the 0.20 branch. It looks like it was fixed as part of a big patch on trunk. > Capacity Scheduler unit tests fail with class not found > --- > > Key: MAPREDUCE-2262 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2262 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: contrib/capacity-sched >Reporter: Owen O'Malley >Assignee: Owen O'Malley > Fix For: 0.20.3 > > Attachments: mr-2262.patch > > > Currently the ivy.xml file for the capacity scheduler doesn't include the > commons-cli, leading to class not found exceptions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-1734) Un-deprecate the old MapReduce API in the 0.20 branch
[ https://issues.apache.org/jira/browse/MAPREDUCE-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen O'Malley updated MAPREDUCE-1734: - Fix Version/s: (was: 0.20.4) 0.20.3 > Un-deprecate the old MapReduce API in the 0.20 branch > - > > Key: MAPREDUCE-1734 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-1734 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: documentation >Reporter: Tom White >Assignee: Todd Lipcon >Priority: Blocker > Fix For: 0.20.3 > > Attachments: mapreduce-1734.txt > > > This issue is to un-deprecate the "old" MapReduce API (in o.a.h.mapred) in > the next 0.20 release, as discussed at > http://www.mail-archive.com/mapreduce-dev@hadoop.apache.org/msg01833.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2262) Capacity Scheduler unit tests fail with class not found
[ https://issues.apache.org/jira/browse/MAPREDUCE-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981432#action_12981432 ] Todd Lipcon commented on MAPREDUCE-2262: +1 > Capacity Scheduler unit tests fail with class not found > --- > > Key: MAPREDUCE-2262 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2262 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: contrib/capacity-sched >Reporter: Owen O'Malley >Assignee: Owen O'Malley > Fix For: 0.20.3 > > Attachments: mr-2262.patch > > > Currently the ivy.xml file for the capacity scheduler doesn't include the > commons-cli, leading to class not found exceptions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2254) Allow setting of end-of-record delimiter for TextInputFormat
[ https://issues.apache.org/jira/browse/MAPREDUCE-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981430#action_12981430 ] Todd Lipcon commented on MAPREDUCE-2254: Hi Ahmed. It looks like GenericLineReader essentially reimplements most of LineReader by overriding the readLine method. It seems strange to me to extend a class only to reimplement the majority of it. Could this patch be done by just modifying LineReader itself to be more generic, perhaps keeping the CRLF implementation as a private method for "fast path"? > Allow setting of end-of-record delimiter for TextInputFormat > > > Key: MAPREDUCE-2254 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2254 > Project: Hadoop Map/Reduce > Issue Type: Improvement >Reporter: Ahmed Radwan > Attachments: MAPREDUCE-2245.patch > > > It will be useful to allow setting the end-of-record delimiter for > TextInputFormat. The current implementation hardcodes '\n', '\r' or '\r\n' as > the only possible record delimiters. This is a problem if users have embedded > newlines in their data fields (which is pretty common). This is also a > problem for other tools using this TextInputFormat (See for example: > https://issues.apache.org/jira/browse/PIG-836 and > https://issues.cloudera.org/browse/SQOOP-136). > I have wrote a patch to address this issue. This patch allows users to > specify any custom end-of-record delimiter using a new added configuration > property. For backward compatibility, if this new configuration property is > absent, then the same exact previous delimiters are used (i.e., '\n', '\r' or > '\r\n'). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2262) Capacity Scheduler unit tests fail with class not found
[ https://issues.apache.org/jira/browse/MAPREDUCE-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen O'Malley updated MAPREDUCE-2262: - Status: Patch Available (was: Open) Adds the required dependency. > Capacity Scheduler unit tests fail with class not found > --- > > Key: MAPREDUCE-2262 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2262 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: contrib/capacity-sched >Reporter: Owen O'Malley >Assignee: Owen O'Malley > Fix For: 0.20.3 > > Attachments: mr-2262.patch > > > Currently the ivy.xml file for the capacity scheduler doesn't include the > commons-cli, leading to class not found exceptions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2262) Capacity Scheduler unit tests fail with class not found
[ https://issues.apache.org/jira/browse/MAPREDUCE-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen O'Malley updated MAPREDUCE-2262: - Attachment: mr-2262.patch > Capacity Scheduler unit tests fail with class not found > --- > > Key: MAPREDUCE-2262 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2262 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: contrib/capacity-sched >Reporter: Owen O'Malley >Assignee: Owen O'Malley > Fix For: 0.20.3 > > Attachments: mr-2262.patch > > > Currently the ivy.xml file for the capacity scheduler doesn't include the > commons-cli, leading to class not found exceptions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MAPREDUCE-2262) Capacity Scheduler unit tests fail with class not found
Capacity Scheduler unit tests fail with class not found --- Key: MAPREDUCE-2262 URL: https://issues.apache.org/jira/browse/MAPREDUCE-2262 Project: Hadoop Map/Reduce Issue Type: Bug Components: contrib/capacity-sched Reporter: Owen O'Malley Assignee: Owen O'Malley Fix For: 0.20.3 Currently the ivy.xml file for the capacity scheduler doesn't include the commons-cli, leading to class not found exceptions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2254) Allow setting of end-of-record delimiter for TextInputFormat
[ https://issues.apache.org/jira/browse/MAPREDUCE-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981424#action_12981424 ] Ahmed Radwan commented on MAPREDUCE-2254: - See INFRA-3357 for the problem of uploading git diff files to the review board. > Allow setting of end-of-record delimiter for TextInputFormat > > > Key: MAPREDUCE-2254 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2254 > Project: Hadoop Map/Reduce > Issue Type: Improvement >Reporter: Ahmed Radwan > Attachments: MAPREDUCE-2245.patch > > > It will be useful to allow setting the end-of-record delimiter for > TextInputFormat. The current implementation hardcodes '\n', '\r' or '\r\n' as > the only possible record delimiters. This is a problem if users have embedded > newlines in their data fields (which is pretty common). This is also a > problem for other tools using this TextInputFormat (See for example: > https://issues.apache.org/jira/browse/PIG-836 and > https://issues.cloudera.org/browse/SQOOP-136). > I have wrote a patch to address this issue. This patch allows users to > specify any custom end-of-record delimiter using a new added configuration > property. For backward compatibility, if this new configuration property is > absent, then the same exact previous delimiters are used (i.e., '\n', '\r' or > '\r\n'). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-1938) Ability for having user's classes take precedence over the system classes for tasks' classpath
[
https://issues.apache.org/jira/browse/MAPREDUCE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981413#action_12981413
]
Scott Carey commented on MAPREDUCE-1938:
{quote}
Users get in trouble without making conflicts in a deliberate way, they get
into those conflicts because of the lack of isolation of the current model
(refer to second paragraph of answer to Mahadev).
Having the use in control as the default is, IMO, the wrong way to go, all the
testing you've done on a release becomes meaningless as the users classpath
will override any library used by the cluster by default.
My take is that we should fix this via classloader isolation from the get go.
{quote}
I agree and disagree. If someone volunteered and fixed the whole situation
with classloader and/or shade and/or OSGi then great, this would not be needed.
However, at this point I'd rather be given a crude tool with varioius risks
than no tool at all. No cluster since 0.18 has worked for me without classpath
collisions requiring manual replacement of libraries.
So all that precious testing on the release you mention is useless to me since
such a cluster can't run my jobs!
{quote}
Too late for 0.22. Moving Fix Version from 0.22 to 0.23.
{quote}
Considering this is in the Y! disro (and perhaps CDH3 ?) is there actually any
veto for getting this in 0.22?Its simplistic and does provide the user with
a gun to shoot themselves in the foot, but the user interested in this already
has a different gun, thats just harder to use and affects all tasks in the
cluster instead of selected ones.
> Ability for having user's classes take precedence over the system classes for
> tasks' classpath
> --
>
> Key: MAPREDUCE-1938
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-1938
> Project: Hadoop Map/Reduce
> Issue Type: New Feature
> Components: job submission, task, tasktracker
>Reporter: Devaraj Das
>Assignee: Krishna Ramachandran
>Priority: Blocker
> Fix For: 0.23.0
>
> Attachments: mapred-1938-1, mapred-1938-2.patch, mapred-1938-3.patch,
> mr-1938-bp20.1.patch, mr-1938-bp20.patch
>
>
> It would be nice to have the ability in MapReduce to allow users to specify
> for their jobs alternate implementations of classes that are already defined
> in the MapReduce libraries. For example, an alternate implementation for
> CombineFileInputFormat.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2261) Fair Multiple Task Assignment Scheduler (Assigning multiple tasks per heart beat)
[ https://issues.apache.org/jira/browse/MAPREDUCE-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981408#action_12981408 ] Todd Lipcon commented on MAPREDUCE-2261: How does this differ from the assignmultiple feature present in the fairscheduler in trunk? > Fair Multiple Task Assignment Scheduler (Assigning multiple tasks per heart > beat) > - > > Key: MAPREDUCE-2261 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2261 > Project: Hadoop Map/Reduce > Issue Type: New Feature >Affects Versions: 0.21.0 >Reporter: Devaraj K > > Functionality wise the Fair Multiple Task Assignment Scheduler behaves > the same way except the assignment of Tasks. Instead of assigning a single > Task per heartbeat, it checks for all the jobs if any local or non-local Task > that can be launched. > Fair Multiple Task Assignment Scheduler has the advantage of assigning > multiple jobs per heart beat interval depending upon the slots available on > the Task Tracker, by configuring the number of parallel tasks to be executed > in a Task Tracker at any point of time. The advantages are as follows: > a) Parallel Execution allows tasks be to submitted and processed in parallel > independent of the status of other tasks. > b) More number of tasks is assigned in a heartbeat interval and consequently > multitasking capability increases. > c) With multi task assignment, Task Tracker efficiency is increased. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2255) correct example code in /api/org/apache/hadoop/util/Tool.html
[ https://issues.apache.org/jira/browse/MAPREDUCE-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981406#action_12981406 ] Todd Lipcon commented on MAPREDUCE-2255: Hi Minoru. First, thanks for helping to contribute! Would you mind uploading a single patch file taken from the root of the SVN checkout (eg using svn diff)? Please see the "Creating a patch" section in http://wiki.apache.org/hadoop/HowToContribute if you need a pointer. > correct example code in /api/org/apache/hadoop/util/Tool.html > - > > Key: MAPREDUCE-2255 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2255 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: documentation >Affects Versions: 0.20.2 > Environment: None >Reporter: minoru nishikubo >Priority: Trivial > Attachments: Tool.html.patch, Tool.java.patch > > > a trivial mistake(?) in example code. But I wondered where Sort() was come > from for a few days. > < int res = ToolRunner.run(new Configuration(), new Sort(), args); > --- > > int res = ToolRunner.run(new Configuration(), new MyApp(), args); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MAPREDUCE-2261) Fair Multiple Task Assignment Scheduler (Assigning multiple tasks per heart beat)
Fair Multiple Task Assignment Scheduler (Assigning multiple tasks per heart beat) - Key: MAPREDUCE-2261 URL: https://issues.apache.org/jira/browse/MAPREDUCE-2261 Project: Hadoop Map/Reduce Issue Type: New Feature Affects Versions: 0.21.0 Reporter: Devaraj K Functionality wise the Fair Multiple Task Assignment Scheduler behaves the same way except the assignment of Tasks. Instead of assigning a single Task per heartbeat, it checks for all the jobs if any local or non-local Task that can be launched. Fair Multiple Task Assignment Scheduler has the advantage of assigning multiple jobs per heart beat interval depending upon the slots available on the Task Tracker, by configuring the number of parallel tasks to be executed in a Task Tracker at any point of time. The advantages are as follows: a) Parallel Execution allows tasks be to submitted and processed in parallel independent of the status of other tasks. b) More number of tasks is assigned in a heartbeat interval and consequently multitasking capability increases. c) With multi task assignment, Task Tracker efficiency is increased. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2259) Hadoop Streaming JAR location might be updated
[ https://issues.apache.org/jira/browse/MAPREDUCE-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] minoru nishikubo updated MAPREDUCE-2259: Attachment: streaming.xml.patch a patch to source document is available. > Hadoop Streaming JAR location might be updated > -- > > Key: MAPREDUCE-2259 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2259 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: documentation > Environment: N/A >Reporter: minoru nishikubo >Priority: Trivial > Attachments: streaming.xml.patch > > > examples in docs/streaming.html: > $HADOOP_HOME/hadoop-streaming.jar > might be updated to > $HADOOP_HOME/contrib/streaming/hadoop-$HADOOP-VERSION-streaming.jar > for someone could not find the streaming archive. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2259) Hadoop Streaming JAR location might be updated
[ https://issues.apache.org/jira/browse/MAPREDUCE-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] minoru nishikubo updated MAPREDUCE-2259: Status: Open (was: Patch Available) > Hadoop Streaming JAR location might be updated > -- > > Key: MAPREDUCE-2259 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2259 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: documentation > Environment: N/A >Reporter: minoru nishikubo >Priority: Trivial > Attachments: streaming.xml.patch > > > examples in docs/streaming.html: > $HADOOP_HOME/hadoop-streaming.jar > might be updated to > $HADOOP_HOME/contrib/streaming/hadoop-$HADOOP-VERSION-streaming.jar > for someone could not find the streaming archive. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2259) Hadoop Streaming JAR location might be updated
[ https://issues.apache.org/jira/browse/MAPREDUCE-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] minoru nishikubo updated MAPREDUCE-2259: Status: Patch Available (was: Open) > Hadoop Streaming JAR location might be updated > -- > > Key: MAPREDUCE-2259 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2259 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: documentation > Environment: N/A >Reporter: minoru nishikubo >Priority: Trivial > > examples in docs/streaming.html: > $HADOOP_HOME/hadoop-streaming.jar > might be updated to > $HADOOP_HOME/contrib/streaming/hadoop-$HADOOP-VERSION-streaming.jar > for someone could not find the streaming archive. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2255) correct example code in /api/org/apache/hadoop/util/Tool.html
[ https://issues.apache.org/jira/browse/MAPREDUCE-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] minoru nishikubo updated MAPREDUCE-2255: Attachment: Tool.html.patch Tool.java.patch Tool.java.patch is for src/core/apache/hadoop/util/Tool.java. Tool.html.patch may not be necessary, because it will be generated by JavaDoc. > correct example code in /api/org/apache/hadoop/util/Tool.html > - > > Key: MAPREDUCE-2255 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-2255 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: documentation >Affects Versions: 0.20.2 > Environment: None >Reporter: minoru nishikubo >Priority: Trivial > Attachments: Tool.html.patch, Tool.java.patch > > > a trivial mistake(?) in example code. But I wondered where Sort() was come > from for a few days. > < int res = ToolRunner.run(new Configuration(), new Sort(), args); > --- > > int res = ToolRunner.run(new Configuration(), new MyApp(), args); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
