[
https://issues.apache.org/jira/browse/CASSANDRA-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13206210#comment-13206210
]
Pavel Yaskevich commented on CASSANDRA-3884:
--------------------------------------------
bq. That sounds buggy to me, the goal of CASSANDRA-1391 was to make it so you
don't have to care about that kind of thing anymore.
There is still no way to make migrations atomic so the same rule applies, we
made possible to concurrent schema propagation with CASSANDRA-1391 so we don't
need to worry about ordering (or time) of the changes but what happens when you
update keyspace/column_family simultaneously doing heavy write/read is still
unpredictable because that would require some sort of global lock while
KSMetaData/CFMetaData are mutated.
> Intermittent SchemaDisagreementException
> ----------------------------------------
>
> Key: CASSANDRA-3884
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3884
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Environment: using ccm on ubuntu.
> Reporter: Tyler Patterson
> Assignee: Pavel Yaskevich
>
> Set up a cluster of two nodes (on cassandra-1.1), create some keyspaces and
> column families, and then make several schema changes. Everything is being
> done through only one of the nodes. About once every 10 times (on my setup)
> I get a SchemaDisagreementException when creating and dropping keyspaces.
> There is a dtest for this: schema_changes_test.py. If your environment
> behaves like mine, you might need to run it 10 times to get the error.
--
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
