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