Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # user >> Inconsistencies in comparisons using KeyComparator


Copy link to this message
-
Re: Inconsistencies in comparisons using KeyComparator
That is an interesting (disturbing) find Alan.  Hopefully the fallback is
rare.  Did you have a technique for making the compare fallback to pure
java compare?

Thank you,
St.Ack
On Mon, Apr 1, 2013 at 7:54 AM, Alan Chaney <[EMAIL PROTECTED]> wrote:

> Hi
>
> I need to write some code that sorts row keys identically to HBase.
>
> I looked at the KeyValue.KeyComparator code, and it seems that, by
> default, HBase elects to use the 'Unsafe' comparator as the basis of its
> comparison, with a fall-back to to the PureJavaComparer should Unsafe not
> be available (for example, in tests.)
>
> However, I'm finding that the sort order from a call to
> KeyValue.KeyComparator appears to be inconsistent between the two forms.
>
> As an example, comparing:
>
> (first param) (second param)
> 0000000000000000ffffffffffffff**ffffffffffffffffff616c1b to
> 0000000000000000ffffffffffffff**ffffffffffffffffff61741b
>
> gives 1 for the default (presumably, Unsafe) call, and -1 using the
> PureJavaComparator.
>
> I would actually expect it to be a -ve number, based on the difference of
> 6c to 74 in the 3rd from last byte above.
>
> Similarly
>
> 000000000000000000000000000000**000000000000000000616c1b to
> 000000000000000000000000000000**0000000000000000061741b
>
> gives > 0 instead of < 0. The PureJavaComparator does a byte-by-byte
> comparison by
>
> Is this expected? From the definition of lexicographical compare that I
> found, I don't think so. There's no issue of signed comparison here,
> because 0x6c and 0x74 are still +ve byte values.
>
> Regards
>
> Alan
>
>
>