David Ribeiro Alves has posted comments on this change. Change subject: [c++client] propagating timestamp for scans ......................................................................
Patch Set 1: I mention this yesterday, but it was pretty late and maybe you didn't get a chance to read it. A snapshot's timestamp is distinct from the timestamp that is propagated. If you look at NewScanRequestPB (https://github.com/cloudera/kudu/blob/master/src/kudu/tserver/tserver.proto#L209) you can see that there is a snap_timestamp field and propagated_timestamp field. We already propagate the client's timestamp to the server (when we set 'snap_timestamp' in NewScanRequestPB, what we're missing is getting a 'propagated_timestamp' in ScanResponsePB and using that to update the client's last known timestamp. The snap_timestamp in the ScanRequest/Response refers to the timestamp of the scan itself. For instance the user can set this arbitrarily in the past to do historic scans, but the propagated_timestamp would still be the current value of the servers clock. I see how having a 'snap_timestamp' in the response might be confusing, but it does refer to the scan's timestamp and not to the timestamp that must be propagated. It's there because if the user doesn't specify a timestamp for the scan the server chooses one (based on the value obtained from the clock if after being updated with the ScanRequest's propagated timestamp). The value is returned on the response so that the client can continue the scan on another tablet while using the same timestamp. -- To view, visit http://gerrit.cloudera.org:8080/5099 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: I4d79024b088ea88fd194cabcb61e640f66326264 Gerrit-PatchSet: 1 Gerrit-Project: kudu Gerrit-Branch: master Gerrit-Owner: Alexey Serbin <aser...@cloudera.com> Gerrit-Reviewer: David Ribeiro Alves <dral...@apache.org> Gerrit-Reviewer: Kudu Jenkins Gerrit-HasComments: No
