Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 21 Aug 2014 00:59:27 +0000 (UTC)
From: "Jonathan Ellis (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12735615.1408581642047.9121.1408582767076@arcas>
In-Reply-To: <JIRA.12735615.1408581642047@arcas>
References: <JIRA.12735615.1408581642047@arcas>
Subject: [jira] [Commented] (CASSANDRA-7808) LazilyCompactedRow incorrectly
 handles row tombstones
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-7808?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D=
14104889#comment-14104889 ]=20

Jonathan Ellis commented on CASSANDRA-7808:
-------------------------------------------

If the problem is incorrectly clearing, how did 5677 introduce it?

> LazilyCompactedRow incorrectly handles row tombstones
> -----------------------------------------------------
>
>                 Key: CASSANDRA-7808
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7808
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Richard Low
>             Fix For: 1.2.19
>
>         Attachments: 7808-v1.diff
>
>
> LazilyCompactedRow doesn=E2=80=99t handle row tombstones correctly, leadi=
ng to an AssertionError (CASSANDRA-4206) in some cases, and the row tombsto=
ne being incorrectly dropped in others. It looks like this was introduced b=
y CASSANDRA-5677.
> To reproduce an AssertionError:
> 1. Hack a really small return value for DatabaseDescriptor.getInMemoryCom=
pactionLimit() like 10 bytes to force large row compaction
> 2. Create a column family with gc_grace =3D 10
> 3. Insert a few columns in one row
> 4. Call nodetool flush
> 5. Delete the row
> 6. Call nodetool flush
> 7. Wait 10 seconds
> 8. Call nodetool compact and it will fail
> To reproduce the row tombstone being dropped, do the same except, after t=
he delete (in step 5), insert a column that sorts before the ones you inser=
ted in step 3. E.g. if you inserted b, c, d in step 3, insert a now. After =
the compaction, which now succeeds, the full row will be visible, rather th=
an just a.
> The problem is two fold. Firstly, LazilyCompactedRow.Reducer.reduce() and=
 getReduce() incorrectly call container.clear(). This clears the columns (a=
s intended) but also removes the deletion times from container. This means =
no further columns are deleted if they are annihilated by the row tombstone=
.
> Secondly, after the second pass, LazilyCompactedRow.isEmpty() is called w=
hich calls
> {{ColumnFamilyStore.removeDeletedCF(emptyColumnFamily, controller.gcBefor=
e(key.getToken()))}}
> which unfortunately removes the last deleted time from emptyColumnFamily =
if it is earlier than gcBefore. Since this is only called after the second =
pass, the second pass doesn=E2=80=99t remove any columns that are removed b=
y the row tombstone whereas the first pass removes just the first one.
> This is pretty serious - no large rows can ever be compacted and row tomb=
stones can go missing.


--
This message was sent by Atlassian JIRA
(v6.2#6252)