Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id BD14E200AF7 for ; Tue, 14 Jun 2016 21:27:21 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id BB9A9160A47; Tue, 14 Jun 2016 19:27:21 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 4385B160A06 for ; Tue, 14 Jun 2016 21:27:20 +0200 (CEST) Received: (qmail 15342 invoked by uid 500); 14 Jun 2016 19:27:18 -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 15332 invoked by uid 99); 14 Jun 2016 19:27:18 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jun 2016 19:27:18 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 4AE7FC028E for ; Tue, 14 Jun 2016 19:27:18 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=2, KAM_HUGEIMGSRC=0.2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx2-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 8F44ph__iZuh for ; Tue, 14 Jun 2016 19:27:15 +0000 (UTC) Received: from mail-vk0-f41.google.com (mail-vk0-f41.google.com [209.85.213.41]) by mx2-lw-us.apache.org (ASF Mail Server at mx2-lw-us.apache.org) with ESMTPS id 86FFB5F253 for ; Tue, 14 Jun 2016 19:27:15 +0000 (UTC) Received: by mail-vk0-f41.google.com with SMTP id j2so68560vkg.2 for ; Tue, 14 Jun 2016 12:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=meGgek4v7m3rFdw+yKXBBuQEx2FK1h5VYX4Zb08gnXc=; b=ayjA3yCN80zvg+9etud0pb9Ux102oFbvuyHqfIZ4VLey+jx8qHvhZkkg/wWLe3J+iL t+WsWcvMpl42SwZOMT9o5l9PnY4HDVXvlPIyviPhcYp/tLgxpFBcPt/l0xUQ/uns0kEN RgImU1Q+S8RCsmTR9KM9qAjqq0D/ANIRlvNj9pztJiJ/Q+N4eVii/4BagHcJ8bwkfUE2 Nqpl7dyIMFVzPGP2yIEqpVDoRRUYBZx9emhv+qpKFbilv/W6Ke9h/TZbizJ+tqUH0JJE FJbhJ6dMzVzlL45yNlJTCu6sFyoHqRGX/95gvzhYAmSjZwdjPOMa0oePJzD+afSFfxOg fbOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=meGgek4v7m3rFdw+yKXBBuQEx2FK1h5VYX4Zb08gnXc=; b=J+9KmmcUdKF5nqodt+4L8qTJdrpxSJwYl3zr02X/6p1zK81jd+HsQIuFIS8uDec9vt jXxK9rwaietPnsUCl0TTC5m6Bzh9WEEs3ZS4Dolz+DBC3DvrzvA9OICK/JNVb83obTT8 7SPMIFZuIwe6LPhaVMtWPvBfgwRSbzrAIPNGeChzWoHz+/BE+YH8OHj2lgC/mQKgEMan 11Bd/WrF4UDz0BjsHO2jJd5EJCYuBajAr82/cNq0FVtCDuELEgdtOYMaRIgUNKedwUVg R2SlzBUFfwO3zuZrX+zgpsvReh/+LGDjbXagwlHfqSFxsAna6QtQlUMG4dHTpWQC0wBL 9+dw== X-Gm-Message-State: ALyK8tJ1bzkirrq3tAuojJd6+QvCVyNuT3qd1RZvFbbNdCOYq5ocfHiUENZV3t2lzZdPshPI6ZlkbD1CljlziA== X-Received: by 10.31.4.79 with SMTP id 76mr9616761vke.75.1465932434836; Tue, 14 Jun 2016 12:27:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.66.66 with HTTP; Tue, 14 Jun 2016 12:27:14 -0700 (PDT) In-Reply-To: References: From: Bhuvan Rawal Date: Wed, 15 Jun 2016 00:57:14 +0530 Message-ID: Subject: Re: select query on entire primary key returning more than one row in result To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001a11429d720b1093053541fec6 archived-at: Tue, 14 Jun 2016 19:27:21 -0000 --001a11429d720b1093053541fec6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have verified this issue to be fixed in 3.6 and 3.7. And the issue mentioned on this thread is fixed as well. On Wed, Jun 15, 2016 at 12:43 AM, Bhuvan Rawal wrote: > Joel, > > If we look at the schema carefully: > > CREATE TABLE test0 ( > pk int, > a int, > b text, > s text static, > PRIMARY KEY (*pk, a)* > ); > > and filtering is performed on clustering column a and its not a static > column: > > select * from test0 where pk=3D0 and a=3D2; > > > > On Wed, Jun 15, 2016 at 12:39 AM, Joel Knighton < > joel.knighton@datastax.com> wrote: > >> It doesn't seem to be an exact duplicate - CASSANDRA-11513 relies on you >> selecting a static column, which you weren't doing in the reported issue= . >> That said, I haven't looked too closely. >> >> On Tue, Jun 14, 2016 at 2:07 PM, Bhuvan Rawal >> wrote: >> >>> I can reproduce CASSANDRA-11513 >>> locally on 3.5, >>> possible duplicate. >>> >>> On Wed, Jun 15, 2016 at 12:29 AM, Joel Knighton < >>> joel.knighton@datastax.com> wrote: >>> >>>> There's some precedent for similar issues with static columns in 3.5 >>>> with https://issues.apache.org/jira/browse/CASSANDRA-11513 - a >>>> deterministic (or somewhat deterministic) path for reproduction would = help >>>> narrow the issue down farther. I've played around locally with similar >>>> schemas (sans the stratio indices) and couldn't reproduce the issue. >>>> >>>> On Tue, Jun 14, 2016 at 1:41 PM, Bhuvan Rawal >>>> wrote: >>>> >>>>> Jira CASSANDRA-12003 >>>>> Has been >>>>> created for the same. >>>>> >>>>> On Tue, Jun 14, 2016 at 11:54 PM, Atul Saroha < >>>>> atul.saroha@snapdeal.com> wrote: >>>>> >>>>>> Hi Tyler, >>>>>> >>>>>> This issue is mainly visible for tables having static columns, still >>>>>> investigating. >>>>>> We will try to test after removing lucene index but I don=E2=80=99t = think >>>>>> this plug-in could led to change in behaviour of cassandra write to = table's >>>>>> memtable. >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------= ------------------------------------------------- >>>>>> Atul Saroha >>>>>> *Lead Software Engineer* >>>>>> *M*: +91 8447784271 *T*: +91 124-415-6069 *EXT*: 12369 >>>>>> Plot # 362, ASF Centre - Tower A, Udyog Vihar, >>>>>> Phase -4, Sector 18, Gurgaon, Haryana 122016, INDIA >>>>>> >>>>>> On Tue, Jun 14, 2016 at 9:54 PM, Tyler Hobbs >>>>>> wrote: >>>>>> >>>>>>> Is 'id' your partition key? I'm not familiar with the stratio >>>>>>> indexes, but it looks like the primary key columns are both indexed= . >>>>>>> Perhaps this is related? >>>>>>> >>>>>>> On Tue, Jun 14, 2016 at 1:25 AM, Atul Saroha < >>>>>>> atul.saroha@snapdeal.com> wrote: >>>>>>> >>>>>>>> After further debug, this issue is found in in-memory memtable as >>>>>>>> doing nodetool flush + compact resolve the issue. And there is no = batch >>>>>>>> write used for this table which is showing issue. >>>>>>>> Table properties: >>>>>>>> >>>>>>>> WITH CLUSTERING ORDER BY (f_name ASC) >>>>>>>>> AND bloom_filter_fp_chance =3D 0.01 >>>>>>>>> AND caching =3D {'keys': 'ALL', 'rows_per_partition': 'NONE'} >>>>>>>>> AND comment =3D '' >>>>>>>>> AND compaction =3D {'class': >>>>>>>>> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'= , >>>>>>>>> 'max_threshold': '32', 'min_threshold': '4'} >>>>>>>>> AND compression =3D {'chunk_length_in_kb': '64', 'class': >>>>>>>>> 'org.apache.cassandra.io.compress.LZ4Compressor'} >>>>>>>>> AND crc_check_chance =3D 1.0 >>>>>>>>> AND dclocal_read_repair_chance =3D 0.1 >>>>>>>>> AND default_time_to_live =3D 0 >>>>>>>>> AND gc_grace_seconds =3D 864000 >>>>>>>>> AND max_index_interval =3D 2048 >>>>>>>>> AND memtable_flush_period_in_ms =3D 0 >>>>>>>>> AND min_index_interval =3D 128 >>>>>>>>> AND read_repair_chance =3D 0.0 >>>>>>>>> AND speculative_retry =3D '99PERCENTILE'; >>>>>>>>> CREATE CUSTOM INDEX nbf_index ON nbf () USING >>>>>>>>> 'com.stratio.cassandra.lucene.Index' WITH OPTIONS =3D {'refresh_s= econds': >>>>>>>>> '1', 'schema': '{ >>>>>>>>> fields : { >>>>>>>>> id : {type : "bigint"}, >>>>>>>>> f_d_name : { >>>>>>>>> type : "string", >>>>>>>>> indexed : true, >>>>>>>>> sorted : false, >>>>>>>>> validated : true, >>>>>>>>> case_sensitive : false >>>>>>>>> } >>>>>>>>> } >>>>>>>>> }'}; >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------= --------------------------------------------------- >>>>>>>> Atul Saroha >>>>>>>> *Lead Software Engineer* >>>>>>>> *M*: +91 8447784271 *T*: +91 124-415-6069 *EXT*: 12369 >>>>>>>> Plot # 362, ASF Centre - Tower A, Udyog Vihar, >>>>>>>> Phase -4, Sector 18, Gurgaon, Haryana 122016, INDIA >>>>>>>> >>>>>>>> On Mon, Jun 13, 2016 at 11:11 PM, Siddharth Verma < >>>>>>>> verma.siddharth@snapdeal.com> wrote: >>>>>>>> >>>>>>>>> No, all rows were not the same. >>>>>>>>> Querying only on the partition key gives 20 rows. >>>>>>>>> In the erroneous result, while querying on partition key and >>>>>>>>> clustering key, we got 16 of those 20 rows. >>>>>>>>> >>>>>>>>> And for "*tombstone_threshold"* there isn't any entry at column >>>>>>>>> family level. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Siddharth Verma >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Tyler Hobbs >>>>>>> DataStax >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Joel Knighton >>>> Cassandra Developer | joel.knighton@datastax.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >> -- >> >> >> >> Joel Knighton >> Cassandra Developer | joel.knighton@datastax.com >> >> >> >> >> >> >> >> > > --001a11429d720b1093053541fec6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have verified this issue to be fixed in 3.6 and 3.7.=C2= =A0
And the issue mentioned on this thread is fixed as well.

