Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 30 Jun 2011 15:05:29 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <1862833606.5751.1309446329275.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1705351038.14649.1308314568122.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (CASSANDRA-2786) After a minor compaction, deleted
 key-slices are visible again
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sylvain Lebresne updated CASSANDRA-2786:
----------------------------------------

    Attachment: 2786_part2.patch

Yeah, turns out EchoedRow is also handling Row tombstones with no columns inside badly.

Attaching patch with fix and unit test. 0.7 is not really impacted because it uses EchoedRow only for cleanup and don't use its isEmpty() function there (but I suppose we could make it throw an UnsupporteOperationException to be on the safe side).

The patch actually ship with two changes that are not strictly related to the issue:
# It fixes testEchoedRow in CompactionsTest. It wasn't using EchoedRow anymore (i.e, the test was useless).
# It always forces deserialization for user submitted compaction (by opposition to only when the user submits only 1 sstable). It is done because exposing the forceDeserialization flag was necessary to write the test for this issue. Following that change, it was trivial to do the user submitted compaction change. It also fix a bad comment (forcing deserialization is only useful for forcing expired column to become tombstones, not for purging since purging will happen without force deserialization if it can).

> After a minor compaction, deleted key-slices are visible again
> --------------------------------------------------------------
>
>                 Key: CASSANDRA-2786
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2786
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.8.0
>         Environment: Reproduced on single Cassandra node (CentOS 5.5)
> Reproduced on single Cassandra node (Windows Server 2008)
>            Reporter: rene kochen
>            Assignee: Sylvain Lebresne
>             Fix For: 0.8.1, 0.8.2
>
>         Attachments: 0001-Fix-wrong-purge-of-deleted-cf.patch, 2786_part2.patch, CassandraIssue.zip, CassandraIssueJava.zip
>
>
> After a minor compaction, deleted key-slices are visible again.
> Steps to reproduce:
> 1) Insert a row named "test".
> 2) Insert 500000 rows. During this step, row "test" is included in a major compaction:
>    file-1, file-2, file-3 and file-4 compacted to file-5 (includes "test").
> 3) Delete row named "test".
> 4) Insert 500000 rows. During this step, row "test" is included in a minor compaction:
>    file-6, file-7, file-8 and file-9 compacted to file-10 (should include tombstoned "test").
> After step 4, row "test" is live again.
> Test environment:
> Single node with empty database.
> Standard configured super-column-family (I see this behavior with several gc_grace settings (big and small values):
> create column family Customers with column_type = 'Super' and comparator = 'BytesType;
> In Cassandra 0.7.6 I observe the expected behavior, i.e. after step 4, the row is still deleted.
> I've included a .NET program to reproduce the problem. I will add a Java version later on.

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