[jira] [Comment Edited] (CASSANDRA-11586) Avoid Silent Insert or Update Failure In Clusters With Time Skew

["DOAN DuyHai (JIRA)" <ji...@apache.org>]

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

DOAN DuyHai edited comment on CASSANDRA-11586 at 4/16/16 5:53 PM:
------------------------------------------------------------------

bq. The client receives no error when the last statement is executed even though the request was dropped.

 To be able to detect that the existing cell (in memtable *AND* on disk) has a timestamp greater than the timestamp of the current mutation, Cassandra will necessarily need to read data before validating the mutation.

 That's what we call *read-before-write* and this is an anti-pattern because it just kills the write throughput.

 I think this JIRA is not an issue because synchronizing system time is out of Cassandra scope. This is the system administration responsibility



was (Author: doanduyhai):
bq. The client receives no error when the last statement is executed even though the request was dropped.

 To be able to detect that the existing cell (in memtable **AND** on disk) has a timestamp greater than the timestamp of the current mutation, Cassandra will necessarily need to read data before validating the mutation.

 That's what we call **read-before-write** and this is an anti-pattern because it just kills the write throughput.

 I think this JIRA is not an issue because synchronizing system time is out of Cassandra scope. This is the system administration responsibility


> 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)