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 E6E1810EB0 for ; Thu, 19 Sep 2013 14:01:07 +0000 (UTC) Received: (qmail 47209 invoked by uid 500); 19 Sep 2013 14:01:03 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 46895 invoked by uid 500); 19 Sep 2013 14:01:02 -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 46867 invoked by uid 99); 19 Sep 2013 14:01:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Sep 2013 14:01:01 +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 (nike.apache.org: domain of petter.von.dolwitz@gmail.com designates 209.85.212.48 as permitted sender) Received: from [209.85.212.48] (HELO mail-vb0-f48.google.com) (209.85.212.48) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Sep 2013 14:00:55 +0000 Received: by mail-vb0-f48.google.com with SMTP id w16so6317281vbf.7 for ; Thu, 19 Sep 2013 07:00:34 -0700 (PDT) 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=2TfZF8fWCiMEHiFnqBLCW6Szerby6fdysHl204ku+hQ=; b=UPWBLdkda22OckN2/Sh44I0xM4hGUdkacxpy9UrG91gm7mNBIjpDY5cg3EK9o0NvLV mVaZyQ6rFSVW7NbVwybdwdRDrhB4vo9SdP4EHw9fxJlqvSaMJadbaThTK1s9E7oY5UoC SrzZnRuEdcIrDCc3S2EehmUsg7xOZo5YqUlcPzNy3+25Mal4bIYMjcnW0epCRTKB9CCx ZbWEb3TLwBIf/JiUsilzCq1X2zc8A9W3vYE/KT3cnal4FQ1kwEpKKEOCepESMVSjos0t +RmPBRrsotT8QRqJU/WtP+zhxqCu2G9cOIe/4fhp3OHZsTegAMvBK+OAZfxfTA+5shcQ nRFQ== MIME-Version: 1.0 X-Received: by 10.221.64.17 with SMTP id xg17mr1329430vcb.5.1379599234302; Thu, 19 Sep 2013 07:00:34 -0700 (PDT) Received: by 10.221.44.8 with HTTP; Thu, 19 Sep 2013 07:00:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Sep 2013 16:00:34 +0200 Message-ID: Subject: Re: Cannot get secondary indexes on fields in compound primary key to work (Cassandra 2.0.0) From: "Petter von Dolwitz (Hem)" To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001a1133158e4b3af804e6bcfa33 X-Virus-Checked: Checked by ClamAV on apache.org --001a1133158e4b3af804e6bcfa33 Content-Type: text/plain; charset=ISO-8859-1 For the record: https://issues.apache.org/jira/browse/CASSANDRA-5975 (2.0.1) resolved this issue for me. 2013/9/8 Petter von Dolwitz (Hem) > Thank you for you reply. > > I will look into this. I cannot not get my head around why the scenario I > am describing does not work though. Should I report an issue around this or > is this expected behaviour? A similar setup is described on this blog post > by the development lead. > > http://www.datastax.com/dev/blog/cql3-for-cassandra-experts > > > > > 2013/9/6 Robert Coli > >> On Fri, Sep 6, 2013 at 6:18 AM, Petter von Dolwitz (Hem) < >> petter.von.dolwitz@gmail.com> wrote: >> >>> I am struggling with getting secondary indexes to work. I have created >>> secondary indexes on some fields that are part of the compound primary key >>> but only one of the indexes seems to work (the one set on the field 'e' on >>> the table definition below). Using any other secondary index in a where >>> clause causes the message "Request did not complete within rpc_timeout.". >>> It seems like if a put a value in the where clause that does not exist in a >>> column with secondary index then cassandra quickly return with the result >>> (0 rows) but if a put in a value that do exist I get a timeout. There is no >>> exception in the logs in connection with this. I've tried to increase the >>> timeout to a minute but it does not help. >>> >> >> In general unless you absolutely need the atomicity of the update of a >> secondary index with the underlying storage row, you are better off making >> a manual secondary index column family. >> >> =Rob >> > > --001a1133158e4b3af804e6bcfa33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For the record:

https://issues.apache.org/jira/browse/CASSAND= RA-5975 (2.0.1) resolved this issue for me.






2013/9/8 Petter von Dolwitz (Hem) <petter.von.dolwitz@gmail.com>
Thank you for you reply.

I will look in= to this. I cannot not get my head around why the scenario I am describing d= oes not work though. Should I report an issue around this or is this expect= ed behaviour? A similar setup is described on this blog post by the develop= ment lead.




2013/9/6 Robert Coli <rcoli@eventbrite.com>
On Fri, Sep 6, 2013 at 6:18 AM, Petter von Dolwitz (H= em) <petter.von.dolwitz@gmail.com> wrote:
I am struggling with getting secondary indexes to work. I have created seco= ndary indexes on some fields that are part of the compound primary key but = only one of the indexes seems to work (the one set on the field 'e'= on the table definition below). Using any other secondary index in a where= clause causes the message "Request did not complete within rpc_timeou= t.". It seems like if a put a value in the where clause that does not = exist in a column with secondary index then cassandra quickly return with t= he result (0 rows) but if a put in a value that do exist I get a timeout. T= here is no exception in the logs in connection with this. I've tried to= increase the timeout to a minute but it does not help.

In general unless you ab= solutely need the atomicity of the update of a secondary index with the und= erlying storage row, you are better off making a manual secondary index col= umn family.

=3DRob=A0


--001a1133158e4b3af804e6bcfa33--