On Wed, Jun 15, = 2016 at 12:43 AM, Bhuvan Rawal <bhu1rawal@gmail.com> wrote= :
Joel,

If = we look at the schema carefully:
CREATE TABLE test0 (
    pk int,
    a int,
    b text,
    s text static,
    PRIMARY KEY (pk, a)
);
and filtering is performed on clustering column a and its = not a static column:
select * from test0 where pk=3D0 and a=3D2;


On Wed,= Jun 15, 2016 at 12:39 AM, Joel Knighton <joel.knighton@datastax.= com> wrote:
It doesn't seem to be an exact duplicate - CASSANDRA-11513 relies on = you selecting a static column, which you weren't doing in the reported = issue. That said, I haven't looked too closely.

On Tue, Jun 14, 2016 at 2= :07 PM, Bhuvan Rawal <bhu1rawal@gmail.com> wrote:
I can reproduce=C2=A0CASSANDRA-11513=C2=A0locally on 3.5, possible = duplicate.

On Wed, Jun 15, 2016 at 12:29 AM, Joel Knighton = <joel.kn= ighton@datastax.com> wrote:
There's some precedent for similar issues with static= columns in 3.5 with https://issues.apache.org/jira/browse/CASSAND= RA-11513=C2=A0- a deterministic (or somewhat deterministic) path for re= production would help narrow the issue down farther. I've played around= locally with similar schemas (sans the stratio indices) and couldn't r= eproduce the issue.

