[
https://issues.apache.org/jira/browse/HBASE-15133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15110044#comment-15110044
]
ramkrishna.s.vasudevan commented on HBASE-15133:
------------------------------------------------
I think for scans atleast you could control the number of columns being fetched
by batching but while doing compactions we may have to rely on this countPerRow
only and that cannot overflow. I think that is why they are able to live with
the existing scan APIs.
> Data loss after compaction when a row has more than Integer.MAX_VALUE columns
> -----------------------------------------------------------------------------
>
> Key: HBASE-15133
> URL: https://issues.apache.org/jira/browse/HBASE-15133
> Project: HBase
> Issue Type: Bug
> Components: Compaction
> Reporter: Toshihiro Suzuki
> Assignee: Toshihiro Suzuki
> Attachments: HBASE-15133-v1.patch, HBASE-15133.patch
>
>
> We have lost the data in our development environment when a row has more than
> Integer.MAX_VALUE columns after compaction.
> I think the reason is type of StoreScanner's countPerRow is int.
> https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java#L67
> After changing the type to long, it seems to be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
