[
https://issues.apache.org/jira/browse/CASSANDRA-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046554#comment-13046554
]
Hudson commented on CASSANDRA-2590:
-----------------------------------
Integrated in Cassandra-0.7 #504 (See
[https://builds.apache.org/job/Cassandra-0.7/504/])
fix removing columns and subcolumns that are supressed by a row
orsupercolumn tombstone during replica resolution
patch by Aaron Morton and jbellis; reviewed by slebresne for CASSANDRA-2590
jbellis :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1133873
Files :
* /cassandra/branches/cassandra-0.7/CHANGES.txt
*
/cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/service/RowResolverTest.java
* /cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/Util.java
*
/cassandra/branches/cassandra-0.7/test/unit/org/apache/cassandra/db/TableTest.java
*
/cassandra/branches/cassandra-0.7/src/java/org/apache/cassandra/service/RowRepairResolver.java
> row delete breaks read repair
> ------------------------------
>
> Key: CASSANDRA-2590
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2590
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Aaron Morton
> Assignee: Aaron Morton
> Priority: Minor
> Fix For: 0.7.7, 0.8.1
>
> Attachments: 0001-2590-v3.patch,
> 0001-cf-resolve-test-and-possible-solution-for-read-repai.patch, 2590-v2.txt,
> 2590-v4-0.7.txt
>
>
> related to CASSANDRA-2589
> Working at CL ALL can get inconsistent reads after row deletion. Reproduced
> on the 0.7 and 0.8 source.
> Steps to reproduce:
> # two node cluster with rf 2 and HH turned off
> # insert rows via cli
> # flush both nodes
> # shutdown node 1
> # connect to node 2 via cli and delete one row
> # bring up node 1
> # connect to node 1 via cli and issue get with CL ALL
> # first get returns the deleted row, second get returns zero rows.
> RowRepairResolver.resolveSuperSet() resolves a local CF with the old row
> columns, and the remote CF which is marked for deletion. CF.resolve() does
> not pay attention to the deletion flags and the resolved CF has both
> markedForDeletion set and a column with a lower timestamp. The return from
> resolveSuperSet() is used as the return for the read without checking if the
> cols are relevant.
> Also when RowRepairResolver.mabeScheduleRepairs() runs it sends two
> mutations. Node 1 is given the row level deletation, and Node 2 is given a
> mutation to write the old (and now deleted) column from node 2. I have some
> log traces for this if needed.
> A quick fix is to check for relevant columns in the RowRepairResolver, will
> attach shortly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
