Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 18 Mar 2011 14:30:29 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <928807310.11698.1300458629815.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1148400259.1549.1299519839521.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Commented: (CASSANDRA-2279) Tombstones not collected
 post-repair
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008450#comment-13008450 ] 

Sylvain Lebresne commented on CASSANDRA-2279:
---------------------------------------------

bq. we'll need a separate patch for 0.6

I don't think 0.6 suffers from the problem fixed by the attached patch. It uses CFStore.getFamily() for range slices to do its bidding which handles correctly the column family deletion times as far as I can tell.

Which make me think that there could be something else at hand here. I'll have a look at Joaquin instructions to try to reproduce what he is seeing. 

> Tombstones not collected post-repair
> ------------------------------------
>
>                 Key: CASSANDRA-2279
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2279
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Tools
>    Affects Versions: 0.6
>            Reporter: Joaquin Casares
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 0.6.13, 0.7.5
>
>         Attachments: RowIteration-unit-tests.patch, fix-RowIteratorFactory.patch, nodeA.txt, nodeB.txt
>
>
> The keys would only show up in sstables2json and look like this:
> (root@aps4):/opt/cassandra/storage/queue/data/Panama Wed Feb 23 07:24:34am 
> ===> /opt/cassandra/bin/sstable2json Queue-2527-Data.db -k waq:publicMessageIndexingWorkArea:PUM8a65ce95-9d35-4941-928c-dd5965e8b29b 
> 2011-02-23 07:24:43,710 INFO [org.apache.cassandra.config.DatabaseDescriptor] - DiskAccessMode 'auto' determined to be mmap, indexAccessMode is mmap 
> 2011-02-23 07:24:43,972 INFO [org.apache.cassandra.io.SSTableReader] - Opening /opt/cassandra/storage/queue/data/Panama/Queue-2527-Data.db 
> { 
> "waq:publicMessageIndexingWorkArea:PUM8a65ce95-9d35-4941-928c-dd5965e8b29b": [] 
> } 
> (root@aps4):/opt/cassandra/storage/queue/data/Panama Wed Feb 23 07:24:44am 
> ===>
> The steps that I took to reproduce it were:
> Create a keyspace, column family, and a key
> Delete the key on Node 1 using the cli (del cf['key'];)
> Flush 
> Repair on a cluster with more than 1 node
> Wait GCSeconds 
> Compact
> And the empty row would appear on Node 2
> However, when I was able to get rid of the empty rows, I was following these steps on a single machine: 
> Create a keyspace, column family, and a key
> Delete the key
> Flush
> Sample write (writing to some temporary key)
> Deleting the attribute to that temporary key (not the entire key)
> Flush
> Compact
> or these steps:
> Create a keyspace, column family, and a key
> Delete the key
> Flush 
> Wait GCseconds
> Compact

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira