[
https://issues.apache.org/jira/browse/HBASE-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968511#action_12968511
]
ryan rawson commented on HBASE-2856:
------------------------------------
question was: would we overflow a long?
At 2^63, we have about 9.22 x 10^18 values available.
At 50,000 operations/second, we will take about 5,849,424 years to roll over.
Stack points out, what about bulk commit, this would then wrap up every bulk
commit as 1 memstore/RWCC transaction, which might be the logically wrong thing
to do, and also the extra time it takes to insert that much stuff into memstore
could also be an issues with RWCC. It is very important that RWCC transactions
stay short or else we pile up too many handlers.
> TestAcidGuarantee broken on trunk
> ----------------------------------
>
> Key: HBASE-2856
> URL: https://issues.apache.org/jira/browse/HBASE-2856
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.89.20100621
> Reporter: ryan rawson
> Assignee: stack
> Priority: Blocker
> Fix For: 0.92.0
>
>
> TestAcidGuarantee has a test whereby it attempts to read a number of columns
> from a row, and every so often the first column of N is different, when it
> should be the same. This is a bug deep inside the scanner whereby the first
> peek() of a row is done at time T then the rest of the read is done at T+1
> after a flush, thus the memstoreTS data is lost, and previously 'uncommitted'
> data becomes committed and flushed to disk.
> One possible solution is to introduce the memstoreTS (or similarly equivalent
> value) to the HFile thus allowing us to preserve read consistency past
> flushes. Another solution involves fixing the scanners so that peek() is not
> destructive (and thus might return different things at different times alas).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
