[
https://issues.apache.org/jira/browse/CASSANDRA-11586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15247001#comment-15247001
]
Mukil Kesavan commented on CASSANDRA-11586:
-------------------------------------------
I agree that is cleaner to leave the timestamp generation to the client.
However, if an update is made to a row by a client with a timestamp older than
the last write time, the request still fails silently. And bear in mind that we
can have multiple clients on different machines as well in which case the java
driver AtomicMonotonicTimestampGenerator doesn't help.
There are solutions around this if we use the "using timestamp" option and
strategies like global timestamp generation or a combination of client side
locking (with zookeeper for example) and read/update with latest timestamp. We
could also perform updates solely through a single "leader" client. But these
solutions end up paying a performance price on every update whereas in practice
the situations where updates with older timestamps may arise infrequently. A
simple error/exception/return value indicating that an update failed from the
server side passed back to the java driver will let clients handle this as
required.
> 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)
