cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David B (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4356) Drop column family fail in Cassandra 1.1.1
Date Wed, 20 Jun 2012 01:18:44 GMT


David B commented on CASSANDRA-4356:

I'm saying that I had to run a different test on the same cluster.  In order to continue with
my work, I had already deleted the data files from the cluster and restarted the cluster,
before I saw your request to get the schema_columnfamily information.

As per my previous comment, I can reproduce at any point now.  Essentially every migration
causes the issue.  If I try to create a column family, I encounter the same.  I need to reboot
the offending node before the column family is available, so that I can stream data to it.
 Then the same issue (i.e. 'invalid UTF Bytes...') occurs if I try to drop the column family.
 Rinse and repeat.

If the above isn't helpful, I can try to completely wipe the 2 nodes (i.e. clearing all system/commit
logs/data files, etc.) and record my steps to reproduce the issue...
> Drop column family fail in Cassandra 1.1.1
> ------------------------------------------
>                 Key: CASSANDRA-4356
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1.1
>         Environment: 2-node cluster running on Ubuntu 10.10
>            Reporter: David B
>            Assignee: Sylvain Lebresne
> 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
> 79f7ab8c-da08-355c-87a0-8e9630eb4945
> 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 on
> 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
>         at java.util.concurrent.Executors$
>         at java.util.concurrent.FutureTask$Sync.innerRun(
>         at
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
>         at java.util.concurrent.ThreadPoolExecutor$
>         at
> From this point on, all other Migration commands (e.g. creating new column families)
similarly report no errors in cassandra-cli, 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