cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joel Knighton (JIRA)" <>
Subject [jira] [Resolved] (CASSANDRA-11484) Consistency issues with subsequent writes, deletes and reads
Date Mon, 25 Apr 2016 21:44:12 GMT


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:
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: Cassandra version: DataStax Enterprise 4.7.1
> Driver version: cassandra-driver-core-
>            Reporter: Prashanth
>            Assignee: Joel Knighton
>         Attachments:
> 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

View raw message