[
https://issues.apache.org/jira/browse/CASSANDRA-6178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885424#comment-13885424
]
Sylvain Lebresne commented on CASSANDRA-6178:
---------------------------------------------
bq. I agree running ntpd is not a big deal but that does not protect Cassandra
from bad clients. Due to this, it will be very hard to diagnose problems.
Customers to such service might report problems which might be due to
intermittent problems with their ntpd.
But clients can already provide their own timestamp, so you're not "protected
from bad clients" at all. In fact, because there is use cases where clients do
need to provide their own timestamps to guarantee specific orderings, you're
likely to get a mix of mostly server-side generated timestamp and a few client
generated ones, which imo is much more likely to give "very hard to diagnose
problems".
But hey, the main thing I want to do is adding the ability for clients to
provide the default timestamp for the query at the protocol level if they want
to. And we already allow client provided timestamps anyway, so it's not like it
would change everything. I'm fine making this optional initially, leaving
server-side generated default timestamp available for environments that thinks
it's better for them.
> 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.5#6160)
