hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10252) Don't write back to WAL/memstore when Increment amount is zero (mostly for query rather than update intention)
Date Wed, 12 Feb 2014 07:05:20 GMT

    [ https://issues.apache.org/jira/browse/HBASE-10252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13898875#comment-13898875

stack commented on HBASE-10252:

So, this patch breaks an asynchbase test (see the below -- thanks to [~tsuna] for help debugging).
 The test presumes that even though the increment value is 0, if the cell does not exist yet,
then the cell is created (with a value of 0).  That is how it worked in 0.96 and previous.

[~fenghh] My guess is that you did not intend to remove this behavior?  If that is the case,
I'll make a small patch in a new issue to restore cell creation though the value is zero.
 Thanks boss.

21:28:57.922 [main] ERROR org.hbase.async.test.TestIntegration - Test failed: incrementCoalescingWithZeroSumAmount
java.lang.AssertionError: List was expected to contain 1 items but was found to contain 0:
	at org.hbase.async.test.TestIntegration.assertSizeIs(TestIntegration.java:851) [build/:na]
	at org.hbase.async.test.TestIntegration.incrementCoalescingWithZeroSumAmount(TestIntegration.java:595)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_45]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_45]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_45]
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) ~[junit-4.11.jar:na]
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) ~[junit-4.11.jar:na]
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) ~[junit-4.11.jar:na]
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) ~[junit-4.11.jar:na]
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) ~[junit-4.11.jar:na]
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) ~[junit-4.11.jar:na]
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) [junit-4.11.jar:na]
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) [junit-4.11.jar:na]
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) [junit-4.11.jar:na]
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) [junit-4.11.jar:na]
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) [junit-4.11.jar:na]
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) [junit-4.11.jar:na]
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) [junit-4.11.jar:na]
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) [junit-4.11.jar:na]
	at org.junit.runners.ParentRunner.run(ParentRunner.java:309) [junit-4.11.jar:na]
	at org.junit.runner.JUnitCore.run(JUnitCore.java:160) [junit-4.11.jar:na]
	at org.junit.runner.JUnitCore.run(JUnitCore.java:138) [junit-4.11.jar:na]
	at org.hbase.async.test.TestIntegration.main(TestIntegration.java:133) [build/:na]

> Don't write back to WAL/memstore when Increment amount is zero (mostly for query rather
than update intention)
> --------------------------------------------------------------------------------------------------------------
>                 Key: HBASE-10252
>                 URL: https://issues.apache.org/jira/browse/HBASE-10252
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>            Reporter: Feng Honghua
>            Assignee: Feng Honghua
>             Fix For: 0.98.0, 0.99.0
>         Attachments: HBASE-10252-trunk-v0.patch, HBASE-10252-trunk-v1.patch
> When user calls Increment by providing amount=0, we don't write the original value to
WAL or memstore : adding 0 yields a 'new' value just with the same value as the original one.
> 1. user provides 0 amount for query rather than for update, this fix is ok; this intention
is the most possible case;
> 2. user provides 0 amount for an update, this fix is also ok : no need to touch back-end
value if that value isn't changed;
> 3. either case we both return correct value, and keep subsequent query results correct
: if the 0 amount Increment is the first update, the query is the same for retrieving a 0
value or retrieving nothing;

This message was sent by Atlassian JIRA

View raw message