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-15133) Data loss after compaction when a row has more than Integer.MAX_VALUE columns
Date Thu, 21 Jan 2016 04:45:39 GMT

    [ 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)

Mime
View raw message