cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5149) Respect slice count even if column expire mid-request
Date Fri, 14 Jun 2013 13:20:21 GMT


Sylvain Lebresne commented on CASSANDRA-5149:

The overall approach looks good to me, though:
* I'd feel a bit better if we were just removing the isMarkedForDelete() (without arguments)
call in Column, so that every caller knows he has to deal with it. It's otherwise hard to
make sure we never call the no-argument version by accident. There's probably a few other
places too (Row for instance) where I'd prefer avoiding having a shortcut calling System.currentTimeMillis().
* In RowIteratorFactory, I think it would make sense to use the filter timestamp rather than
relying on System.currentTimeMillis() for gcBefore.
* There is possibly a few places where a function takes 'gcBefore' and 'now', either directly
(collectReducedColumns), or because they have a filter and gcBefore (CFS.filterColumnFamily()).
Maybe we could drop the gcBefore and just rely on the timestamp.

> Respect slice count even if column expire mid-request
> -----------------------------------------------------
>                 Key: CASSANDRA-5149
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>    Affects Versions: 0.7.0
>            Reporter: Sylvain Lebresne
>            Assignee: Aleksey Yeschenko
>             Fix For: 2.0
> This is a follow-up of CASSANDRA-5099.
> If a column expire just while a slice query is performed, it is possible for replicas
to count said column as live but to have the coordinator seeing it as dead when building the
final result. The effect that the query might return strictly less columns that the requested
slice count even though there is some live columns matching the slice predicate but not returned
in the result.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message