cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3430) Break Big Compaction Lock apart
Date Mon, 07 Nov 2011 16:42:51 GMT

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

Sylvain Lebresne commented on CASSANDRA-3430:
---------------------------------------------

bq. Hmm. That's true, but that also makes it more obvious that we could potentially have data
flushed post-"main" truncate, whose indexes get truncated, so the index won't actually match
the data file. Right?

I think the current truncate is already racy. Because we flush and grab the truncateAt timestamp
outside of the compaction lock. So it is possible that between the grab of truncateAt and
the beginning of submitTruncate, some new sstable is flushed and compacted against "pre-truncate"
sstables (and since our compaction lock is not fair, it's not even an absolutely crazy scenario),
which would lead on the data on sstable not being removed (which can lead to having bad indexes
already since this can happen for an index cf only).

I don't really think this ticket makes this problem worst, nor does it fixes it. And grabbing
the baseCF lock along with the indexes ones wouldn't fix it either. I think what we must do
is lock everything before we even start doing the flush and grabbing of truncateAt.

But in any case, if we don't grab the index CF lock while calling markCompacted on that cf,
we have a risk of segfaulting the VM (if it happens we're deleting a sstable that is being
compacted). In other word, I would be fine with committing this ticket with the lock grabbing
pushed inside the for loop as of my initial comment on the argument that 'potentially have
some data not truncated as it should' is already an existing bug (and defer it's resolution
to another ticket), but I'm -1 on introducing the possibility of a JVM segfault.

                
> Break Big Compaction Lock apart
> -------------------------------
>
>                 Key: CASSANDRA-3430
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3430
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>            Priority: Minor
>              Labels: compaction
>             Fix For: 1.0.3
>
>         Attachments: 3430-1.0.txt, 3430-1.1.txt
>
>


--
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

        

Mime
View raw message