[ 
https://issues.apache.org/jira/browse/HADOOP-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702134#action_12702134
 ] 

Chris Douglas commented on HADOOP-5589:
---------------------------------------

+1

{noformat}
     [exec] +1 overall.  
     [exec] 
     [exec]     +1 @author.  The patch does not contain any @author tags.
     [exec] 
     [exec]     +1 tests included.  The patch appears to include 3 new or 
modified tests.
     [exec] 
     [exec]     +1 javadoc.  The javadoc tool did not generate any warning 
messages.
     [exec] 
     [exec]     +1 javac.  The applied patch does not increase the total number 
of javac compiler warnings.
     [exec] 
     [exec]     +1 findbugs.  The patch does not introduce any new Findbugs 
warnings.
     [exec] 
     [exec]     +1 Eclipse classpath. The patch retains Eclipse classpath 
integrity.
     [exec] 
     [exec]     +1 release audit.  The applied patch does not increase the 
total number of release audit warnings.
{noformat}

Relevant tests, TestDatamerge and TestTupleWritable both pass

> TupleWritable: Lift implicit limit on the number of values that can be stored
> -----------------------------------------------------------------------------
>
>                 Key: HADOOP-5589
>                 URL: https://issues.apache.org/jira/browse/HADOOP-5589
>             Project: Hadoop Core
>          Issue Type: Improvement
>          Components: mapred
>    Affects Versions: 0.19.1
>            Reporter: Jingkei Ly
>            Assignee: Jingkei Ly
>         Attachments: HADOOP-5589-1.patch, HADOOP-5589-2.patch, 
> HADOOP-5589-3.patch, HADOOP-5589-4.patch, HADOOP-5589-4.patch
>
>
> TupleWritable uses an instance field of the primitive type, long, which I 
> presume is so that it can quickly determine if a position has been written to 
> in its array of Writables (by using bit-shifting operations on the long 
> field). The problem with this is that it implies that there is a maximum 
> limit of 64 values you can store in a TupleWritable.
> An example of a use-case where I think this would be a problem is if you had 
> two MR jobs with over 64 reduces tasks and you wanted to join the outputs 
> with CompositeInputFormat  - this will probably cause unexpected results in 
> the current scheme.
> At the very least, the 64-value limit should be documented in TupleWritable.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to