[
https://issues.apache.org/jira/browse/CASSANDRA-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis resolved CASSANDRA-5922.
---------------------------------------
Resolution: Cannot Reproduce
> Delete doesn't delete data.
> ---------------------------
>
> Key: CASSANDRA-5922
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5922
> Project: Cassandra
> Issue Type: Bug
> Environment: 4-node cluster w/ Cassandra v1.2.8
> Oracle JDK 1.6.0_45
> Netflix Astyanax 1.56.42
> Quorum read and write consistency level
> Reporter: Chris Eineke
>
> In a nutshell, I'm running several test cases against my Cassandra JPA
> implementation (astyanax-jpa, see https://github.com/ceineke/astyanax-jpa)
> and sometimes (!) batched deletes seem not to delete all rows specified in
> the batch.
> Here's the sequence of prepared CQL3 statements that is causing the issue to
> appear:
> TRUNCATE compositeentity;
> (delete all records so we have a clean slate)
> INSERT INTO compositeentity (compositekeypartone, compositekeyparttwo,
> compositekeypartthree, astring, auuid) VALUES (?, ?, ?, ?, ?);
> INSERT INTO compositeentity (compositekeypartone, compositekeyparttwo,
> compositekeypartthree, astring, auuid) VALUES (?, ?, ?, ?, ?);
> (insert two unique rows into the table)
> SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM
> compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND
> compositekeypartthree = ?;
> SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM
> compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND
> compositekeypartthree = ?;
> (load both rows from the table to validate their existence)
> SELECT COUNT(1) FROM compositeentity;
> (counts rows to validate the number of records in the table)
> BEGIN BATCH DELETE FROM compositeentity WHERE compositekeypartone = ? AND
> compositekeyparttwo = ? AND compositekeypartthree = ?; DELETE FROM
> compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND
> compositekeypartthree = ?; APPLY BATCH;
> (uses a logged batch to delete the two rows from the table)
> SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM
> compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND
> compositekeypartthree = ?;
> SELECT compositekeypartone, compositekeyparttwo, compositekeypartthree FROM
> compositeentity WHERE compositekeypartone = ? AND compositekeyparttwo = ? AND
> compositekeypartthree = ?;
> (tries loads the rows from the table to check that they don't exist anymore)
> After the delete, Cassandra has deleted only the first row so that the second
> SELECT here actually returns data. So far, this behaviour occurs randomly.
> This happens even if there's a long sleep (1s, 10s) between the batch delete
> and the selects. It is always the second row that isn't deleted, never the
> first.
> Thinking it might be timing issue (based on
> http://ria101.wordpress.com/2011/02/08/cassandra-the-importance-of-system-clocks-avoiding-oom-and-how-to-escape-oom-meltdown/),
> I've set up NTP to keep the clocks synchronized across all nodes (one node
> acts as the master which syncs to time.nrc.ca and {0,1,2,3}.ca.pool.ntp.org,
> whereas the remaining ones sync against the master. This hasn't reduced the
> number of times this behaviour crops up.
> (I am executing all statements with QUORUM level consistency.)
> I'm open to suggestions as to why this occurs and how I can fix it, if this
> can be fixed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
