[jira] [Commented] (CASSANDRA-8818) Creating keyspace then table fails with non-prepared query
[
https://issues.apache.org/jira/browse/CASSANDRA-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14325708#comment-14325708
]
Sylvain Lebresne commented on CASSANDRA-8818:
-
What happens is that you should wait for schema propagation (of the keyspace)
before issuing the table creation. Now, while it's possible to do that
manually, the theory is that your driver should handle that and so I suspect
the C# driver either don't do that, or doesn't do it properly (the fact it
works with cqlsh supports the theory that it's not a C* problem; the fact that
it works if you use prepared statements is likely just due to the fact that the
time it takes to prepare the statement is enough for the schema to propagate).
You'll want to check that with the C# driver authors (see the getting help
section of https://github.com/datastax/csharp-driver) as drivers are separate
from the Apache Cassandra project and thus not tracked here.
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)
[jira] [Commented] (CASSANDRA-8818) Creating keyspace then table fails with non-prepared query
[
https://issues.apache.org/jira/browse/CASSANDRA-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14326266#comment-14326266
]
Jonathan New commented on CASSANDRA-8818:
-
Thanks for the explanation! I'll file it with the csharp-driver authors. Sorry,
I didn't originally realize it was tracked separately.
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)
[jira] [Commented] (CASSANDRA-8818) Creating keyspace then table fails with non-prepared query
[
https://issues.apache.org/jira/browse/CASSANDRA-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14325325#comment-14325325
]
Aleksey Yeschenko commented on CASSANDRA-8818:
--
Nope, CL.ALL does not affect schema propagation and synchronisation.
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)
[jira] [Commented] (CASSANDRA-8818) Creating keyspace then table fails with non-prepared query
[
https://issues.apache.org/jira/browse/CASSANDRA-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14325307#comment-14325307
]
Sotirios Delimanolis commented on CASSANDRA-8818:
-
Shouldn't the ConsistencyLevel of All account for that?
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)
[jira] [Commented] (CASSANDRA-8818) Creating keyspace then table fails with non-prepared query
[
https://issues.apache.org/jira/browse/CASSANDRA-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14325287#comment-14325287
]
Philip Thompson commented on CASSANDRA-8818:
What Cassandra version are you using? I assume what is happening is that the
keyspace creation hasn't finished propagating to all nodes before the table
create statement gets there. I believe blocking is the driver's responsibility.
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)
[jira] [Commented] (CASSANDRA-8818) Creating keyspace then table fails with non-prepared query
[
https://issues.apache.org/jira/browse/CASSANDRA-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14325469#comment-14325469
]
Jonathan New commented on CASSANDRA-8818:
-
Cassandra 2.0.12. Is this the right place to file this bug?
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)
