hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13945) [0.98] Prefix_Tree seekBefore() does not work correctly
Date Mon, 22 Jun 2015 10:15:00 GMT

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

Anoop Sam John commented on HBASE-13945:
----------------------------------------

KeyValueUtil being private interface +1 for changing this method behavior.   I was thinking
whether we should leave the KVUtil method as is and at used place do a BB#rewind().   But
as it is private no issue to change also..
copyKeyToNewByteBuffer -> Just add a javadoc to this method and clearly say that the BB
position will be at the begin of the key bytes in the buffer. If any one uses this tomorrow,
it will be quite clear from the doc then.
We have similar logic in copyToNewByteBuffer().  This is used by PrefixTreeSeeker#getKeyValueBuffer()
but no usage for this API as such.  Still can you change copyToNewByteBuffer() also similar
way?  And add a clear doc?

Can fix on commit. am +1

> [0.98] 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: 0.98.2
>            Reporter: ramkrishna.s.vasudevan
>            Assignee: ramkrishna.s.vasudevan
>             Fix For: 0.98.14
>
>         Attachments: HBASE-13945_0.98.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