cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan McGuire (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-6519) cqlsh hangs indefinitely when dropping table
Date Wed, 30 Apr 2014 00:57:32 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-6519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ryan McGuire updated CASSANDRA-6519:
------------------------------------

    Labels: qa-resolved  (was: )

> cqlsh hangs indefinitely when dropping table
> --------------------------------------------
>
>                 Key: CASSANDRA-6519
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6519
>             Project: Cassandra
>          Issue Type: Bug
>          Components: API
>         Environment: C* from trunk -- cassandra-2.0.3-709-g486f079
> java 1.7.0_45 (on linux 64 bit)
> [cqlsh 4.1.0 | Cassandra 2.1-SNAPSHOT | CQL spec 3.1.1 | Thrift protocol 19.39.0]
> 3 node cluster built on my machine using ccm
>            Reporter: Russ Hatch
>            Assignee: Russ Hatch
>              Labels: qa-resolved
>
> Using ccqlsh, I issue a drop statement for a table and it hangs indefinitely (running
cassandra-2.0.3-709-g486f079 from trunk).
> Here's the statement:
> cqlsh:taskapp> drop table user_task;
> Here's the full setup I used:
> {noformat}
> ccm create test_cluster
> ccm populate -n 3
> ccm start
> ccm node1 cqlsh
> CREATE KEYSPACE taskapp WITH replication = {
>   'class': 'SimpleStrategy',
>   'replication_factor': '3'
> };
> use taskapp;
> create table user (
>     user_id timeuuid PRIMARY KEY,
>     first_name text,
>     last_name text,
>     email text
> );
> create table user_task (
>     task_id timeuuid PRIMARY KEY,
>     user_id timeuuid,
>     task_order int,
>     task_description text,
>     is_complete boolean,
>     is_top_level boolean,
>     subtask_ids list<timeuuid>
> );
> {noformat}
> and then the statement which hangs:
> drop table user_task;
> I also checked that all 3 nodes have the same schema version uuid, using these queries
someone shared with me:
> {noformat}
> cqlsh:taskapp> SELECT rpc_address, schema_version FROM system.peers
>            ... ;
>  rpc_address | schema_version
> -------------+--------------------------------------
>    127.0.0.3 | 6e782241-91e9-3cfa-88c0-88f445a573c1
>    127.0.0.2 | 6e782241-91e9-3cfa-88c0-88f445a573c1
> (2 rows)
> cqlsh:taskapp> SELECT schema_version FROM system.local WHERE key='local';
>  schema_version
> --------------------------------------
>  6e782241-91e9-3cfa-88c0-88f445a573c1
> (1 rows)
> {noformat}
> I checked the logs for all 3 nodes, which I think were normal. Node1 (used in the cqlsh
session) showed this message:
> {noformat}
> INFO  [Thrift:3] 2013-12-20 14:29:23,200 MigrationManager.java:289 - Drop ColumnFamily
'taskapp/user_task'
> {noformat}
> The other node logs showed no activity that looked related to the attempted drop statement.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message