[
https://issues.apache.org/jira/browse/CASSANDRA-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920324#action_12920324
]
Gary Dusbabek commented on CASSANDRA-1585:
------------------------------------------
One approach is to push migrations onto the CompactionManager executor. pro:
simple. con: a major compaction on column family X will block what would
normally be a quick schema update on column family Y.
Another approach is to try to allow parallel operations, probably using locks.
I envision something like this:
lock(cfId);
// do work
unlock(cfId);
pro: parallel operations. con: more complicated.
> 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.
