cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3716) Clean up isMarkedForDelete / getLocalDeletionTime
Date Mon, 23 Jan 2012 09:50:38 GMT


Sylvain Lebresne commented on CASSANDRA-3716:

bq. Any ideas on reducing that danger?

Not much, no. Some of the iMFD calls are actually on IColumnContainer, for which it's not
dependent on timing. But it's a minority of calls, so renaming those instances wouldn't help
much (and since SuperColumn is both a IColumn and IColumnContainer, we'd have to duplicate
the method, which wouldn't be a win for code clarity imo).

But in fact I'm not convince iMFD is really much of an issue. Since we have expiring columns,
there is nothing wrong with the fact that iMFD is dependent on time, and in fact this is perfectly
ok for most of the code. The real fragility is the two-pass compaction that pretty much expect
that the world is frozen between the two passes, which is  very fragile. I want to give a
serious look to CASSANDRA-2319 in a hopefully not too distant future. That would allow getting
rid of the two passes, so may be the right way to get rid of this fragility.

It couldn't hurt however to add some comments on Column/IColumn to remind that iMFD does depend
on time for expiring columns. 
> Clean up isMarkedForDelete / getLocalDeletionTime
> -------------------------------------------------
>                 Key: CASSANDRA-3716
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Sylvain Lebresne
>              Labels: compaction
>             Fix For: 1.1
>         Attachments: 3716.patch
> As explained in CASSANDRA-3579, isMarkedForDelete() depends on the current system clock
so it can change during a two-pass compaction.  Suggested fix is to replace iMFD + gLDT with
a getExpirationTime method, so comparison with the compaction's gcBefore will remain constant.

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


View raw message