Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 11 Oct 2013 13:58:43 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12673232.1381413597667.51628.1381499923930@arcas>
In-Reply-To: <JIRA.12673232.1381413597667@arcas>
References: <JIRA.12673232.1381413597667@arcas>
Subject: [jira] [Commented] (CASSANDRA-6178) Consider allowing timestamp at
 the protocol level ... and deprecating server side timestamps
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-6178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792631#comment-13792631 ] 

Sylvain Lebresne commented on CASSANDRA-6178:
---------------------------------------------

bq. Let's not forget that "Bad Things happen if not just your server clocks but also your app server clocks are not synchronized" confuses people too.

I don't really buy that "you need to synchronize your server clocks" would somewhat make perfect sense but doing so for the clients would be highly confusing.  Using server-side timestamps solves in *no* way whatsoever the situation that this stackoverflow user describe in particular.

I'm not really convinced that server side timestamps makes much of anything simpler for a user point of view (versus having the timestamp set by the driver that is).  Yes, you need to run ntpd on your clients too, but that sound hardly a big deal to me. In fact, provided you have any timeseries type usage, it's probably a good idea to synchronize your clients clock anyway for the sake of your (time-based) column names.

bq. What if we just made the client default to a single server per Session and only failover when necessary?

To be honest, I think that's a really bad idea.

First, that does not really work, since when you failover, you'll still potentially fail the "sequential updates made on the same client thread will be applied sequentially".

And secondly, that heavily constraint the architecture of clients. Concretely, that goes against the basic architecture of the java driver for instance: it breaks pretty much all of the load balancing policies provided, including things like token aware and latency based policies. And the driver does not distinguish between reads and writes because one of our most fundamental design choice from day one has been "we do not parse the query client side". It also makes it harder to manage your server connections efficiently (in particular, I don't know how to even code this with the current java driver API without relying on thread IDs, but there's no easy way to know when a thread dies so that would be a mess).

And all this for what? Because we're afraid asking people to set-up ntpd client side is too much?


> Consider allowing timestamp at the protocol level ... and deprecating server side timestamps
> --------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6178
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6178
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>
> Generating timestamps server side by default for CQL has been done for convenience, so that end-user don't have to provide one with every query.  However, doing it server side has the downside that updates made sequentially by one single client (thread) are no guaranteed to have sequentially increasing timestamps. Unless a client thread is always pinned to one specific server connection that is, but no good client driver out (that is, including thrit driver) there does that because that's contradictory to abstracting fault tolerance to the driver user (and goes again most sane load balancing strategy).
> Very concretely, this means that if you write a very trivial test program that sequentially insert a value and then erase it (or overwrite it), then, if you let CQL pick timestamp server side, the deletion might not erase the just inserted value (because the delete might reach a different coordinator than the insert and thus get a lower timestamp). From the user point of view, this is a very confusing behavior, and understandably so: if timestamps are optional, you'd hope that they are least respect the sequentiality of operation from a single client thread.
> Of course we do support client-side assigned timestamps so it's not like the test above is not fixable. And you could argue that's it's not a bug per-se.  Still, it's a very confusing "default" behavior for something very simple, which suggest it's not the best default.
> You could also argue that inserting a value and deleting/overwriting right away (in the same thread) is not something real program often do. And indeed, it's likely that in practice server-side timestamps work fine for most real application. Still, it's too easy to get counter-intuitive behavior with server-side timestamps and I think we should consider moving away from them.
> So what I'd suggest is that we push back the job of providing timestamp client side. But to make it easy for the driver to generate it (rather than the end user), we should allow providing said timestamp at the protocol level.
> As a side note, letting the client provide the timestamp would also have the advantage of making it easy for the driver to retry failed operations with their initial timestamp, so that retries are truly idempotent.


--
This message was sent by Atlassian JIRA
(v6.1#6144)