[
https://issues.apache.org/jira/browse/CASSANDRA-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920337#action_12920337
]
Gary Dusbabek commented on CASSANDRA-1585:
------------------------------------------
There are more timing issues than we discussed on IRC that neither approach
addresses. They all relate to the lifecycle of ColumnFamilyStore instances.
Consider these steps:
1. Migration X is scheduled (say it's a rename)
2. Compaction of X is scheduled.
The compaction manager deals directly with ColumnFamilyStore instances, which
aren't directly acted on by a schema migration, but which can really have their
underpinnings mangled (files moving around basically). At the very least, we
should check to make sure the CFS instances are still valid when the executor
gets around to letting them run.
Am I making sense?
> Schema change with compaction race
> ----------------------------------
>
> Key: CASSANDRA-1585
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1585
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Stu Hood
> Assignee: Gary Dusbabek
> Priority: Minor
> Fix For: 0.7.0
>
>
> We observed what appeared to be a race between an ongoing compaction and a
> system_drop_cf call. The destination SSTable of the compaction was not
> removed by the drop, so it remained in the data directory. Recreating a CF of
> the same name caused the SSTable to become active again (or to at least show
> in the gossiped load).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
