[ https://issues.apache.org/jira/browse/CASSANDRA-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan New updated CASSANDRA-8818: ------------------------------------ Description: 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. In this case with tracing on, we saw that it was "Preparing statement". 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} was: 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} > 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. > In this case with tracing on, we saw that it was "Preparing statement". > 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)