You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (Created) (JIRA)" <ji...@apache.org> on 2011/10/31 17:33:32 UTC
[jira] [Created] (CASSANDRA-3430) Break Big Compaction Lock apart
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
Fix For: 1.0.2
--
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
[jira] [Commented] (CASSANDRA-3430) Break Big Compaction Lock apart
Posted by "Sylvain Lebresne (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13142037#comment-13142037 ]
Sylvain Lebresne commented on CASSANDRA-3430:
---------------------------------------------
In submitTruncate, I think we should push the lock inside the for loop and grab it for each CF. Otherwise we have no guarantee the indexed cf are not compacting during the call to markCompacted.
But other than that it lgtm.
> 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.2
>
> 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
[jira] [Updated] (CASSANDRA-3430) Break Big Compaction Lock apart
Posted by "Jonathan Ellis (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-3430:
--------------------------------------
Fix Version/s: (was: 1.0.7)
1.1
> 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.1
>
> 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
[jira] [Commented] (CASSANDRA-3430) Break Big Compaction Lock apart
Posted by "Sylvain Lebresne (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Issue Comment Edited] (CASSANDRA-3430) Break Big Compaction
Lock apart
Posted by "Jonathan Ellis (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13142366#comment-13142366 ]
Jonathan Ellis edited comment on CASSANDRA-3430 at 11/2/11 6:08 PM:
--------------------------------------------------------------------
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 that either we need to make index compaction lock both the base CF as well as itself, or just bag this for 1.0 and only do it in 1.1. Kind of inclined towards the latter.
was (Author: jbellis):
Hmm. If we do that then 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 that either we need to make index compaction lock both the base CF as well as itself, or just bag this for 1.0 and only do it in 1.1. Kind of inclined towards the latter.
> 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.2
>
> 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
[jira] [Updated] (CASSANDRA-3430) Break Big Compaction Lock apart
Posted by "Sylvain Lebresne (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-3430:
----------------------------------------
Fix Version/s: (was: 1.1)
1.1.1
> 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.1.1
>
> 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
[jira] [Updated] (CASSANDRA-3430) Break Big Compaction Lock apart
Posted by "Jonathan Ellis (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-3430:
--------------------------------------
Attachment: 3430-1.0.txt
3430-1.1.txt
> 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.2
>
> 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
[jira] [Commented] (CASSANDRA-3430) Break Big Compaction Lock apart
Posted by "Jonathan Ellis (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13142366#comment-13142366 ]
Jonathan Ellis commented on CASSANDRA-3430:
-------------------------------------------
Hmm. If we do that then 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 that either we need to make index compaction lock both the base CF as well as itself, or just bag this for 1.0 and only do it in 1.1. Kind of inclined towards the latter.
> 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.2
>
> 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