[
https://issues.apache.org/jira/browse/HBASE-13945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ramkrishna.s.vasudevan updated HBASE-13945:
-------------------------------------------
Attachment: HBASE-13945_trunk_2.patch
Patch for trunk. The last patch for trunk had adjusted the position and limit
in the test case for it to pass. Now the rewind operation in
getKeyValueBuffer() will ensure that the BB is also compared on per byte basis
- which was never happening.
> Prefix_Tree seekBefore() does not work correctly
> ------------------------------------------------
>
> Key: HBASE-13945
> URL: https://issues.apache.org/jira/browse/HBASE-13945
> Project: HBase
> Issue Type: Bug
> Affects Versions: 1.0.0, 0.98.2, 1.0.1, 1.1.0, 1.0.1.1, 1.1.0.1
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Fix For: 0.98.14, 1.0.2, 1.2.0, 1.1.1, 1.1.2, 1.3.0, 1.2.1
>
> Attachments: HBASE-13945_0.98.patch, HBASE-13945_0.98_1.patch,
> HBASE-13945_0.98_2.patch, HBASE-13945_0.98_3.patch,
> HBASE-13945_branch-1.1.patch, HBASE-13945_trunk.patch,
> HBASE-13945_trunk_1.patch, HBASE-13945_trunk_2.patch
>
>
> This is related to the TestSeekTo test case where the seekBefore() does not
> work with Prefix_Tree because of an issue in getFirstKeyInBlock(). In the
> trunk and branch-1 changing the return type of getFirstKeyInBlock() from BB
> to Cell resolved the problem, but the same cannot be done in 0.98. Hence we
> need a change in the KvUtil.copyToNewBuffer API to handle this. Since the
> limit is made as the position - in seekBefore when we do
> {code}
> byte[] firstKeyInCurrentBlock = Bytes.getBytes(firstKey);
> {code}
> in HFileReaderV2.seekBefore() we end up in an empty byte array and it would
> not be the expected one based on which we try to seek to load a new block.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
