Just to clarify what I was saying, there was a JIRA where we were discussing this. Server clocks are unreliable and when region moves (or if we have writable replicas) between-server clocks are even more sor. So we cannot really promise consistency wrt order even for requests from the same client now; even if we manage TS 100%. My suggestion was that we have 3 modes: (1) we manage TS on server => TS gets written as seqNum which has guarantees, no client-supplied TS; (2) client manages TS and supplies it, fail put if no TS; (3) legacy compat mode, but TS is generated in the client library instead of RS, so the onus is on the client app/client's server to manage clocks and there's no expectation that HBase will guarantee order.
On Thu, Apr 10, 2014 at 5:09 PM, Nick Dimiduk <[email protected]> wrote: > Reading through the write path, it seems to me that > RSRpcServices#doBatchOp(RegionActionResult.Builder,HRegion,List<Action> > mutations,CellScanner) should be honoring a nonce if present. The reason > being: if a client sends some Puts without specifying a TS, it relies on > the RS to provide one. Should such an operation succeed on the server but > the ACK not reach the client, client may resend the operation, silently > inserting more cells than intended. Deletes may well be a more sinister > issue, removing more cells than intended. > > I've not yet written a test to confirm this. > > There was conversation around the implementation of nonces discussing > options for removing the coupling of TS to clock-on-the-wall time. Sergey > describes the current situation quite eloquently: "server-generated TS > provide illusion of consistency guarantees which is not there by any > means". A fix for this will likely subtly break the semantics of our data > coordinates, and so should be addressed with 1.0, perhaps along side a > revamped client-side API. > > -n > -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