On Tue, Jun 14, 2016 at 1:41 PM, Bhuvan Rawal <bhu1r= awal@gmail.com> wrote:
Jira=C2=A0CASSANDRA-12003=C2=A0Has been created f= or the same.

On Tue, Jun 14, 2016 at 11:54 PM, Atul Saroha <atul.saroha@sna= pdeal.com> wrote:
Hi Tyler,

This issue is mainly visible for table= s having static columns, still investigating.
We will try to test after = removing lucene index but I don=E2=80=99t think this plug-in could led to c= hange in behaviour of cassandra write to table's memtable.

---------------= ---------------------------------------------------------------------------= ---------------------------
Atul Saroha
Lead Softw= are Engineer
M: +9= 1 8447784271=C2=A0T: +91 124-415-6069 EXT: 12369
P= lot # 362, ASF Centre - Tower A, Udyog Vihar,
=C2=A0Phase -4, Sector 18,= Gurgaon, Haryana 122016, INDIA
=

On Tue, Jun 14, 2016 at 9:5= 4 PM, Tyler Hobbs <tyler@datastax.com> wrote:
Is 'id' your partition key? I= 'm not familiar with the stratio indexes, but it looks like the primary= key columns are both indexed.=C2=A0 Perhaps this is related?

On Tue, Jun= 14, 2016 at 1:25 AM, Atul Saroha <atul.saroha@snapdeal.com>= wrote:
After fur= ther debug, this issue is found in in-memory memtable as doing nodetool flu= sh + compact resolve the issue. And there is no batch write used for this t= able which is showing issue.
Table properties:

