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=0 and a=2;



On Wed, Jun 15, 2016 at 12:39 AM, Joel Knighton <joel.knigh...@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 <bhu1ra...@gmail.com> wrote:
>
>> I can reproduce CASSANDRA-11513
>> <https://issues.apache.org/jira/browse/CASSANDRA-11513> locally on 3.5,
>> possible duplicate.
>>
>> On Wed, Jun 15, 2016 at 12:29 AM, Joel Knighton <
>> joel.knigh...@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 <bhu1ra...@gmail.com>
>>> wrote:
>>>
>>>> Jira CASSANDRA-12003
>>>> <https://issues.apache.org/jira/browse/CASSANDRA-12003> Has been
>>>> created for the same.
>>>>
>>>> On Tue, Jun 14, 2016 at 11:54 PM, Atul Saroha <atul.sar...@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’t 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 <ty...@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.
>>>>>> Perhaps this is related?
>>>>>>
>>>>>> On Tue, Jun 14, 2016 at 1:25 AM, Atul Saroha <
>>>>>> atul.sar...@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 = 0.01
>>>>>>>>     AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
>>>>>>>>     AND comment = ''
>>>>>>>>     AND compaction = {'class':
>>>>>>>> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
>>>>>>>> 'max_threshold': '32', 'min_threshold': '4'}
>>>>>>>>     AND compression = {'chunk_length_in_kb': '64', 'class':
>>>>>>>> 'org.apache.cassandra.io.compress.LZ4Compressor'}
>>>>>>>>     AND crc_check_chance = 1.0
>>>>>>>>     AND dclocal_read_repair_chance = 0.1
>>>>>>>>     AND default_time_to_live = 0
>>>>>>>>     AND gc_grace_seconds = 864000
>>>>>>>>     AND max_index_interval = 2048
>>>>>>>>     AND memtable_flush_period_in_ms = 0
>>>>>>>>     AND min_index_interval = 128
>>>>>>>>     AND read_repair_chance = 0.0
>>>>>>>>     AND speculative_retry = '99PERCENTILE';
>>>>>>>> CREATE CUSTOM INDEX nbf_index ON nbf () USING
>>>>>>>> 'com.stratio.cassandra.lucene.Index' WITH OPTIONS = {'refresh_seconds':
>>>>>>>> '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.siddha...@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 <http://datastax.com/>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> <http://www.datastax.com/>
>>>
>>> Joel Knighton
>>> Cassandra Developer | joel.knigh...@datastax.com
>>>
>>> <https://www.linkedin.com/company/datastax>
>>> <https://www.facebook.com/datastax> <https://twitter.com/datastax>
>>> <https://plus.google.com/+Datastax/about>
>>> <http://feeds.feedburner.com/datastax> <https://github.com/datastax/>
>>>
>>> <http://cassandrasummit.org/Email_Signature>
>>>
>>
>>
>
>
> --
>
> <http://www.datastax.com/>
>
> Joel Knighton
> Cassandra Developer | joel.knigh...@datastax.com
>
> <https://www.linkedin.com/company/datastax>
> <https://www.facebook.com/datastax> <https://twitter.com/datastax>
> <https://plus.google.com/+Datastax/about>
> <http://feeds.feedburner.com/datastax> <https://github.com/datastax/>
>
> <http://cassandrasummit.org/Email_Signature>
>

Reply via email to