[
https://issues.apache.org/jira/browse/HBASE-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154002#comment-13154002
]
Lars Hofhansl commented on HBASE-2856:
--------------------------------------
Re: 0.92, I was going by your comment above
bq. If someone did it in next day or so, I'd be up for having it committed to
0.92 in time for first RC.
It's not entirely clean, yet:
{noformat}
Results :
Failed tests: testClosing(org.apache.hadoop.hbase.client.TestHCM)
testFilterAcrossMultipleRegions(org.apache.hadoop.hbase.client.TestFromClientSide):
expected:<17576> but was:<28064>
testForceSplit(org.apache.hadoop.hbase.client.TestAdmin): Scanned more than
expected (6000)
testForceSplitMultiFamily(org.apache.hadoop.hbase.client.TestAdmin): Scanned
more than expected (6000)
testSplitWhileBulkLoadPhase(org.apache.hadoop.hbase.mapreduce.TestLoadIncrementalHFilesSplitRecovery)
testGroupOrSplitPresplit(org.apache.hadoop.hbase.mapreduce.TestLoadIncrementalHFilesSplitRecovery)
testWholesomeSplit(org.apache.hadoop.hbase.regionserver.TestSplitTransaction)
testRollback(org.apache.hadoop.hbase.regionserver.TestSplitTransaction)
testBasicSplit(org.apache.hadoop.hbase.regionserver.TestHRegion)
Tests in error:
testShutdownFixupWhenDaughterHasSplit(org.apache.hadoop.hbase.regionserver.TestSplitTransactionOnCluster):
test timed out after 300000 milliseconds
Tests run: 1065, Failures: 9, Errors: 1, Skipped: 7
{noformat}
I have no time to look at these tonight, though. But that probably points to
another RC.
Would sure be nice if the acid guarantees that HBase claims would be met in
0.92 :)
> 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: Amitanand Aiyer
> Priority: Blocker
> Fix For: 0.94.0
>
> Attachments: 2856-0.92.txt, 2856-v2.txt, 2856-v3.txt, 2856-v4.txt,
> 2856-v5.txt, 2856-v6.txt, 2856-v7.txt, 2856-v8.txt,
> 2856-v9-all-inclusive.txt, acid.txt
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
