Gridmix simulated job's map's hdfsBytesRead counter is wrong when compressed
input is used
--
Key: MAPREDUCE-2722
URL: https://issues.apache.org/jira/browse/MAPREDUCE-2722
See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/745/
###
## LAST 60 LINES OF THE CONSOLE
###
[...truncated 234832 lines...]
[junit]0.9:96658
[junit]
MR-279: port MAPREDUCE-2324 to mrv2
---
Key: MAPREDUCE-2723
URL: https://issues.apache.org/jira/browse/MAPREDUCE-2723
Project: Hadoop Map/Reduce
Issue Type: Sub-task
Components: mrv2
Affects Vers
Moving to mapreduce-dev@, bcc general@.
Yes, as described in the bug, the CS has high-ram jobs which is a
better model for shared multi-tenant clusters. The hadoop-0.20.203
release from Apache has the most current and tested version of the
CapacityScheduler.
Arun
Sent from my iPhone
On Jul 22,
[
https://issues.apache.org/jira/browse/MAPREDUCE-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Joseph Evans resolved MAPREDUCE-2572.
Resolution: Won't Fix
I filed this and the more I think about it that s
I've recently using hadoop*(version 0.21.0)* for some data processing, but
sometimes reducer crashed. Always the log is like bellow(at the end of this
mail), which tells when multi fetchers recieved mapoutput simultaneously,
the merge part may fail due to some disadvantages. To verify this
assumpti
Pls open a jira and file the patch. Thanks!
Sent from my iPhone
On Jul 22, 2011, at 6:56 PM, sp yu wrote:
> I've recently using hadoop*(version 0.21.0)* for some data processing, but
> sometimes reducer crashed. Always the log is like bellow(at the end of this
> mail), which tells when multi fe
