cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-7403) Reconciliation doesn't consider fields specific to expiring cells
Date Tue, 08 Jul 2014 10:04:05 GMT


Sylvain Lebresne updated CASSANDRA-7403:

    Attachment: 7403-followup.txt

The commit broke ColumnFamilyStoreTest.testIndexUpdateOverwritingExpiringColumns. It's not
really the fault of the patch, it's more an incompleteness of CASSANDRA-7268, but since the
later has been committed in released versions and the tests broke with this commit, let's
quickly follow up here.

The problem is that the patch CASSANDRA-7268 was not properly rebased on 2.1: the {{shouldCleanupOldValue}}
path was only skipped in the case the new cell is not live (which is not too useful). Attaching
simple followup that fixes that (I removed the SecondaryIndex.upate method because it was
getting in the way, I figure that was not a big deal but maybe it is for custom indexes?).
The patch also include minor updates of the comments of the patch for this ticket.

> Reconciliation doesn't consider fields specific to expiring cells 
> ------------------------------------------------------------------
>                 Key: CASSANDRA-7403
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Sam Tunnicliffe
>            Assignee: Benedict
>             Fix For: 2.1 rc3
>         Attachments: 7403-followup.txt
> Reconciling 2 ExpiringColumns which are equal in every way except for the localExpirationTime
field will always favour the instance on which reconcile is called as fields specific to expiration
are not considered. 
> This is actually beneficial in pre-2.1 versions as in AtomicSortedColumns.Holder.addColumn
we call reconcile on the new column, which 'wins' the reconcilliation and so the localExpirationTime
is effectively extended.
> From 2.1 onwards, reconcile is actually called on the existing value (in BTreeSortedColumns.ColumnUpdater)
and so it wins the reconcilliation and the ttl doesn't get extended. The same thing happens
in the iterator returned from MergeIterator.Reducer.getReducer() so we see the same behaviour
when merging cells from the multiple SSTables and/or memtables.

This message was sent by Atlassian JIRA

View raw message