[
https://issues.apache.org/jira/browse/CASSANDRA-11586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-11586.
------------------------------------------
Resolution: Not A Problem
I guess what you're describing here is a downside of server-side assigned
timestamps and it's been discussed in CASSANDRA-6178. Long story short, if you
need to guarantee that your 2nd update is considered after your 1st insert,
then you should make sure the timestamp of the update is greater than the oe of
the insert, which means you should assign the timestamp client side. Which, for
reason I argue CASSANDRA-6178, is imo a better idea in general anyway and
modern drivers and versions of C* can do that for you transparently.
> Avoid Silent Insert or Update Failure In Clusters With Time Skew
> ----------------------------------------------------------------
>
> Key: CASSANDRA-11586
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11586
> Project: Cassandra
> Issue Type: Bug
> Components: Core, CQL
> Reporter: Mukil Kesavan
>
> It isn't uncommon to have a cluster of Cassandra servers with clock skew
> ranging from a few milliseconds to seconds or even minutes even with NTP
> configured on them. We use the coordinator's timestamp for all insert/update
> requests. Currently, an update to an already existing row with an older
> timestamp (because the request coordinator's clock is lagging behind) results
> in a successful response to the client even though the update was dropped.
> Here's a sample sequence of requests:
> * Consider 3 Cassandra servers with times, T+10, T+5 and T respectively
> * INSERT INTO TABLE1 (id, data) VALUES (1, "one"); is coordinated by server 1
> with timestamp (T+10)
> * UPDATE TABLE1 SET data='One' where id=1; is coordinated by server 3 with
> timestamp T
> The client receives no error when the last statement is executed even though
> the request was dropped.
> It will be really helpful if we could return an error or response to the
> client indicating that the request was dropped. This gives the client an
> option to handle this situation gracefully. If this is useful, I can work on
> a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
