[
https://issues.apache.org/jira/browse/HBASE-16148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15410361#comment-15410361
]
Enis Soztutar commented on HBASE-16148:
---------------------------------------
bq. Should we update the server clock with client set timestamps ? In HBase,
client can set any timestamp he wants, it could have any skew.
I feel we should not update the clock with client set timestamps, rather send
another field in put request which just reads time of system clock, use that to
update server clock.
With HLC the expectation is that the client normally will not set the
timestamps, only servers will do. But from RS perspective there is no
distinction between doing Puts where the client has actually set the
timestamps, versus through intercluster replication or wal recovery receiving
Puts with already-set timestamps. It would be good to differentiate between
these two cases so that if it is the client, we will not call update server
clock, otherwise we will.
However, if we want to be flexible still in having the client to optionally set
timestamps together with servers, then we can do it so that all Puts update the
server clocks. If the request is more than the configured clock skew, it will
be rejected anyway.
> Hybrid Logical Clocks(placeholder for running tests)
> ----------------------------------------------------
>
> Key: HBASE-16148
> URL: https://issues.apache.org/jira/browse/HBASE-16148
> Project: HBase
> Issue Type: Sub-task
> Components: API
> Reporter: Sai Teja Ranuva
> Assignee: Sai Teja Ranuva
> Priority: Minor
> Labels: test-patch
> Attachments: HBASE-16148.master.001.patch,
> HBASE-16148.master.6.patch, HBASE-16148.master.test.1.patch,
> HBASE-16148.master.test.2.patch, HBASE-16148.master.test.3.patch,
> HBASE-16148.master.test.4.patch, HBASE-16148.master.test.5.patch,
> HLC.1.patch, HLC.2.patch, HLC.3.patch, HLC.patch
>
>
> This JIRA is just a placeholder to test Hybrid Logical Clocks code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
