Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Date: Wed, 16 Nov 2016 14:55:58 +0000 (UTC)
From: "Phil Yang (JIRA)" <jira@apache.org>
To: dev@hbase.apache.org
Message-ID: <JIRA.13021162.1479308149000.292814.1479308158634@Atlassian.JIRA>
In-Reply-To: <JIRA.13021162.1479308149000@Atlassian.JIRA>
References: <JIRA.13021162.1479308149000@Atlassian.JIRA> <JIRA.13021162.1479308149891@arcas>
Subject: [jira] [Created] (HBASE-17112) Prevent setting timestamp of delta
 operations being same as previous value's
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 16 Nov 2016 14:56:01 -0000

Phil Yang created HBASE-17112:
---------------------------------

             Summary: Prevent setting timestamp of delta operations being same as previous value's
                 Key: HBASE-17112
                 URL: https://issues.apache.org/jira/browse/HBASE-17112
             Project: HBase
          Issue Type: Bug
            Reporter: Phil Yang
            Assignee: Phil Yang


In delta operations, Increment and Append. We will read current value first and then write the new whole result into WAL as the type of Put with current timestamp. If the previous ts is larger than current ts, we will use the previous ts.

If we have two Puts with same TS, we will ignore the Put with lower sequence id. It is not friendly with versioning. And for replication we will drop sequence id  while writing to peer cluster so in the slave we don't know what the order they are being written. If the pushing is disordered, the result will be wrong.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)