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

Sylvain Lebresne commented on CASSANDRA-7403:
---------------------------------------------

Technically, the patch lgtm. I'm not sure I would have changed the rules for 
expiring cells to compare the expiration before comparing the values however, 
mainly for the sake of not changing an existing rule that was not really a bug. 
Of course, there is a real chance that no-one rely on this existing behaviour, 
but I'm not sure there is much benefits to taking that chance. Or more 
precisely, what does changing the behaviour in that case buys us? (note that I 
buy that for equal values favouring the longer TTL makes sense as it gives you 
some kind of "update the TTL in place", it's the unequal values case that is 
less clear to me).

> Reconciliation doesn't consider fields specific to expiring cells 
> ------------------------------------------------------------------
>
>                 Key: CASSANDRA-7403
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7403
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Sam Tunnicliffe
>            Assignee: Benedict
>             Fix For: 2.1.0
>
>
> 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
(v6.2#6252)

Reply via email to