hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ramkrishna.s.vasudevan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13945) Prefix_Tree seekBefore() does not work correctly
Date Mon, 22 Jun 2015 17:49:01 GMT

    [ https://issues.apache.org/jira/browse/HBASE-13945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14596320#comment-14596320
] 

ramkrishna.s.vasudevan commented on HBASE-13945:
------------------------------------------------

Ideally the test should have been used with BB.array() and BB.arrayOffset() but they tend
to use it with BBs and thus it was not asserting fully.
bq.      byte[] firstKeyInCurrentBlock = Bytes.getBytes(firstKey);
The next option is to change Bytes.getBytes to Bytes.toBytes?  In terms of getFirstKeyInBlock
whcih is the actual issue here usage of KVUtil API is not right.  If we still don't want to
change the KVUTil API then change Bytes.getBytes to Bytes.toBytes.

> 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_branch-1.1.patch, HBASE-13945_trunk.patch, HBASE-13945_trunk_1.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)

Mime
View raw message