[
https://issues.apache.org/jira/browse/MAPREDUCE-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13565944#comment-13565944
]
Arun C Murthy commented on MAPREDUCE-2264:
------------------------------------------
Comments:
# We shouldn't introduce a whole set of ctors if we can avoid it - particularly
since Segment is just internal api. Proliferation of ctors is something to
avoid.
# The Segment.getRawDataLength implementation is odd - won't it be better to
just set rawLength = getLength() as default-value unless it's passed in
explicitly?
# We seem to be doing localFS.getFileStatus(file).getLen() on
CompressAwarePaths, won't it be easier to set it up so that we just call
Segment.getLength() by, maybe, doing localFS.getFileStatus(file).getLen() in
the Segment ctor or lazily in Segment.getLength?
# A coding nit: we should add a CompressAwarePath.create static method and use
it rather than try to 'new' one in several places. Obviously a factory is nicer
for unit-testing etc., but it's an overkill for now?
> 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
> Affects Versions: 0.20.2, 0.20.205.0
> Reporter: Adam Kramer
> Assignee: Devaraj K
> Labels: critical-0.22.0
> Fix For: 1.2.0, 2.0.3-alpha
>
> Attachments: MAPREDUCE-2264-0.20.205-1.patch,
> MAPREDUCE-2264-0.20.205.patch, MAPREDUCE-2264-0.20.3.patch,
> MAPREDUCE-2264-branch-1-1.patch, MAPREDUCE-2264-branch-1-2.patch,
> MAPREDUCE-2264-branch-1.patch, MAPREDUCE-2264-trunk-1.patch,
> MAPREDUCE-2264-trunk-1.patch, MAPREDUCE-2264-trunk-2.patch,
> MAPREDUCE-2264-trunk-3.patch, MAPREDUCE-2264-trunk-4.patch,
> MAPREDUCE-2264-trunk-5.patch, MAPREDUCE-2264-trunk-5.patch,
> MAPREDUCE-2264-trunk.patch, more than 100%.bmp
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
