[CASSANDRA-4322] Error in CLI when updating keyspace

• Type: Bug
• Status: Resolved
• Priority: Low
• Resolution: Fixed
• Fix Version/s: 1.1.6
• Severity: Low
• Assignee: Pavel Yaskevich
• Reporter: Richard Low

Authors

Pavel Yaskevich

Reviewers

Dave Brosius

• Created: 08/Jun/12 16:03
• Updated: 16/Apr/19 09:32
• Resolved: 11/Sep/12 11:18

Description

To repro:

1. Open the cli
2. Create a keyspace:
create keyspace ks1 with placement_strategy = SimpleStrategy and strategy_options =

{replication_factor:1}

;
3. Update the keyspace:
update keyspace ks1 with strategy_options =

{replication_factor:3}

;

The output is:

[default@unknown] create keyspace ks1 with placement_strategy = SimpleStrategy and strategy_options =

{replication_factor:1}

;
8ecd5e16-e0f7-37e7-850e-38ee1a3a510e
Waiting for schema agreement...
... schemas agree across the cluster
[default@unknown] update keyspace ks1 with strategy_options =

{replication_factor:3}

;
857af387-6677-3e39-bdf6-e1132673c25b
Waiting for schema agreement...
... schemas agree across the cluster
org.apache.thrift.protocol.TProtocolException: Required field 'keyspace' was not present! Struct: describe_keyspace_args(keyspace:null)
[default@unknown]

The problem is that the patch in CASSANDRA-4052 assumes the CLI is authenticated to a working keyspace. getKSMetaData in executeUpdateKeySpace is called with keySpace, which is null.

Changing this to keyspaceName partially solves it, we now get:

[default@unknown] update keyspace ks1 with strategy_options =

{replication_factor:3}

;
Not authenticated to a working keyspace.
18d750fc-19d9-30f0-b8b9-18b2e4a0a0d4
Waiting for schema agreement...
... schemas agree across the cluster
Not authenticated to a working keyspace.

This comes from replayAssumptions in getKSMetaData.

It seems that the refresh code needs to be reworked slightly to not assume the CLI is authenticated to a keyspace.