Jonathan New created CASSANDRA-8818: ---------------------------------------
Summary: Creating keyspace then table fails with non-prepared query Key: CASSANDRA-8818 URL: https://issues.apache.org/jira/browse/CASSANDRA-8818 Project: Cassandra Issue Type: Bug Components: Drivers (now out of tree) Reporter: Jonathan New Hi, I'm not sure if this is a driver or cassandra issue, so please feel free to move to the appropriate component. I'm using C# on mono (linux), and the 2.5.0 cassandra driver for C#. We have a cluster of 3 nodes, and we noticed that when we created a keyspace, then a table for that keyspace in quick succession it would fail frequently. I put our approximate code below. Additionally, we noticed that if we did a prepared statement instead of just executing the query, it would succeed. It also appeared that running the queries from a .cql file (outside of our C# program) would succeed as well. Please let me know if you need additional details. Thanks! {noformat} var pooling = new PoolingOptions () .SetMaxConnectionsPerHost (HostDistance.Remote, 24) .SetHeartBeatInterval (1000); var queryOptions = new QueryOptions () .SetConsistencyLevel(ConsistencyLevel.ALL); var builder = Cluster.Builder () .AddContactPoints (contactPoints) .WithPort (9042) .WithPoolingOptions (pooling) .WithQueryOptions (queryOptions) .WithQueryTimeout (15000); String keyspaceQuery = "CREATE KEYSPACE IF NOT EXISTS metadata WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '3'} AND durable_writes = true;"; String tableQuery = "CREATE TABLE IF NOT EXISTS metadata.patch_history ( metadata_key text, patch_version int, applied_date timestamp, patch_file text, PRIMARY KEY (metadata_key, patch_version) ) WITH CLUSTERING ORDER BY (patch_version DESC) AND bloom_filter_fp_chance = 0.01 AND caching = 'KEYS_ONLY' AND comment = '' AND compaction = {'min_threshold': '4', 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32'} AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'} AND dclocal_read_repair_chance = 0.1 AND default_time_to_live = 0 AND gc_grace_seconds = 864000 AND memtable_flush_period_in_ms = 0 AND read_repair_chance = 0.0 AND speculative_retry = '99.0PERCENTILE';"; using (var session = cluster.Connect ()) { session.Execute(keyspaceQuery); session.Execute(tableQuery); } {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)