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

Hong Tang commented on HADOOP-6834:
-----------------------------------

In the first append, lastLen is 0, lastKey refers to a valid byte array whose 
bytes are all zero. So the behavior is determined. However, I do agree that it 
is possible for a customary comparator, an zero-length byte array may not be a 
legal key type. So it would be nice to do a first-key check.

Ahad, would you be interested in providing a patch, or perhaps share with us a 
sample program with customized comparator that fails TFile.Writer.append?

> TFile.append compares initial key against null lastKey  
> --------------------------------------------------------
>
>                 Key: HADOOP-6834
>                 URL: https://issues.apache.org/jira/browse/HADOOP-6834
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: io
>    Affects Versions: 0.20.1, 0.20.2
>            Reporter: Ahad Rana
>
> The following code in TFile.KeyReigster.close: 
>             byte[] lastKey = lastKeyBufferOS.getBuffer();
>             int lastLen = lastKeyBufferOS.size();
>             if (tfileMeta.getComparator().compare(key, 0, len, lastKey, 0,
>                 lastLen) < 0) {
>               throw new IOException("Keys are not added in sorted order");
>             }
> compares the initial  key (passed in via  TFile.Writer.append) against a 
> technically NULL lastKey. lastKey is not initialized until after the first 
> call to TFile.Writer.append. The underlying RawComparator interface used for 
> comparisons does not stipulate the proper behavior when either length 1  or 
> length 2 is zero. In the case of LongWritable, its WritableComparator 
> implementation does an unsafe read on the passed in byte arrays b1 and b2. 
> Since TFile pre-allocates the buffer used for storing lastKey, this passes a 
> valid buffer with zero count to LongWritable's comparator, which ignores 
> length and thus produces incorrect results. 

-- 
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