[
https://issues.apache.org/jira/browse/HBASE-13933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593314#comment-14593314
]
ramkrishna.s.vasudevan commented on HBASE-13933:
------------------------------------------------
bq.The other difference between all DBEs and Prefix Tree is that when we seek
to a key after the last key all the DBEs will point to the last key when we do
scanner.getKeyValue. But Prefix_Tree is giving a null. Is it fine to have this
behaviourial change? May be in normal scan this will not happen? This can be
done in a seperate JIRA.
The if condition in the test case is for the above condition. Will raise a
seperate JIRA for that. Let it be there. Once we do HBASE-13933 that will be
needed.
> DBE's seekBefore with tags corrupts the tag's offset information thus leading
> to incorrect results
> --------------------------------------------------------------------------------------------------
>
> Key: HBASE-13933
> URL: https://issues.apache.org/jira/browse/HBASE-13933
> Project: HBase
> Issue Type: Bug
> Affects Versions: 1.0.0, 2.0.0, 1.0.1, 1.1.0, 0.98.13, 1.0.1.1, 1.1.0.1
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Priority: Critical
> Fix For: 2.0.0, 0.98.14, 1.0.2, 1.2.0, 1.1.1, 1.3.0
>
> Attachments: HBASE-13933.patch, HBASE-13933_2.patch,
> HBASE-13993_1.patch
>
>
> The problem occurs with moveToPrevious() case and incase of tags we copy the
> previous pointer's tag info to the current because already decoded the tags.
> Will check once again before I post other details. I have a test case to
> reproduce the problem. Found this while working with MultibyteBuffers and
> verified if this is present in trunk - it is in all branches where we have
> tags compression (I suppose) will verify
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