WITH CLUSTERING ORDER BY (f_name ASC)
= =C2=A0=C2=A0=C2=A0 AND bloom_filter_fp_chance =3D 0.01
=C2=A0=C2=A0=C2= =A0 AND caching =3D {'keys': 'ALL', 'rows_per_partition= ': 'NONE'}
=C2=A0=C2=A0=C2=A0 AND comment =3D ''
= =C2=A0=C2=A0=C2=A0 AND compaction =3D {'class': 'org.apache.cas= sandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold&= #39;: '32', 'min_threshold': '4'}
=C2=A0=C2=A0= =C2=A0 AND compression =3D {'chunk_length_in_kb': '64', = 9;class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
= =C2=A0=C2=A0=C2=A0 AND crc_check_chance =3D 1.0
=C2=A0=C2=A0=C2=A0 AND d= clocal_read_repair_chance =3D 0.1
=C2=A0=C2=A0=C2=A0 AND default_time_to= _live =3D 0
=C2=A0=C2=A0=C2=A0 AND gc_grace_seconds =3D 864000
=C2=A0= =C2=A0=C2=A0 AND max_index_interval =3D 2048
=C2=A0=C2=A0=C2=A0 AND memt= able_flush_period_in_ms =3D 0
=C2=A0=C2=A0=C2=A0 AND min_index_interval = =3D 128
=C2=A0=C2=A0=C2=A0 AND read_repair_chance =3D 0.0
=C2=A0=C2= =A0=C2=A0 AND speculative_retry =3D '99PERCENTILE';
CREATE CUSTO= M INDEX nbf_index ON nbf () USING 'com.stratio.cassandra.lucene.Index&#= 39; WITH OPTIONS =3D {'refresh_seconds': '1', 'schema&#= 39;: '{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fields : {
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 id=C2=A0 : = {type : "bigint"},
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 f_d_name : {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : "string",
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 indexed=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : true,=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 sorted=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 := false,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 validated=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : true,=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 case_sensitive : false
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0= =C2=A0 }'};


<= div>
---------------------------------------------------= ------------------------------------------------------------------
Atul = Saroha
= Lead Software Engineer
M= : +91 8447784271=C2=A0T: +91 124-415-6069 EXT: 12369=
Plot # 362, ASF Centre - Tower A, Udyog Vihar,
=C2=A0Phase -4, = Sector 18, Gurgaon, Haryana 122016, INDIA

On Mon, Jun 13, 2016 at 11:11 PM, Siddharth = Verma <verma.siddharth@snapdeal.com> wrote:
No, = all rows were not the same.
Querying only on the partition key gi= ves 20 rows.
In the erroneous result, while querying on partition = key and clustering key, we got 16 of those 20 rows.

And for &q= uot;tombstone_threshold" there isn't any entry at column family level.
Thanks,
Siddharth Verma






--
Tyler Hobbs
DataStax
<= /div>





<= font color=3D"#888888">--
=

=

Joel Knighton
Cass= andra Developer | joel.knighton@datastax.com


=





--
=

--001a11429d720b1093053541fec6--