Mukil Kesavan created CASSANDRA-11586:
-----------------------------------------
Summary: Insert or Update Behavior 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)
