cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew F. Dennis (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-2026) creating/dropping keyspaces does not work reliably
Date Mon, 24 Jan 2011 18:56:44 GMT

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

Matthew F. Dennis commented on CASSANDRA-2026:
----------------------------------------------

If you must call describe_versions until it matches otherwise the cluster breaks, then the
call you make to change schema should do this for you.  If after some reasonable amount of
time (or whatever you pass into the call) there still isn't schema agreement, then the call
can return with an error/exception.

I could easily be convinced the API itself shouldn't do this, but the CLI certainly should.
 When the call returns from the CLI, I expect my request to completely finished and things
working or I expect the CLI to return an error.  This applies to invocations in batch mode,
in file mode and in interactive mode.

> creating/dropping keyspaces does not work reliably
> --------------------------------------------------
>
>                 Key: CASSANDRA-2026
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2026
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.7.0
>         Environment: observed on EC2 and real HW
>            Reporter: Matthew F. Dennis
>             Fix For: 0.7.1
>
>
> Creating and/or dropping keyspaces on more than just a few nodes does not reliably work
(observed multiple times on 5, 15 and 40 node clusters. never observed on single node clusters)
> Right after a cluster is booted, importing a schema from yaml works reliably.
> However, creating keyspaces (same for dropping keyspaces) via the CLI, either with -f
or by pasting into the window usually does not work (though sometimes it does).  In particular,
only some nodes show the new changes while others do not.  ; 
> Often the changes are only reflected on the node where they were made, but not on any
other node.  Most of the time some small subset of the nodes get the changes, but the majority
do not.
> Sometimes it takes several attempts to expose the problem.  Once it happens the first
time though, it continues to happen reliably on every change after the problem is first observed.
> In most cases all changes were executed from the same seed node.  It also happens when
executed from non-seed nodes though.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message