[
https://issues.apache.org/jira/browse/HBASE-12078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhangduo updated HBASE-12078:
-----------------------------
Description:
our row key is combined with two ints, and we found that sometimes when we
using only the first int part to scan, the result returned may missing some
rows. But when we dump the whole hfile, the row is still there.
We have written a testcase to reproduce the bug. It works like this:
put 1-12345
put 12345-0x01000000
put 12345-0x01010000
put 12345-0x02000000
put 12345-0x02020000
put 12345-0x03000000
put 12345-0x03030000
put 12345-0x04000000
put 12345-0x04040000
flush memstore
then scan using 12345，the returned row key will be
12345-0x20000000(12345-0x10000000 expected)
was:
our row key is combined with two ints, and we found that sometimes when we
using only the first int part to scan, the result returned may missing some
rows. But when we dump the whole hfile, the row is still there.
We have written a testcase to reproduce the bug. It works like this:
put 1-12345
put 12345-0x01000000
put 12345-0x01010000
put 12345-0x02000000
put 12345-0x02020000
put 12345-0x03000000
put 12345-0x03030000
put 12345-0x04000000
put 12345-0x04040000
then scan using 12345，the returned row key will be
12345-0x20000000(12345-0x10000000 expected)
> Missing Data when scanning using PREFIX_TREE DATA-BLOCK-ENCODING
> ----------------------------------------------------------------
>
> Key: HBASE-12078
> URL: https://issues.apache.org/jira/browse/HBASE-12078
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.98.6.1
> Environment: CentOS 6.3
> hadoop 2.5.0(hdfs)
> hadoop 2.2.0(hbase)
> hbase 0.98.6.1
> sun-jdk 1.7.0_67-b01
> Reporter: zhangduo
> Attachments: prefix_tree_error.patch
>
>
> our row key is combined with two ints, and we found that sometimes when we
> using only the first int part to scan, the result returned may missing some
> rows. But when we dump the whole hfile, the row is still there.
> We have written a testcase to reproduce the bug. It works like this:
> put 1-12345
> put 12345-0x01000000
> put 12345-0x01010000
> put 12345-0x02000000
> put 12345-0x02020000
> put 12345-0x03000000
> put 12345-0x03030000
> put 12345-0x04000000
> put 12345-0x04040000
> flush memstore
> then scan using 12345，the returned row key will be
> 12345-0x20000000(12345-0x10000000 expected)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
