[
https://issues.apache.org/jira/browse/CASSANDRA-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190957#comment-13190957
]
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: https://issues.apache.org/jira/browse/CASSANDRA-3716
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
