[ https://issues.apache.org/jira/browse/HBASE-6200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401868#comment-13401868 ]
Hudson commented on HBASE-6200: ------------------------------- Integrated in HBase-TRUNK #3077 (See [https://builds.apache.org/job/HBase-TRUNK/3077/]) HBASE-6200 KeyComparator.compareWithoutRow can be wrong when families have the same prefix (Jieshan) (Revision 1354290) Result = FAILURE tedyu : Files : * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/KeyValue.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/TestKeyValue.java > KeyComparator.compareWithoutRow can be wrong when families have the same > prefix > ------------------------------------------------------------------------------- > > Key: HBASE-6200 > URL: https://issues.apache.org/jira/browse/HBASE-6200 > Project: HBase > Issue Type: Bug > Affects Versions: 0.90.6, 0.92.1, 0.94.0 > Reporter: Jean-Daniel Cryans > Assignee: Jieshan Bean > Priority: Blocker > Fix For: 0.90.7, 0.92.2, 0.96.0, 0.94.1 > > Attachments: 6200-0.92.txt, 6200-0.94.txt, 6200-90.patch, > 6200-trunk-v2.patch, 6200-trunk-v3.patch, 6200-trunk-v4.txt > > > As reported by Desert Rose on IRC and on the ML, {{Result}} has a weird > behavior when some families share the same prefix. He posted a link to his > code to show how it fails, http://pastebin.com/7TBA1XGh > Basically {{KeyComparator.compareWithoutRow}} doesn't differentiate families > and qualifiers so "f:a" is said to be bigger than "f1:", which is false. Then > what happens is that the KVs are returned in the right order from the RS but > then doing {{Result.binarySearch}} it uses > {{KeyComparator.compareWithoutRow}} which has a different sorting so the end > result is undetermined. > I added some debug and I can see that the data is returned in the right order > but {{Arrays.binarySearch}} returned the wrong KV, which is then verified > agains the passed family and qualifier which fails so null is returned. > I don't know how frequent it is for users to have families with the same > prefix, but those that do have that and that use those families at the same > time will have big correctness issues. This is why I mark this as a blocker. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira