[
https://issues.apache.org/jira/browse/HBASE-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932357#action_12932357
]
HBase Review Board commented on HBASE-3235:
-------------------------------------------
Message from: "Gary Helmling" <[email protected]>
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1224/
-----------------------------------------------------------
Review request for hbase and Ryan Rawson.
Summary
-------
Fix for MemStore.upsert(KeyValue) to start the kvset.tailSet() of potential KVs
to remove at the beginning of entries for the row/family/qualifier combination,
ignoring timestamp to prevent Puts being skipped based on timestamp alone and
masking the ICV.
This addresses bug HBASE-3235.
http://issues.apache.org/jira/browse/HBASE-3235
Diffs
-----
src/main/java/org/apache/hadoop/hbase/regionserver/MemStore.java b7409b0
src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java 7640997
Diff: http://review.cloudera.org/r/1224/diff
Testing
-------
Added a new test:
TestHRegion.testIncrementColumnValue_UpdatingInPlace_TimestampClobber() to
recreate the existing failure condition: 1) put to a row/family/qualifier, 2)
ICV to the same row/family/qualifier with the same timestamp. This test fails
consistently without the patch to MemStore.
With the patch to MemStore, the new test case consistently passes. I also ran
TestHRegion 15+ times and saw no more intermittent failures of
testIncrementColumnValue_UpdatingInPlace(). Previously this was failing every
5 or so test runs, so this seems a pretty good indication it's fixed.
I also ran through the full test suite on 0.90 and all passed except for an
error in TestHLog...
Thanks,
Gary
> Intermittent incrementColumnValue failure in TestHRegion
> --------------------------------------------------------
>
> Key: HBASE-3235
> URL: https://issues.apache.org/jira/browse/HBASE-3235
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 0.90.0
> Reporter: Gary Helmling
>
> I first saw this in a Hudson build, but can reproduce locally with enough
> test runs (5-10 times):
> {noformat}
> -------------------------------------------------------------------------------
> Test set: org.apache.hadoop.hbase.regionserver.TestHRegion
> -------------------------------------------------------------------------------
> Tests run: 51, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 39.413 sec
> <<< FAILURE!
> testIncrementColumnValue_UpdatingInPlace(org.apache.hadoop.hbase.regionserver.TestHRegion)
> Time elapsed: 0.079 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<2>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:283)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:195)
> at junit.framework.Assert.assertEquals(Assert.java:201)
> at
> org.apache.hadoop.hbase.regionserver.TestHRegion.testIncrementColumnValue_UpdatingInPlace(TestHRegion.java:1889)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {noformat}
> Alternately, the failure can also show up in
> testIncrementColumnValue_UpdatingInPlace_Negative():
> {noformat}
> testIncrementColumnValue_UpdatingInPlace_Negative(org.apache.hadoop.hbase.regionserver.TestHRegion)
> Time elapsed: 0.03 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<2> but was:<3>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:283)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:130)
> at junit.framework.Assert.assertEquals(Assert.java:136)
> at
> org.apache.hadoop.hbase.regionserver.TestHRegion.assertICV(TestHRegion.java:2081)
> at
> org.apache.hadoop.hbase.regionserver.TestHRegion.testIncrementColumnValue_UpdatingInPlace_Negative(TestHRegion.java:1990)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
