Re: best practice for waiting for schema changes to propagate
The system.peers table which is a copy of some gossip info the node has stored, including the schema version. You should query this and wait until all schema versions have converged. http://www.datastax.com/documentation/cql/3.0/cql/cql_using/use_sys_tab_cluster_t.html http://www.datastax.com/dev/blog/the-data-dictionary-in-cassandra-1-2 As ensuring that the driver keeps talking to the node you made the schema change on I would ask the drivers specific mailing list / IRC: - MAILING LIST: https://groups.google.com/a/lists.datastax.com/forum/#!forum/java-driver-user - IRC: #datastax-drivers on irc.freenode.net http://freenode.net/ On 30 September 2014 10:16, Clint Kelly clint.ke...@gmail.com wrote: Hi all, I often have problems with code that I write that uses the DataStax Java driver to create / modify a keyspace or table and then soon after reads the metadata for the keyspace to verify that whatever changes I made the keyspace or table are complete. As an example, I may create a table called `myTableName` and then very soon after do something like: assert(session .getCluster() .getMetaData() .getKeyspace(myKeyspaceName) .getTable(myTableName) != null) I assume this fails sometimes because the default round-robin load balancing policy for the Java driver will send my create-table request to one node and the metadata read to another, and because it takes some time for the table creation to propagate across all of the nodes in my cluster. What is the best way to deal with this problem? Is there a standard way to wait for schema changes to propagate? Best regards, Clint -- Ben Bromhead Instaclustr | www.instaclustr.com | @instaclustr http://twitter.com/instaclustr | +61 415 936 359
Re: best practice for waiting for schema changes to propagate
Also be aware of https://issues.apache.org/jira/browse/CASSANDRA-7734 if you are using C* 2.0.6+ (2.0.6 introduced a change that can sometimes causes initial schema propagation not to happen, introducing potentially long delays until some other code path repairs it later) On Sep 30, 2014, at 1:54 AM, Ben Bromhead b...@instaclustr.com wrote: The system.peers table which is a copy of some gossip info the node has stored, including the schema version. You should query this and wait until all schema versions have converged. http://www.datastax.com/documentation/cql/3.0/cql/cql_using/use_sys_tab_cluster_t.html http://www.datastax.com/dev/blog/the-data-dictionary-in-cassandra-1-2 As ensuring that the driver keeps talking to the node you made the schema change on I would ask the drivers specific mailing list / IRC: MAILING LIST: https://groups.google.com/a/lists.datastax.com/forum/#!forum/java-driver-user IRC: #datastax-drivers on irc.freenode.net On 30 September 2014 10:16, Clint Kelly clint.ke...@gmail.com wrote: Hi all, I often have problems with code that I write that uses the DataStax Java driver to create / modify a keyspace or table and then soon after reads the metadata for the keyspace to verify that whatever changes I made the keyspace or table are complete. As an example, I may create a table called `myTableName` and then very soon after do something like: assert(session .getCluster() .getMetaData() .getKeyspace(myKeyspaceName) .getTable(myTableName) != null) I assume this fails sometimes because the default round-robin load balancing policy for the Java driver will send my create-table request to one node and the metadata read to another, and because it takes some time for the table creation to propagate across all of the nodes in my cluster. What is the best way to deal with this problem? Is there a standard way to wait for schema changes to propagate? Best regards, Clint -- Ben Bromhead Instaclustr | www.instaclustr.com | @instaclustr | +61 415 936 359 smime.p7s Description: S/MIME cryptographic signature
best practice for waiting for schema changes to propagate
Hi all, I often have problems with code that I write that uses the DataStax Java driver to create / modify a keyspace or table and then soon after reads the metadata for the keyspace to verify that whatever changes I made the keyspace or table are complete. As an example, I may create a table called `myTableName` and then very soon after do something like: assert(session .getCluster() .getMetaData() .getKeyspace(myKeyspaceName) .getTable(myTableName) != null) I assume this fails sometimes because the default round-robin load balancing policy for the Java driver will send my create-table request to one node and the metadata read to another, and because it takes some time for the table creation to propagate across all of the nodes in my cluster. What is the best way to deal with this problem? Is there a standard way to wait for schema changes to propagate? Best regards, Clint
