[jira] [Resolved] (CASSANDRA-11484) Consistency issues with subsequent writes, deletes and reads

["Joel Knighton (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-11484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joel Knighton resolved CASSANDRA-11484.
---------------------------------------
    Resolution: Not A Problem

Thanks for the report [~prashanth123] - I'm unable to reproduce this issue with the environment and test case you've described.

This is likely just a case of a mismatch in expectations. You should only expect to find the record deleted if the timestamp of the delete is greater than that of the initial insert for the record. It could be the case that the create and delete are handled by different coordinators whose clocks are out of sync, so that the insert is timestamped after the delete (or a similar situation). If the sstables are available to you, you may be able to confirm this by using a tool like sstable2json to look at the timestamps of the insert and delete.

It may be helpful to research Cassandra data models and other techniques (such as client-side timestamps) that can mitigate the above concerns in some circumstances.

If you are able to reproduce this still and strongly believe it isn't due to the above timestamp behavior, please reopen and we'll try to track it down farther.

> Consistency issues with subsequent writes, deletes and reads
> ------------------------------------------------------------
>
>                 Key: CASSANDRA-11484
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11484
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: Cassandra version: DataStax Enterprise 4.7.1
> Driver version: cassandra-driver-core-2.1.7.1
>            Reporter: Prashanth
>            Assignee: Joel Knighton
>         Attachments: CassandraDbCheckAppTest.java
>
>
> There have been intermittent failures when the following subsequent queries are performed on a 4 node cluster:
> 1. Insert a few records with consistency level QUORUM
> 2. Delete one of the records with consistency level ALL
> 3. Retrieve all the records with consistency level QUORUM or ALL and test that the deleted record does not exist
> The tests are failing because the record does not appear to be deleted and a pattern for the failures couldn't be established.
> A snippet of the code is attached to this issue so that the setup/tear down mechanism can be seen as well. 
> (Both truncating and dropping the table approaches where used as a tear down mechanism)



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