CREATE INDEX intermittently and silently fails #198

snoopdave opened this Issue Jan 24, 2013 · 6 comments


None yet

4 participants


I'm using Astyanax to create the Column Families and Indexes I need for my application programmatically. I'm using Cassanda 1.1.8 and latest code from Astyanax's Github repo, and I'm configuring Astyanax with setCqlVersion("3.0.0").

My code reads my schema.cql file and uses Astyanax to run each CREATE TABLE and CREATE INDEX command, with code like this:

      "Creating column family {}", name);
                ColumnFamily cf = currentCF = ColumnFamily.newColumnFamily(
                    name, StringSerializer.get(), StringSerializer.get(), StringSerializer.get());

All of my (dozens of) tables get created, but some of the indexes are not created. Each time I run my code, a slightly different set of Indexes are not created.

When I run my update script directly with cqlsh -3, all tables and indexes are created properly, and consistently.

elandau commented Jan 30, 2013

Can you provide the exact statements that you are running or a unit test that reproduces this behavior.

buhe commented Mar 4, 2013

i create table and create index.
CREATE TABLE bookmark (id varchar,user varchar,title varchar,url varchar,createdTime bigint,updatedTime bigint,PRIMARY KEY ( id) );
CREATE INDEX bookmark_user_idx ON bookmark ( user );
CREATE INDEX bookmark_updatedTime_idx ON bookmark ( updatedTime );

sometimes, table not created. sometimes one of indexes not created.
if index not created, don not throw any exception.

buhe commented Mar 4, 2013

I run my code in cluster and standalone.
In standalone, my code work right.

buhe commented Mar 4, 2013

When use thrift api, code work right.

elandau commented Apr 1, 2013

I suspect that the problem here might be that the different commands are being executed on different nodes and that it may take cassandra some time to make sure all the nodes are in sync. Try reading the Host from the first call and reusing it on subsequent calls. That way all 'schema' changes are happening on the same node.

opuneet commented Aug 1, 2013

Agree with suggestion made here, this is probably an artifact of using different node in close succession. Pin to the same host after the first call and this should fix the problem. Closing this out.

@opuneet opuneet closed this Aug 1, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment