4
csuser@lovelyserver01:~$ cqlsh --cql3 lovelyserver01
Connected to Lovely Cluster at lovelyserver01:9160.
[cqlsh 2.2.0 | Cassandra 1.1.1 | CQL spec 3.0.0 | Thrift protocol 19.32.0]
Use HELP for help.
cqlsh> CREATE KEYSPACE bigdata WITH strategy_class = 'SimpleStrategy' AND strategy_options:replication_factor=3;
cqlsh> USE bigdata;
cqlsh:bigdata> CREATE COLUMNFAMILY results (client_id int, hierarchy_id int, units int, measures int, PRIMARY KEY (client_id, hierarchy_id));

insert a few rows, anywhere from 5 to 5000 rows - nothing crazy. Then I realize I need to adjust the column family layout and reinsert all the data so I:

cqlsh:bigdata> DROP COLUMNFAMILY results;

This does nothing, no error, the column family still exists and I can still select data from that column family. I do it a few more times and then it seems to work.

Then when I try and recreate the column family, every time I get "TSocket read 0 bytes" and the cqlsh session becomes useless. If I delete the cassandra data directory on all nodes then I can recreate the keyspace and restart. Naturally this has made development rather slow going.

I have tried this on a cluster of 5 older laptops as well as 10 AWS EC2 instances.

Initial tokens for each node is twice the value of the previous. The seed for each node is set up to be the first node. Commitlog is on the same device. I am using the hostname for the listen_address and rpc_address.

Anyone know what the issue may be?

Kevin Branigan
  • 223
  • 3
  • 10
  • editing cassandra/conf/log4j-server.properties and setting log4j.appender.R.File to something it could actually access may have fixed the issue. (testing further) – Kevin Branigan Jun 13 '12 at 15:43
  • So, that definitely did not resolve the issue. What I'm finding now, is that the CF seems to drop sometimes, but when I recreate it, cassandra system.log reports MarshalException on fields that _used_ to be in the CF. (but are not in the new create column family command) and cqlsh errors with "TSocket read 0 bytes" – Kevin Branigan Jul 03 '12 at 14:51
  • https://issues.apache.org/jira/browse/CASSANDRA-44 – Kevin Branigan Jul 03 '12 at 19:43
  • this might be it, I'm using 1.1.1 https://issues.apache.org/jira/browse/CASSANDRA-4307 – Kevin Branigan Jul 04 '12 at 19:04
  • have same issue with 1.1.2. I am on single node cluster – Nick Jul 10 '12 at 18:01
  • Same issue for me. Single node, v1.1.0 on Ubuntu 12.04. I issue the command 'drop column family messages;'. The results in a note that 'schemas agree across the cluster'. But the column family is still there. – pedorro Jul 12 '12 at 19:48
  • I have encountered this issue as well, and fixed it as described here: http://stackoverflow.com/questions/22982954/drop-column-family-from-cassandra-cli-will-not-drop-the-cf/22993780#22993780 – Aaron May 13 '14 at 13:47

2 Answers2

3

A combination of:

  • updating to cassandra 1.1.2 (from 1.1.1)
  • installing NTP on all nodes
  • upgrading the file system to ext4 (from ext3)

has fixed this issue.

Kevin Branigan
  • 223
  • 3
  • 10
0

Seems like editing that file 'log4j-server.properties' did not fix the issue.

I have to delete the data on all machines to recreate a column family. This is highly annoying.

Kevin Branigan
  • 223
  • 3
  • 10