[
https://issues.apache.org/jira/browse/HBASE-26713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482805#comment-17482805
]
Bryan Beaudreault commented on HBASE-26713:
-------------------------------------------
Sorry for the lack of clarity[~apurtell] , wanted to log this while it was
fresh but was end of day for us. We’ll probably tackle this tomorrow because
it’s blocking us, but would appreciate any help with review.
> Increments submitted by 1.x clients will be stored with timestamp 0 on 2.x+
> clusters
> ------------------------------------------------------------------------------------
>
> Key: HBASE-26713
> URL: https://issues.apache.org/jira/browse/HBASE-26713
> Project: HBase
> Issue Type: Bug
> Reporter: Bryan Beaudreault
> Priority: Major
> Fix For: 2.5.0, 3.0.0-alpha-3, 2.4.10
>
>
> We discovered this in our work on upgrading from ~1.2.0 to 2.4.6. A 1.2.0
> client will submit an Increment, without specifying a timestamp. This should
> be translated as LATEST_TIMESTAMP, but an hbase 2 server will store it with a
> timestamp of 0.
> This is because the QualifierValue timestamp proto field is optional, and is
> not set in branch-1 MutationProtos:
> [https://github.com/apache/hbase/blob/branch-1/hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/RequestConverter.java#L218-L219.]
> In branch-1, the timestamp is actually ignored entirely:
> [https://github.com/apache/hbase/blob/branch-1/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java#L8435-L8456.]
> So this is not an issue there.
> As of HBASE-18546, the timestamp is no longer ignored, but the usage of
> QualiferValue.getTimestamp() in deserialization is not wrapped in a
> .hasTimestamp() call:
> [https://github.com/apache/hbase/blob/7d8dc3524981a04e82ff236bb3dc18d36ebc82b4/hbase-client/src/main/java/org/apache/hadoop/hbase/shaded/protobuf/ProtobufUtil.java#L886-L909].
> The default value for non-present optionals is defined by the underlying
> primitive, so for longs that is 0. Since the Increment's timestamp is now
> respected by HRegion, it causes the erroneous 0 value to be stored:
> [https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java#L4180]
> (updateLatestStamp only overwrites the cell timestamp if it's
> LATEST_TIMESTAMP, which in this case it has been deserialized as 0)
> I think this might only apply to clients who do not use a KeyValueCodec.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
