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