Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 39D31E295 for ; Sun, 13 Jan 2013 16:59:38 +0000 (UTC) Received: (qmail 73022 invoked by uid 500); 13 Jan 2013 16:59:35 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 72995 invoked by uid 500); 13 Jan 2013 16:59:35 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 72986 invoked by uid 99); 13 Jan 2013 16:59:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Jan 2013 16:59:35 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of shsedghi@gmail.com designates 209.85.210.182 as permitted sender) Received: from [209.85.210.182] (HELO mail-ia0-f182.google.com) (209.85.210.182) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Jan 2013 16:59:28 +0000 Received: by mail-ia0-f182.google.com with SMTP id x2so2931472iad.41 for ; Sun, 13 Jan 2013 08:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=0JWIgImsDIOOHOETCjJB3eiW3KNnrUXz866QjKJ+DBE=; b=E4Z09YcCRlHa96YncabX35OOFEUe34e1kzo/T+3DsCqR2VqbIWcpbVJsZPu2j52i+P EOZXlYgsq5ZNoPyl7GHvsXwGzQ4ziuTYLHie1lP5IT6rIQPzNO1L4o0oLfGOCdZyr6zD 4JXJWLoAIw6fhpnMAXE03gtdc6OfxoB5MtOfnJySnU0mDOGDkW1Q5v8nLh5AKz6GtX1H UKggkLOsFdDfAyGyN6NTy7v53TRCR5R+qZDrXcTozTs+lN3a9KfZLjzrxB326Bbb+rqA xHtGc3oLBkLcvRSR8JsYm+IBKrsZfRh7vXyzoms35phu4XcBxdCmypBhneIENJO48yek ICQg== MIME-Version: 1.0 Received: by 10.42.54.12 with SMTP id p12mr61386679icg.23.1358096348430; Sun, 13 Jan 2013 08:59:08 -0800 (PST) Received: by 10.64.34.231 with HTTP; Sun, 13 Jan 2013 08:59:08 -0800 (PST) In-Reply-To: References: Date: Sun, 13 Jan 2013 11:59:08 -0500 Message-ID: Subject: Re: Cassandra 1.2 Thrift and CQL 3 issue From: Shahryar Sedghi To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=90e6ba3fd9176b3fe904d32e7215 X-Virus-Checked: Checked by ClamAV on apache.org --90e6ba3fd9176b3fe904d32e7215 Content-Type: text/plain; charset=ISO-8859-1 I finally realized that Thrift API has changed from 1.1 to 1.2 and my code and modified JDBC driver works well except I get an exception on the system log when I close the connection. Looks like it is an old issue reappearing. I have evaluated new Java driver, it is easier and more practical than JDBC for Cassandra and I will eventually move there, but I need to fix this first. Thrift API has new prepare_cql3_query and client.execute_prepared_cql3_query, which I expected even if it exists due to changes on the server side to be private and client.set_cql_version("3.0.0") should take care of the differences. So the remaining question is: Since new cql3 methods require ConsistencyLevel.xxx, is consistency level at the query has precedence over this level at the api or not. The answer to this question is important for general purpose framework code like JDBC driver that hides these difference. Thanks in advance Shahryar On Sat, Jan 12, 2013 at 1:39 PM, Shahryar Sedghi wrote: > Thanks Brian > > it is not the same issue, and stack trace is different. It is a simple > test case and I have 3 columns and I populate all of them with: > cqlsh:somedb> CREATE TABLE test(interval int,id text, body text, primary > key (interval, id)); > cqlsh:somedb> insert into test (interval, id, body) values(3, 'key3', > 'body3'); > cqlsh:somedb> insert into test (interval, id, body) values(1, 'key1', > 'body1'); > cqlsh:somedb> insert into test (interval, id, body) values(2, 'key2', > 'body2'); > > as you see in your case it was explicitly dealing with CQL3 on the > Cassandra side. I think in my case it is not recognizing it as CQL3. > > *at > org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(Cassandra.java:4062) > * > > at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32) > at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34) > at > org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:199) > > as in my case it does not get to the same class > > > *at > org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:4036) > * > at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32) > at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34) > at > org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:199) > > > I am doing something wrong on client side that Cassandra thinks it is > CQL2 (aka. cql). How do you tell thrift it is CQL 3? > > Thanks > > > On Sat, Jan 12, 2013 at 12:48 PM, Shahryar Sedghi wrote: > >> Hi >> >> I am trying to test my application that runs with JDBC, CQL 3 with >> Cassandra 1.2. After getting many weird errors and downgrading from JDBC to >> thrift, I realized the thrift on Cassandra 1.2 has issues with wide rows. >> If I define the table as: >> >> CREATE TABLE test(interval int,id text, body text, primary key >> (interval, id)); >> >> select interval, id, body from test; >> >> fails with: >> >> ERROR [Thrift:16] 2013-01-11 18:23:35,997 CustomTThreadPoolServer.java >> (line 217) Error occurred during processing of message. >> java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 1 >> at >> org.apache.cassandra.config.CFMetaData.getColumnDefinitionFromColumnName(CFMetaData.java:923) >> at >> org.apache.cassandra.cql.QueryProcessor.processStatement(QueryProcessor.java:502) >> at >> org.apache.cassandra.cql.QueryProcessor.process(QueryProcessor.java:789) >> at >> org.apache.cassandra.thrift.CassandraServer.execute_cql_query(CassandraServer.java:1652) >> at >> org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:4048) >> at >> org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:4036) >> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32) >> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34) >> at >> org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:199) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614) >> at java.lang.Thread.run(Thread.java:780) >> >> Same code works well with Cassandra 1.1. >> >> At the same time, if I define the table as: >> CREATE TABLE test1(interval int,id text, body text, primary key >> (interval)); >> >> everything works fine. I am using >> >> DataStax Community 1.2 >> >> apache-cassandra-clientutil-1.2.0.jar >> apache-cassandra-thrift-1.2.0.jar >> libthrift-0.7.0.jar >> >> Apparently client.set_cql_version("3.0.0"); has no effect either. Is >> there a setting that I miss on the client side to dictate cql3 or it is a >> bug? >> >> Thanks in advance >> >> Shahryar >> >> -- >> "Life is what happens while you are making other plans." ~ John Lennon >> > > > > -- > "Life is what happens while you are making other plans." ~ John Lennon > -- "Life is what happens while you are making other plans." ~ John Lennon --90e6ba3fd9176b3fe904d32e7215 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I finally realized=A0 that Thrift API = has changed from 1.1 to 1.2 and my code and modified JDBC driver works well= except I get an exception on the system log when I close the connection. L= ooks like it is an old issue reappearing. I have evaluated new Java driver,= it is easier and more practical than JDBC for Cassandra and I will eventua= lly move there, but I need to fix this first.

