[
https://issues.apache.org/jira/browse/HBASE-7774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572046#comment-13572046
]
Anoop Sam John commented on HBASE-7774:
---------------------------------------
bq.so calling kv.getTimestamp() during the comparisons in put.has() will
populate kv.timestampCache with Long.MAX_VALUE
I think this is fixed in some other Jira.
bq.Now, I think this has bigger implications. Basically, you can't rely on the
timestamp at all in prePut()
Yes. we faced this issue while working with the secondary index implementation.
We wanted to populate the index Puts in a pre hook but the TS which will be
used by the original put is generated after this hook call in HRegion. That is
also one of the reason why we introduced new hooks. Pls have a look at
HBASE-4210
> RegionObserver.prePut() cannot rely on the Put's timestamps, can even cause
> data loss
> -------------------------------------------------------------------------------------
>
> Key: HBASE-7774
> URL: https://issues.apache.org/jira/browse/HBASE-7774
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.92.2, 0.96.0, 0.94.4
> Reporter: Jean-Daniel Cryans
> Priority: Critical
>
> We had a user that had code that looked like this in a coprocessor's prePut():
> {code}
> if (put.has(expectedKv))
> put.add(kvSayingIFoundIt);
> else
> put.add(kvSayingNotFound);
> {code}
> If you have MSLAB turned *off*, and you have the {{expectedKv}} in your
> {{Put}}, doing a {{Get}} following your insert will only return
> {{kvSayingIFoundIt}} and not the KV you were actually inserting.
> More so, if you only do {{put.has(expectedKv)}}, you will not get anything
> back. Your data seems to be gone.
> The reason is that in {{prePut()}} the timestamp hasn't been set yet, so
> calling {{kv.getTimestamp()}} during the comparisons in {{put.has()}} will
> populate {{kv.timestampCache}} with {{Long.MAX_VALUE}}. Then it will stay in
> the {{MemStore}} with that big timestamp and be filtered out because
> {{TimeRange}} will compare {{Long.MAX_VALUE}} >= {{Long.MAX_VALUE}} and
> return {{SKIP}}.
> And the reason it works correctly with MSLAB *on* is that the KV is cloned in
> {{maybeCloneWithAllocator()}} and the cache is reset.
> Now, I think this has bigger implications. Basically, you can't rely on the
> timestamp at all in {{prePut()}}. I'm sure this can screw someone else in a
> creative way later.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
