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>
