Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 18 Feb 2015 02:21:11 +0000 (UTC)
From: "Aleksey Yeschenko (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12775784.1424220757000.71179.1424226071836@Atlassian.JIRA>
In-Reply-To: <JIRA.12775784.1424220757000@Atlassian.JIRA>
References: <JIRA.12775784.1424220757000@Atlassian.JIRA>
 <JIRA.12775784.1424220757501@arcas>
Subject: [jira] [Commented] (CASSANDRA-8818) Creating keyspace then table
 fails with non-prepared query
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)