[
https://issues.apache.org/jira/browse/HBASE-6200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13400323#comment-13400323
]
Jieshan Bean commented on HBASE-6200:
-------------------------------------
@Anoop:
Thanks for your carefully review.
Only the createLastOnRow methods using Type.Minimum. Likes below:
{noformat}
public static KeyValue createLastOnRow(final byte[] row) {
return new KeyValue(row, null, null, HConstants.LATEST_TIMESTAMP,
Type.Minimum);
}
{noformat}
At this time, the length of CF (or Qualifier) should be 0.
Actually, we can create one KeyValue with CF as empty but Qualifier is not
empty. And if we call KeyValue#getQualifier, we can get the correct value. So I
think this check should be strict with both CF == 0 and Qualifier == 0.
> 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-trunk-v2.patch, HBASE-6200-90-v2.patch,
> HBASE-6200-90.patch, HBASE-6200-92-v2.patch, HBASE-6200-92.patch,
> HBASE-6200-94-v2.patch, HBASE-6200-94.patch, HBASE-6200-trunk-v2.patch,
> HBASE-6200-trunk.patch
>
>
> 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