Thrift API has new=A0 prepare_cql3_query and client.execute_prepared_cq= l3_query, which I expected even if it exists due to changes on the server s= ide to be private and client.set_cql_version("3.0.0") should take= care of the differences.

So the remaining question is:

Since new cql3 methods= require ConsistencyLevel.xxx, is consistency level at the query has preced= ence over this level at the api or not. The answer to this question is impo= rtant for general purpose framework code like JDBC driver that hides these = difference.

Thanks in advance

Shahryar


On Sat, Jan 12, 2013 at 1:39 = PM, Shahryar Sedghi <shsedghi@gmail.com> wrote:
Thanks Brian

it= is not the same issue, and stack trace is different. It is a simple test c= ase and I have 3 columns and I populate all of them with:
cqlsh:somedb> CREATE TABLE=A0 test(interval int,id text, body text, prim= ary key (interval, id));
cqlsh:somedb> insert into test (interval, id, body) values(3, 'key3&= #39;, 'body3');
cqlsh:somedb> insert into test (interval, id,= body) values(1, 'key1', 'body1');
cqlsh:somedb> inse= rt into test (interval, id, body) values(2, 'key2', 'body2'= );

as you see in your case it was explicitly dealing with CQL3 on th= e Cassandra side. I think in my case it is not recognizing it as CQL3.
<= div>
at org.apache.cassandra.thrift.Cassa= ndra$Processor$execute_cql3_query.getResult(Cassandra.java:4062)=

at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(C= ustomTThreadPoolServer.java:199)

as in my case it d= oes not get=A0 to the same class


=A0=A0=A0 at org.apache.cassandra.thrift.Cassandra$Pro= cessor$execute_cql_query.getResult(Cassandra.java:4036)
=A0=A0=A0 at org.apache.thrift.ProcessFunction.process(ProcessFunction= .java:32)
=A0=A0=A0 at org.apache.thrift.TBaseProcessor.process(TBasePro= cessor.java:34)
=A0=A0=A0 at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProc= ess.run(CustomTThreadPoolServer.java:199)


I a= m doing something wrong on client side that Cassandra thinks it is=A0 CQL2 = (aka. cql). How do you tell thrift it is CQL 3?

Thanks


On Sat, Jan= 12, 2013 at 12:48 PM, Shahryar Sedghi <shsedghi@gmail.com>= wrote:
Hi
<= br>
I am trying to test my application that runs with JDBC, CQL 3 with= Cassandra 1.2. After getting many weird errors and downgrading from JDBC t= o thrift, I realized the thrift on Cassandra 1.2 has issues with wide rows.= If I define the table as:

CREATE TABLE=A0 test(interval int,id text, body text, primary key (inte= rval, id));

select interval, id, body from test;

=A0fails wit= h:

ERROR [Thrift:16] 2013-01-11 18:23:35,997 CustomTThreadPoolServer= .java (line 217) Error occurred during processing of message.
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 1
= =A0=A0=A0 at org.apache.cassandra.config.CFMetaData.getColumnDefinitionFrom= ColumnName(CFMetaData.java:923)
=A0=A0=A0 at org.apache.cassandra.cql.Qu= eryProcessor.processStatement(QueryProcessor.java:502)
=A0=A0=A0 at org.apache.cassandra.cql.QueryProcessor.process(QueryProcessor= .java:789)
=A0=A0=A0 at org.apache.cassandra.thrift.CassandraServer.exec= ute_cql_query(CassandraServer.java:1652)
=A0=A0=A0 at org.apache.cassand= ra.thrift.Cassandra$Processor$execute_cql_query.getResult(Cassandra.java:40= 48)
=A0=A0=A0 at org.apache.cassandra.thrift.Cassandra$Processor$execute_cql_qu= ery.getResult(Cassandra.java:4036)
=A0=A0=A0 at org.apache.thrift.Proces= sFunction.process(ProcessFunction.java:32)
=A0=A0=A0 at org.apache.thrif= t.TBaseProcessor.process(TBaseProcessor.java:34)
=A0=A0=A0 at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProc= ess.run(CustomTThreadPoolServer.java:199)
=A0=A0=A0 at java.util.concurr= ent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
=A0=A0=A0= at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j= ava:614)
=A0=A0=A0 at java.lang.Thread.run(Thread.java:780)

Same code w= orks well with Cassandra 1.1.

At the same time, if I define the tab= le as:
CREATE TABLE=A0 test1(interval int,id text, body text, primary ke= y (interval));

everything works fine. I am using

DataStax Communit= y 1.2

apache-cassandra-clientutil-1.2.0.jar
apache-cassandra= -thrift-1.2.0.jar
libthrift-0.7.0.jar

Apparently clien= t.set_cql_version("3.0.0"); has no effect either. Is there a sett= ing that I miss on the client side to dictate cql3 or it is a bug?

Thanks in advance
Shahryar

--
"Life is what happens while you are making other plans." ~ John L= ennon



--
"Life is what happ= ens while you are making other plans." ~ John Lennon



--
"Life = is what happens while you are making other plans." ~ John Lennon --90e6ba3fd9176b3fe904d32e7215--