[
https://issues.apache.org/jira/browse/HBASE-21640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16729215#comment-16729215
]
Hudson commented on HBASE-21640:
--------------------------------
Results for branch branch-2
[build #1577 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1577/]:
(x) *{color:red}-1 overall{color}*
----
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1577//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1577//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1577//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Remove the TODO when increment zero
> -----------------------------------
>
> Key: HBASE-21640
> URL: https://issues.apache.org/jira/browse/HBASE-21640
> Project: HBase
> Issue Type: Improvement
> Reporter: Guanghao Zhang
> Assignee: Guanghao Zhang
> Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.2, 2.0.4
>
> Attachments: HBASE-21640.master.001.patch,
> HBASE-21640.master.002.patch, HBASE-21640.master.003.patch
>
>
>
> {code:java}
> // If delta amount to apply is 0, don't write WAL or MemStore.
> long deltaAmount = getLongValue(delta);
> // TODO: Does zero value mean reset Cell? For example, the ttl.
> apply = deltaAmount != 0;
> {code}
> This is an optimization when increment 0. But it introduced some new problems.
> 1.As the TODO said, Does zero value mean reset ttl?
> 2.HBASE-17318 have to introduce a new variable "firstWrite" because it don't
> apply 0.
> 3. There is a coprocessor method postMutationBeforeWAL to return a new cell.
> But it may be not applied.
>
> {code:java}
> // Give coprocessors a chance to update the new cell
> if (coprocessorHost != null) {
> newCell =
> coprocessorHost.postMutationBeforeWAL(mutationType, mutation,
> currentValue, newCell);
> }
> // If apply, we need to update memstore/WAL with new value; add it toApply.
> if (apply || firstWrite) {
> toApply.add(newCell);
> }
> {code}
>
> So my proposal is remove this optimization. Any suggestions are welcomed.
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
