[jira] [Commented] (CASSANDRA-10021) Losing writes in a single-node cluster

["Aleksey Yeschenko (JIRA)" <ji...@apache.org>]

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

Aleksey Yeschenko commented on CASSANDRA-10021:
-----------------------------------------------

In Cassandra, last written value wins, where 'last written' means 'with highest timestamp'. In case of a timestamp tie, the largest value (per its type comparator) wins.

In your case, you are overwriting a cell with another value but close enough in time (within the same millisecond), that they are getting the same auto-generated timestamp on the server side. And in that case, the cell with the largest value wins (20.500). In other words, this is expected behaviour if you have multiple sessions.

That said, if you are doing all the writes within the same session, you should not have clashes in the timestamps. It's possible that some related bug got fixed in 2.1.8+.

Not sure what you want us to do here. 2.0 line is officially over, and, as you say, you cannot reproduce the problem in 2.1 and up. There is nothing to do.

Per your comment, closing as Cannot Reproduce. That said, if you stumble upon it in the latest 2.1/2.2/3.0 release - feel free to reopen.

> Losing writes in a single-node cluster
> --------------------------------------
>
>                 Key: CASSANDRA-10021
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10021
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: Docker images
>            Reporter: Jeremy Schlatter
>            Assignee: Sylvestor George
>         Attachments: cpp-repro.zip, go-repro.zip
>
>
> I am able to reliably reproduce write losses in the following circumstances:
> * Set up a single-node cluster.
> * Create keyspace with SimpleStrategy, replication_factor = 1.
> * Create a table with a float field.
> * Send an UPDATE command to set the float value on a row.
> * After the command returns, immediately send another UPDATE to set the float value to something _smaller_ than the first value.
> * The second UPDATE is sometimes lost.
> Reproduction code attached. There are two implementations: one in Go and one in C++. They do the same thing -- I implemented both to rule out a bug in the client library. For both cases, you can reproduce by doing the following:
> 1. docker run --name repro-cassandra --rm cassandra:2.0.14
> (or any other Cassandra version)
> 2. Download and unzip one of the zip files, and change to its directory.
> 3. docker build -t repro .
> 4. docker run --link repro-cassandra:cassandra --rm repro
> The reproduction code will repeatedly run two UPDATEs followed by a SELECT until it detects a lost write, and then print:
> "Lost a write. Got 20.500000, want 10.500000"
> This may be fixed in 2.1.8 because I have not been able to reproduce it in that version.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)