cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David B (JIRA)" <>
Subject [jira] [Created] (CASSANDRA-4356) Drop column family fail in Cassandra 1.1.1
Date Tue, 19 Jun 2012 22:15:43 GMT
David B created CASSANDRA-4356:

             Summary: Drop column family fail in Cassandra 1.1.1
                 Key: CASSANDRA-4356
             Project: Cassandra
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.1.1
         Environment: 2-node cluster running on Ubuntu 10.10
            Reporter: David B

2-node v1.1.1 cluster.  Attempts to drop column families appears to succeed, but fails behind
the scenes.  More specifically, the column family is deleted as follows:

cassandra-cli -h HOST_1
> use MyKeyspace
> drop column family MyColumnFamily
Waiting for schema agreement...
... schemas agree across the cluster

Data files in fact have been deleted on HOST_1.  However, the files on HOST_2 still exist
in the /data directory.  Also, the following stack trace appears in /var/log/system.log:

ERROR [MigrationStage:1] 2012-06-19 22:05:56,172 (line 134) Exception
in thread Thread[MigrationStage:1,5,main]
org.apache.cassandra.cql.jdbc.MarshalException: invalid UTF8 bytes 4fe0f7c7
        at org.apache.cassandra.cql.jdbc.JdbcUTF8.getString(
        at org.apache.cassandra.cql.jdbc.JdbcUTF8.compose(
        at org.apache.cassandra.db.marshal.UTF8Type.compose(
        at org.apache.cassandra.cql3.UntypedResultSet$Row.getString(
        at org.apache.cassandra.config.CFMetaData.fromSchemaNoColumns(
        at org.apache.cassandra.config.CFMetaData.fromSchema(
        at org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(
        at org.apache.cassandra.db.DefsTable.mergeColumnFamilies(
        at org.apache.cassandra.db.DefsTable.mergeSchema(
        at org.apache.cassandra.db.DefsTable.mergeRemoteSchema(
        at org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(
        at java.util.concurrent.Executors$
        at java.util.concurrent.FutureTask$Sync.innerRun(
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
        at java.util.concurrent.ThreadPoolExecutor$

>From this point on, all other Migration commands (e.g. creating new column families) similarly
report no errors, but fail behind the scenes.  Recovering from the erroneous state requires
a cluster restart.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message