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