[jira] [Commented] (CASSANDRA-11432) Counter values become under-counted when running repair.

2016-04-03 Thread Dikang Gu (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223678#comment-15223678
 ] 

Dikang Gu commented on CASSANDRA-11432:
---

[~iamaleksey], any updates on this? Any more information we can provide? Thanks!

> Counter values become under-counted when running repair.
> 
>
> Key: CASSANDRA-11432
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11432
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Aleksey Yeschenko
>
> We are experimenting Counters in Cassandra 2.2.5. Our setup is that we have 6 
> nodes, across three different regions, and in each region, the replication 
> factor is 2. Basically, each nodes holds a full copy of the data.
> We are writing to cluster with CL = 2, and reading with CL = 1. 
> When are doing 30k/s counter increment/decrement per node, and at the 
> meanwhile, we are double writing to our mysql tier, so that we can measure 
> the accuracy of C* counter, compared to mysql.
> The experiment result was great at the beginning, the counter value in C* and 
> mysql are very close. The difference is less than 0.1%. 
> But when we start to run the repair on one node, the counter value in C* 
> become much less than the value in mysql,  the difference becomes larger than 
> 1%.
> My question is that is it a known problem that the counter value will become 
> under-counted if repair is running? Should we avoid running repair for 
> counter tables?
> Thanks. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11483) Enhance sstablemetadata

2016-04-03 Thread Chris Lohfink (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Lohfink updated CASSANDRA-11483:
--
Assignee: Chris Lohfink
  Status: Patch Available  (was: Open)

attached patch or 
https://github.com/clohfink/cassandra/tree/11483-metadata-update

> Enhance sstablemetadata
> ---
>
> Key: CASSANDRA-11483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11483
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Minor
> Attachments: CASSANDRA-11483.txt, Screen Shot 2016-04-03 at 11.40.32 
> PM.png
>
>
> sstablemetadata provides quite a bit of useful information but theres a few 
> hiccups I would like to see addressed:
> * Does not use client mode
> * Units are not provided (or anything for that matter). There is data in 
> micros, millis, seconds as durations and timestamps from epoch. But there is 
> no way to tell what one is without a non-trival code dive
> * in general pretty frustrating to parse



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11483) Enhance sstablemetadata

2016-04-03 Thread Chris Lohfink (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Lohfink updated CASSANDRA-11483:
--
Attachment: CASSANDRA-11483.txt

> Enhance sstablemetadata
> ---
>
> Key: CASSANDRA-11483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11483
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Chris Lohfink
>Priority: Minor
> Attachments: CASSANDRA-11483.txt, Screen Shot 2016-04-03 at 11.40.32 
> PM.png
>
>
> sstablemetadata provides quite a bit of useful information but theres a few 
> hiccups I would like to see addressed:
> * Does not use client mode
> * Units are not provided (or anything for that matter). There is data in 
> micros, millis, seconds as durations and timestamps from epoch. But there is 
> no way to tell what one is without a non-trival code dive
> * in general pretty frustrating to parse



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11483) Enhance sstablemetadata

2016-04-03 Thread Chris Lohfink (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223655#comment-15223655
 ] 

Chris Lohfink commented on CASSANDRA-11483:
---

While at it, included ansi colors and some extra info
!Screen Shot 2016-04-03 at 11.40.32 PM.png|width=500!

Boring example:
{code}
SSTable: /Users/clohfink/git/sstable-tools/src/test/resources/ma-2-big
Partitions: 1   
Rows: 1
Tombstones: 0
Cells: 4
Widest Partitions: 
  [frodo] 1
Largest Partitions: 
  [frodo] 104
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Bloom Filter FP chance: 0.01
Minimum timestamp: 1455937221199050 (02/19/2016 21:00:21)
Maximum timestamp: 1455937221199050 (02/19/2016 21:00:21)
SSTable min local deletion time: 2147483647 (01/18/2038 21:14:07)
SSTable max local deletion time: 2147483647 (01/18/2038 21:14:07)
Compressor: org.apache.cassandra.io.compress.LZ4Compressor
Compression ratio: -1.0
TTL min: 0 (0 milliseconds)
TTL max: 0 (0 milliseconds)
First token: 6564497868996989420 (frodo)
Last token: 6564497868996989420 (frodo)
minClustringValues: []
maxClustringValues: []
Estimated droppable tombstones: 0.0
SSTable Level: 0
Repaired at: 0 (12/31/1969 18:00:00)
  ReplayPosition(segmentId=1455937219425, position=41561)
totalColumnsSet: 4
totalRows: 1
Estimated tombstone drop times: 
   Drop Time| Count  (%)  Histogram 
   2147483647 (01/18/2038 21:14:07) | 4 (100) ██
   Percentiles
   50th  2395318855 (11/26/2045 08:20:55)
   75th  2395318855 (11/26/2045 08:20:55)
   95th  2395318855 (11/26/2045 08:20:55)
   98th  2395318855 (11/26/2045 08:20:55)
   99th  2395318855 (11/26/2045 08:20:55)
   Min   1996099047 (04/02/2033 18:57:27)
   Max   2395318855 (11/26/2045 08:20:55)
Partition Size: 
   Size (bytes) | Count  (%)  Histogram 
   50 (50 B)| 1 (100) ██
   Percentiles
   50th  50 (50 B)
   75th  50 (50 B)
   95th  50 (50 B)
   98th  50 (50 B)
   99th  50 (50 B)
   Min   43 (43 B)
   Max   50 (50 B)
Column Count: 
   Columns | Count  (%)  Histogram 
   4   | 1 (100) ██
   Percentiles
   50th  4
   75th  4
   95th  4
   98th  4
   99th  4
   Min   4
   Max   4
Estimated cardinality: 1
EncodingStats minTTL: 0 (0 milliseconds)
EncodingStats minLocalDeletionTime: 144288 (01/17/1970 10:48:00)
EncodingStats minTimestamp: 1455937221199050 (02/19/2016 21:00:21)
KeyType: org.apache.cassandra.db.marshal.UTF8Type
ClusteringTypes: []
StaticColumns: 
RegularColumns: password:org.apache.cassandra.db.marshal.UTF8Type, 
gender:org.apache.cassandra.db.marshal.UTF8Type, 
state:org.apache.cassandra.db.marshal.UTF8Type, 
birth_year:org.apache.cassandra.db.marshal.LongType
{code}

Slightly more interesting:
{code}
SSTable: /Users/clohfink/git/sstable-tools/ma-119-big
Partitions: 22515   
Rows: 13579337
Tombstones: 0
Cells: 13579337
Widest Partitions: 
  [12345] 99
  [99049] 62664
  [99007] 60437
  [99017] 59728
  [99010] 59555
Largest Partitions: 
  [12345] 189888705
  [99049] 2965017
  [99007] 2860391
  [99017] 2826094
  [99010] 2818038
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Bloom Filter FP chance: 0.01
Minimum timestamp: 1456554952195298 (02/27/2016 00:35:52)
Maximum timestamp: 1456594562846756 (02/27/2016 11:36:02)
SSTable min local deletion time: 2147483647 (01/18/2038 21:14:07)
SSTable max local deletion time: 2147483647 (01/18/2038 21:14:07)
Compressor: org.apache.cassandra.io.compress.LZ4Compressor
Compression ratio: 0.3068105022732033
TTL min: 0 (0 milliseconds)
TTL max: 0 (0 milliseconds)
First token: 286432166153517 (21139)
Last token: 9223106912315136675 (21299)
minClustringValues: [1]
maxClustringValues: [99]
Estimated droppable tombstones: 0.0
SSTable Level: 0
Repaired at: 0 (12/31/1969 18:00:00)
  ReplayPosition(segmentId=1456414025108, position=16709244)
totalColumnsSet: 13579337
totalRows: 13579337
Estimated tombstone drop times: 
   Drop Time| Count (%)  Histogram 
   2147483647 (01/18/2038 21:14:07) | 27158674 (100) 
██
   Percentiles
   50th  2395318855 (11/26/2045 08:20:55)
   75th  2395318855 (11/26/2045 08:20:55)
   95th  2395318855 (11/26/2045 08:20:55)
   98th  2395318855 (11/26/2045 08:20:55)
   99th  2395318855 (11/26/2045 08:20:55)
   Min   1996099047 (04/02/2033 18:57:27)
   Max   2395318855 (11/26/2045 08:20:55)
Partition Size: 
   Size (bytes) | Count  (%)  Histogram 
   258 (258 B)  | 6 (  0) 
   310 (310 B)  |20 (  0) ▏
   372 (372 B)  |50 (  0) ▍
   446 (446 B)  |45 (  0) ▍
   535 (535 B)  |66 (  0) ▌
   642

[jira] [Created] (CASSANDRA-11483) Enhance sstablemetadata

2016-04-03 Thread Chris Lohfink (JIRA) 
Chris Lohfink created CASSANDRA-11483:
-

 Summary: Enhance sstablemetadata
 Key: CASSANDRA-11483
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11483
 Project: Cassandra
  Issue Type: Improvement
  Components: Observability
Reporter: Chris Lohfink
Priority: Minor
 Attachments: Screen Shot 2016-04-03 at 11.40.32 PM.png

sstablemetadata provides quite a bit of useful information but theres a few 
hiccups I would like to see addressed:

* Does not use client mode
* Units are not provided (or anything for that matter). There is data in 
micros, millis, seconds as durations and timestamps from epoch. But there is no 
way to tell what one is without a non-trival code dive
* in general pretty frustrating to parse




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11183) Enable SASI index for static columns

2016-04-03 Thread Pavel Yaskevich (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Yaskevich updated CASSANDRA-11183:

Reviewer: Pavel Yaskevich

> Enable SASI index for static columns
> 
>
> Key: CASSANDRA-11183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: sasi
>Reporter: DOAN DuyHai
>Assignee: DOAN DuyHai
>Priority: Minor
> Fix For: 3.6
>
> Attachments: CASSANDRA-11183-statics.patch, 
> patch_SASI_for_Static_AFTER_Review.txt
>
>
> This is a follow up ticket for post Cassandra 3.4 SASI integration.
> Since [CASSANDRA-8103] it is possible to index static columns, which is 
> *extremely useful* for some scenarios (find all sensors whose characteristics 
> are saved in static columns)
> /cc [~xedin] [~rustyrazorblade] [~jkrupan]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11183) Enable SASI index for static columns

2016-04-03 Thread Pavel Yaskevich (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Yaskevich updated CASSANDRA-11183:

Component/s: (was: CQL)
 sasi

> Enable SASI index for static columns
> 
>
> Key: CASSANDRA-11183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: sasi
>Reporter: DOAN DuyHai
>Assignee: DOAN DuyHai
>Priority: Minor
> Fix For: 3.6
>
> Attachments: CASSANDRA-11183-statics.patch, 
> patch_SASI_for_Static_AFTER_Review.txt
>
>
> This is a follow up ticket for post Cassandra 3.4 SASI integration.
> Since [CASSANDRA-8103] it is possible to index static columns, which is 
> *extremely useful* for some scenarios (find all sensors whose characteristics 
> are saved in static columns)
> /cc [~xedin] [~rustyrazorblade] [~jkrupan]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11183) Enable SASI index for static columns

2016-04-03 Thread Pavel Yaskevich (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Yaskevich updated CASSANDRA-11183:

Attachment: CASSANDRA-11183-statics.patch

[~doanduyhai] The latest patch is not applicable on the trunk, so you will have 
to rebase. I'm also attaching changes (CASSANDRA-11183-statics.patch) for 
Operation, ColumnIndex.getValueOf and SASIIndexBuilder that I think are less 
intrusive comparing to separating getValue into getValueOf and getStaticValueOf 
which has to check column kind anyway.

> Enable SASI index for static columns
> 
>
> Key: CASSANDRA-11183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: DOAN DuyHai
>Assignee: DOAN DuyHai
>Priority: Minor
> Fix For: 3.6
>
> Attachments: CASSANDRA-11183-statics.patch, 
> patch_SASI_for_Static_AFTER_Review.txt
>
>
> This is a follow up ticket for post Cassandra 3.4 SASI integration.
> Since [CASSANDRA-8103] it is possible to index static columns, which is 
> *extremely useful* for some scenarios (find all sensors whose characteristics 
> are saved in static columns)
> /cc [~xedin] [~rustyrazorblade] [~jkrupan]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11225) dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters

2016-04-03 Thread Stefania (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223598#comment-15223598
 ] 

Stefania commented on CASSANDRA-11225:
--

There were no failures in the latest run, so I've created a [pull 
request|https://github.com/riptano/cassandra-dtest/pull/910].

I wonder if it should be considered a bug that the coordinator may not read 
locally with simple snitch, even if it is a replica.

> dtest failure in consistency_test.TestAccuracy.test_simple_strategy_counters
> 
>
> Key: CASSANDRA-11225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11225
> Project: Cassandra
>  Issue Type: Test
>Reporter: Russ Hatch
>Assignee: Russ Hatch
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/209/testReport/consistency_test/TestAccuracy/test_simple_strategy_counters
> Failed on CassCI build cassandra-2.1_novnode_dtest #209
> error: "AssertionError: Failed to read value from sufficient number of nodes, 
> required 2 but got 1 - [574, 2]"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11320) Improve backoff policy for cqlsh COPY FROM

2016-04-03 Thread Stefania (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223595#comment-15223595
 ] 

Stefania commented on CASSANDRA-11320:
--

bq. Since this is a fairly large change, let's keep it in 3.x for now. 

Agreed.

bq. In order to get this before the 3.5 code freeze, I went ahead and merged 
this myself and ran the relevant dtests locally. Aside from one minor dtest 
tweak everything looks good.

Thank you so much for merging and fixing the flacky test.

--

I've created a dtest pull request 
[here|https://github.com/riptano/cassandra-dtest/pull/909]; it contains a new 
test that exercises the back-off policy.

> Improve backoff policy for cqlsh COPY FROM
> --
>
> Key: CASSANDRA-11320
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11320
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Stefania
>Assignee: Stefania
>  Labels: doc-impacting
> Fix For: 3.0.5, 3.5
>
>
> Currently we have an exponential back-off policy in COPY FROM that kicks in 
> when timeouts are received. However there are two limitations:
> * it does not cover new requests and therefore we may not back-off 
> sufficiently to give time to an overloaded server to recover
> * the pause is performed in the receiving thread and therefore we may not 
> process server messages quickly enough
> There is a static throttling mechanism in rows per second from feeder to 
> worker processes (the INGESTRATE) but the feeder has no idea of the load of 
> each worker process. However it's easy to keep track of how many chunks a 
> worker process has yet to read by introducing a bounded semaphore.
> The idea is to move the back-off pauses to the worker processes main thread 
> so as to include all messages, new and retries, not just the retries that 
> timed out. The worker process will not read new chunks during the back-off 
> pauses, and the feeder process can then look at the number of pending chunks 
> before sending new chunks to a worker process.
> [~aholmber], [~aweisberg] what do you think?  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11474) cqlsh: COPY FROM should use regular inserts for single statement batches

2016-04-03 Thread Stefania (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefania updated CASSANDRA-11474:
-
Labels: lhf  (was: )

> cqlsh: COPY FROM should use regular inserts for single statement batches
> 
>
> Key: CASSANDRA-11474
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11474
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Stefania
>Assignee: Stefania
>  Labels: lhf
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> I haven't reproduced it with a test yet but, from code inspection, if CQL 
> rows are larger than {{batch_size_fail_threshold_in_kb}} and this parameter 
> cannot be changed, then data import will fail.
> Users can control the batch size by setting MAXBATCHSIZE.
> If a batch contains a single statement, there is no need to use a batch and 
> we should use normal inserts instead or, alternatively, we should skip the 
> batch size check for unlogged batches with only one statement.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11474) cqlsh: COPY FROM should use regular inserts for single statement batches

2016-04-03 Thread Stefania (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223589#comment-15223589
 ] 

Stefania commented on CASSANDRA-11474:
--

We should also make sure that if a child process aborts during startup, then 
the error message is displayed to the user. At the moment the only way to see 
exceptions thrown by worker processes during startup is via {{--debug}}.

> cqlsh: COPY FROM should use regular inserts for single statement batches
> 
>
> Key: CASSANDRA-11474
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11474
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 2.2.x, 3.0.x, 3.x
>
>
> I haven't reproduced it with a test yet but, from code inspection, if CQL 
> rows are larger than {{batch_size_fail_threshold_in_kb}} and this parameter 
> cannot be changed, then data import will fail.
> Users can control the batch size by setting MAXBATCHSIZE.
> If a batch contains a single statement, there is no need to use a batch and 
> we should use normal inserts instead or, alternatively, we should skip the 
> batch size check for unlogged batches with only one statement.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11462) IncomingStreamingConnection version check message wrong

2016-04-03 Thread Ryan Magnusson (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223527#comment-15223527
 ] 

Ryan Magnusson commented on CASSANDRA-11462:


[~snazy], how does it look now?

> IncomingStreamingConnection version check message wrong
> ---
>
> Key: CASSANDRA-11462
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11462
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Priority: Trivial
>
> If compares against {{StreamMessage.CURRENT_VERSION}} but prints 
> {{MessagingService.current_version}}. The error message is confusing tho.
> {code}
> if (version != StreamMessage.CURRENT_VERSION)
> throw new IOException(String.format("Received stream using 
> protocol version %d (my version %d). Terminating connection", version, 
> MessagingService.current_version));
> {code}
> EDIT: That message is only printed at debug log level



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-10120) When specifying both num_tokens and initial_token, error out if the numbers don't match

2016-04-03 Thread Roman Pogribnyi (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-10120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Pogribnyi updated CASSANDRA-10120:

Attachment: 10120-3.0.txt

Updated patch to check whether size(initial_token) == num_tokens

> When specifying both num_tokens and initial_token, error out if the numbers 
> don't match
> ---
>
> Key: CASSANDRA-10120
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10120
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeremy Hanna
>Assignee: Roman Pogribnyi
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
> Attachments: 10120-3.0.txt, 10120-3.0.txt
>
>
> Right now if both initial_token and num_tokens are specified, initial_token 
> is used.  As something to not trip people up, it would be nice to do a basic 
> error check.  If both are specified, we should make sure they match.  That 
> is, if they have one initial token and num_tokens of 256, it should error out 
> on startup and alert the user of the configuration.  It's better to fail fast 
> than bootstrap with only one token.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11183) Enable SASI index for static columns

2016-04-03 Thread DOAN DuyHai (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

DOAN DuyHai updated CASSANDRA-11183:

Attachment: patch_SASI_for_Static_AFTER_Review.txt

Ok, after [~xedin] remarks, I have updated the patch.

Now *normal* and *static* rows are passed together to 
{{operation.satisfiedBy(Unfiltered, Row, allowMissings)}} and 
{{operation.localSatisfiedBy(Unfiltered, Row, allowMissings)}}

However, I did not modify the method {{ColumnIndex.getValueOf(column, row, 
nowInSecs)}} because it is used at many places where we may not have access to 
static row.

Instead I added a new method  {{ColumnIndex.getValueOfStatic(column, staticRow, 
nowInSecs)}} 

This method will be called by

* {{ColumnIndex.index(DecoratedKey, Row)}}
* {{operation.localSatisfiedBy(Unfiltered, Row, allowMissings)}}

For test coverage, in addition of existing {{SASIIndexTest.testStaticIndex}}, I 
also added {{OperationTest.testSatisfiedByWithStatic}} which combines

# static AND non static conditions
# static OR non static conditions
# (static OR static conditions) AND  static conditions

All tests are green

> Enable SASI index for static columns
> 
>
> Key: CASSANDRA-11183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: DOAN DuyHai
>Assignee: DOAN DuyHai
>Priority: Minor
> Fix For: 3.6
>
> Attachments: patch_SASI_for_Static_AFTER_Review.txt
>
>
> This is a follow up ticket for post Cassandra 3.4 SASI integration.
> Since [CASSANDRA-8103] it is possible to index static columns, which is 
> *extremely useful* for some scenarios (find all sensors whose characteristics 
> are saved in static columns)
> /cc [~xedin] [~rustyrazorblade] [~jkrupan]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[Cassandra Wiki] Update of "ContributorsGroup" by DaveBrosius

2016-04-03 Thread Apache Wiki 
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for 
change notification.

The "ContributorsGroup" page has been changed by DaveBrosius:
https://wiki.apache.org/cassandra/ContributorsGroup?action=diff=56=57

   * Nick Neuberger
   * ono_matope
   * OtisGospodnetic
+  * PedroGordo
   * PeterSchuller
   * PauloMotta
   * PavelYaskevich

[jira] [Updated] (CASSANDRA-11183) Enable SASI index for static columns

2016-04-03 Thread DOAN DuyHai (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

DOAN DuyHai updated CASSANDRA-11183:

Attachment: (was: patch_SASI_for_Static.txt)

> Enable SASI index for static columns
> 
>
> Key: CASSANDRA-11183
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11183
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: DOAN DuyHai
>Assignee: DOAN DuyHai
>Priority: Minor
> Fix For: 3.6
>
>
> This is a follow up ticket for post Cassandra 3.4 SASI integration.
> Since [CASSANDRA-8103] it is possible to index static columns, which is 
> *extremely useful* for some scenarios (find all sensors whose characteristics 
> are saved in static columns)
> /cc [~xedin] [~rustyrazorblade] [~jkrupan]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11482) nodetool: Found unexpected parameters: [gettimeout, read]

2016-04-03 Thread Dinesh Kumar (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dinesh Kumar updated CASSANDRA-11482:
-
Description: 
While getting timeout values from nodetool giving below error.

{quote}
root@ubuntu:~# nodetool gettimeout read
nodetool: Found unexpected parameters: [gettimeout, read]
See 'nodetool help' or 'nodetool help '.
{quote}

Getting the same error on CCM as well.

{quote}
$ ccm node1 nodetool gettimeout read
Traceback (most recent call last):
  File "E:\Studies\Cassandra\ccm\ccm-master\ccm.py", line 74, in 
cmd.run()
  File "E:\Studies\Cassandra\ccm\ccm-master\ccmlib\cmds\node_cmds.py", line 
267, in run
stdout, stderr = self.node.nodetool(" ".join(self.args[1:]))
  File "E:\Studies\Cassandra\ccm\ccm-master\ccmlib\node.py", line 699, in 
nodetool
raise NodetoolError(" ".join(args), exit_status, stdout, stderr)
ccmlib.node.NodetoolError: Nodetool command 
'C:\Users\dins2\.ccm\repository\3.0.3\bin\nodetool.bat -h localhost -p 7100 
gettimeout read' failed; exit status: 1; stdout: nodetool: Found unexpected 
parameters: [gettimeout, read]
See 'nodetool help' or 'nodetool help '.
{quote}

C* v3.0.3

  was:
While getting timeout values from nodetool giving below error.

{quote}
root@ubuntu:~# nodetool gettimeout read
nodetool: Found unexpected parameters: [gettimeout, read]
See 'nodetool help' or 'nodetool help '.
{quote}

Getting the same error on CCM as well.

{quote}
$ ccm node1 nodetool gettimeout read
Traceback (most recent call last):
  File "E:\Studies\Cassandra\ccm\ccm-master\ccm.py", line 74, in 
cmd.run()
  File "E:\Studies\Cassandra\ccm\ccm-master\ccmlib\cmds\node_cmds.py", line 
267, in run
stdout, stderr = self.node.nodetool(" ".join(self.args[1:]))
  File "E:\Studies\Cassandra\ccm\ccm-master\ccmlib\node.py", line 699, in 
nodetool
raise NodetoolError(" ".join(args), exit_status, stdout, stderr)
ccmlib.node.NodetoolError: Nodetool command 
'C:\Users\dins2\.ccm\repository\3.0.3\bin\nodetool.bat -h localhost -p 7100 
gettimeout read' failed; exit status: 1; stdout: nodetool: Found unexpected 
parameters: [gettimeout, read]
See 'nodetool help' or 'nodetool help '.
{quote}




> nodetool: Found unexpected parameters: [gettimeout, read]
> -
>
> Key: CASSANDRA-11482
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11482
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Dinesh Kumar
>  Labels: gettimeout, nodetool
> Fix For: 3.4
>
>
> While getting timeout values from nodetool giving below error.
> {quote}
> root@ubuntu:~# nodetool gettimeout read
> nodetool: Found unexpected parameters: [gettimeout, read]
> See 'nodetool help' or 'nodetool help '.
> {quote}
> Getting the same error on CCM as well.
> {quote}
> $ ccm node1 nodetool gettimeout read
> Traceback (most recent call last):
>   File "E:\Studies\Cassandra\ccm\ccm-master\ccm.py", line 74, in 
> cmd.run()
>   File "E:\Studies\Cassandra\ccm\ccm-master\ccmlib\cmds\node_cmds.py", line 
> 267, in run
> stdout, stderr = self.node.nodetool(" ".join(self.args[1:]))
>   File "E:\Studies\Cassandra\ccm\ccm-master\ccmlib\node.py", line 699, in 
> nodetool
> raise NodetoolError(" ".join(args), exit_status, stdout, stderr)
> ccmlib.node.NodetoolError: Nodetool command 
> 'C:\Users\dins2\.ccm\repository\3.0.3\bin\nodetool.bat -h localhost -p 7100 
> gettimeout read' failed; exit status: 1; stdout: nodetool: Found unexpected 
> parameters: [gettimeout, read]
> See 'nodetool help' or 'nodetool help '.
> {quote}
> C* v3.0.3



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CASSANDRA-11482) nodetool: Found unexpected parameters: [gettimeout, read]

2016-04-03 Thread Dinesh Kumar (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dinesh Kumar resolved CASSANDRA-11482.
--
   Resolution: Implemented
Fix Version/s: 3.4

{{gettimeout}} and {{settimeout}} have been implemented in v3.4

> nodetool: Found unexpected parameters: [gettimeout, read]
> -
>
> Key: CASSANDRA-11482
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11482
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Dinesh Kumar
>  Labels: gettimeout, nodetool
> Fix For: 3.4
>
>
> While getting timeout values from nodetool giving below error.
> {quote}
> root@ubuntu:~# nodetool gettimeout read
> nodetool: Found unexpected parameters: [gettimeout, read]
> See 'nodetool help' or 'nodetool help '.
> {quote}
> Getting the same error on CCM as well.
> {quote}
> $ ccm node1 nodetool gettimeout read
> Traceback (most recent call last):
>   File "E:\Studies\Cassandra\ccm\ccm-master\ccm.py", line 74, in 
> cmd.run()
>   File "E:\Studies\Cassandra\ccm\ccm-master\ccmlib\cmds\node_cmds.py", line 
> 267, in run
> stdout, stderr = self.node.nodetool(" ".join(self.args[1:]))
>   File "E:\Studies\Cassandra\ccm\ccm-master\ccmlib\node.py", line 699, in 
> nodetool
> raise NodetoolError(" ".join(args), exit_status, stdout, stderr)
> ccmlib.node.NodetoolError: Nodetool command 
> 'C:\Users\dins2\.ccm\repository\3.0.3\bin\nodetool.bat -h localhost -p 7100 
> gettimeout read' failed; exit status: 1; stdout: nodetool: Found unexpected 
> parameters: [gettimeout, read]
> See 'nodetool help' or 'nodetool help '.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11482) nodetool: Found unexpected parameters: [gettimeout, read]

2016-04-03 Thread Dinesh Kumar (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223343#comment-15223343
 ] 

Dinesh Kumar commented on CASSANDRA-11482:
--

[~yukim], Thanks for the clarification. I have checked in C* v3.4, I can able 
to get the {{timeout}} values and {{settimeout}} also working as expected.

> nodetool: Found unexpected parameters: [gettimeout, read]
> -
>
> Key: CASSANDRA-11482
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11482
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Dinesh Kumar
>  Labels: gettimeout, nodetool
>
> While getting timeout values from nodetool giving below error.
> {quote}
> root@ubuntu:~# nodetool gettimeout read
> nodetool: Found unexpected parameters: [gettimeout, read]
> See 'nodetool help' or 'nodetool help '.
> {quote}
> Getting the same error on CCM as well.
> {quote}
> $ ccm node1 nodetool gettimeout read
> Traceback (most recent call last):
>   File "E:\Studies\Cassandra\ccm\ccm-master\ccm.py", line 74, in 
> cmd.run()
>   File "E:\Studies\Cassandra\ccm\ccm-master\ccmlib\cmds\node_cmds.py", line 
> 267, in run
> stdout, stderr = self.node.nodetool(" ".join(self.args[1:]))
>   File "E:\Studies\Cassandra\ccm\ccm-master\ccmlib\node.py", line 699, in 
> nodetool
> raise NodetoolError(" ".join(args), exit_status, stdout, stderr)
> ccmlib.node.NodetoolError: Nodetool command 
> 'C:\Users\dins2\.ccm\repository\3.0.3\bin\nodetool.bat -h localhost -p 7100 
> gettimeout read' failed; exit status: 1; stdout: nodetool: Found unexpected 
> parameters: [gettimeout, read]
> See 'nodetool help' or 'nodetool help '.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11480) Fix uptodate check for antlr files after 11372

2016-04-03 Thread Robert Stupp (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-11480:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Thanks!
Committed as 5e933c542a2c452adefce7e652015933f9d75f8a to trunk

> Fix uptodate check for antlr files after 11372
> --
>
> Key: CASSANDRA-11480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11480
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Trivial
>  Labels: lhf
> Fix For: 3.6
>
> Attachments: fix-antlr.txt
>
>
> CASSANDRA-11372 has split {{Cql.g}} into three separate files.
> The {{uptodate}} check in {{build.xml}} just checks against {{Cql.g}} but not 
> the two new files.
> Attached trivial patch fixes {{build.xml}} to check against all three files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11480) Fix uptodate check for antlr files after 11372

2016-04-03 Thread Robert Stupp (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-11480:
-
 Reviewer: Sylvain Lebresne
Fix Version/s: (was: 3.x)
   3.6

> Fix uptodate check for antlr files after 11372
> --
>
> Key: CASSANDRA-11480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11480
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Trivial
>  Labels: lhf
> Fix For: 3.6
>
> Attachments: fix-antlr.txt
>
>
> CASSANDRA-11372 has split {{Cql.g}} into three separate files.
> The {{uptodate}} check in {{build.xml}} just checks against {{Cql.g}} but not 
> the two new files.
> Attached trivial patch fixes {{build.xml}} to check against all three files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

cassandra git commit: Fix uptodate check for antlr files after 11372

2016-04-03 Thread snazy 
Repository: cassandra
Updated Branches:
  refs/heads/trunk 2ca2fffee -> 5e933c542


Fix uptodate check for antlr files after 11372

patch by Robert Stupp; reviewed by Sylvain Lebresne for CASSANDRA-11480


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5e933c54
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5e933c54
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5e933c54

Branch: refs/heads/trunk
Commit: 5e933c542a2c452adefce7e652015933f9d75f8a
Parents: 2ca2fff
Author: Robert Stupp 
Authored: Sun Apr 3 16:17:15 2016 +0200
Committer: Robert Stupp 
Committed: Sun Apr 3 16:17:15 2016 +0200

--
 build.xml | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e933c54/build.xml
--
diff --git a/build.xml b/build.xml
index 1855a16..c6b2246 100644
--- a/build.xml
+++ b/build.xml
@@ -212,8 +212,11 @@
 -->
 
 
+
targetfile="${build.src.gen-java}/org/apache/cassandra/cql3/Cql.tokens">
+
+
+
+

[jira] [Commented] (CASSANDRA-11480) Fix uptodate check for antlr files after 11372

2016-04-03 Thread Sylvain Lebresne (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223306#comment-15223306
 ] 

Sylvain Lebresne commented on CASSANDRA-11480:
--

+1

> Fix uptodate check for antlr files after 11372
> --
>
> Key: CASSANDRA-11480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11480
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Trivial
>  Labels: lhf
> Fix For: 3.x
>
> Attachments: fix-antlr.txt
>
>
> CASSANDRA-11372 has split {{Cql.g}} into three separate files.
> The {{uptodate}} check in {{build.xml}} just checks against {{Cql.g}} but not 
> the two new files.
> Attached trivial patch fixes {{build.xml}} to check against all three files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11154) CassandraDaemon in Managed mode fails to be restartable

2016-04-03 Thread Achim Nierbeck (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223247#comment-15223247
 ] 

Achim Nierbeck commented on CASSANDRA-11154:


Is this patch acceptable, should I provide more infos/details about it?

> CassandraDaemon in Managed mode fails to be restartable
> ---
>
> Key: CASSANDRA-11154
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11154
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Achim Nierbeck
> Fix For: 3.x
>
> Attachments: CASSANDRA-11154_patch.txt
>
>
> Restarting the CassandraDeamon in managed mode fails to restart due to 
> duplicate migration of already migrated keyspaces. 
> To reproduce this, just do something like in this test class: 
> https://github.com/ANierbeck/Karaf-Cassandra/blob/master/Karaf-Cassandra-Embedded/src/test/java/de/nierbeck/cassandra/embedded/TestEmbedded.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-11310) Allow filtering on clustering columns for queries without secondary indexes

2016-04-03 Thread Alex Petrov (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223225#comment-15223225
 ] 

Alex Petrov commented on CASSANDRA-11310:
-

I've found one problem. It turns out that the restrictions I specified were a 
bit too strict and under several scenarios (for example, when PK is restricted 
with EQ and there are two slices, although both slices have same first column) 
were involving filtering even though they shouldn't have. One other scenario 
was handled incorrectly because the position counter was never updated. 

With Frozen collection tests - it's just missed cases that previously were 
disallowed.

I've pushed (unsquashed to make it easier to trace changes) commits here: 
https://github.com/ifesdjeen/cassandra/commits/11310-trunk

> Allow filtering on clustering columns for queries without secondary indexes
> ---
>
> Key: CASSANDRA-11310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11310
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Alex Petrov
>  Labels: doc-impacting
> Fix For: 3.x
>
>
> Since CASSANDRA-6377 queries without index filtering non-primary key columns 
> are fully supported.
> It makes sense to also support filtering on clustering-columns.
> {code}
> CREATE TABLE emp_table2 (
> empID int,
> firstname text,
> lastname text,
> b_mon text,
> b_day text,
> b_yr text,
> PRIMARY KEY (empID, b_yr, b_mon, b_day));
> SELECT b_mon,b_day,b_yr,firstname,lastname FROM emp_table2
> WHERE b_mon='oct' ALLOW FILTERING;
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-11310) Allow filtering on clustering columns for queries without secondary indexes

2016-04-03 Thread Alex Petrov (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223225#comment-15223225
 ] 

Alex Petrov edited comment on CASSANDRA-11310 at 4/3/16 11:45 AM:
--

I've found one problem. It turns out that the restrictions I specified were a 
bit too strict and under several scenarios (for example, when PK is restricted 
with EQ and there are two slices, although both slices have same first column) 
were involving filtering even though they shouldn't have. One other scenario 
was handled incorrectly because the position counter was never updated. 

With Frozen collection tests - it's just missed cases that previously were 
disallowed.

I've pushed (unsquashed to make it easier to trace changes) commits here: 
https://github.com/ifesdjeen/cassandra/commits/11310-trunk


was (Author: ifesdjeen):
I've found one problem. It turns out that the restrictions I specified were a 
bit too strict and under several scenarios (for example, when PK is restricted 
with EQ and there are two slices, although both slices have same first column) 
were involving filtering even though they shouldn't have. One other scenario 
was handled incorrectly because the position counter was never updated. 

With Frozen collection tests - it's just missed cases that previously were 
disallowed.

I've pushed (unsquashed to make it easier to trace changes) commits here: 
https://github.com/ifesdjeen/cassandra/commits/11310-trunk

> Allow filtering on clustering columns for queries without secondary indexes
> ---
>
> Key: CASSANDRA-11310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11310
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Alex Petrov
>  Labels: doc-impacting
> Fix For: 3.x
>
>
> Since CASSANDRA-6377 queries without index filtering non-primary key columns 
> are fully supported.
> It makes sense to also support filtering on clustering-columns.
> {code}
> CREATE TABLE emp_table2 (
> empID int,
> firstname text,
> lastname text,
> b_mon text,
> b_day text,
> b_yr text,
> PRIMARY KEY (empID, b_yr, b_mon, b_day));
> SELECT b_mon,b_day,b_yr,firstname,lastname FROM emp_table2
> WHERE b_mon='oct' ALLOW FILTERING;
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-7396) Allow selecting Map key, List index

2016-04-03 Thread Robert Stupp (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223215#comment-15223215
 ] 

Robert Stupp commented on CASSANDRA-7396:
-

[~slebresne] am I correct, that 
{{org.apache.cassandra.db.filter.ColumnFilter.Builder#addSubSelection}} would 
be the "key" method to query individual elements / slices from collections 
(sets + maps)?

> Allow selecting Map key, List index
> ---
>
> Key: CASSANDRA-7396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7396
> Project: Cassandra
>  Issue Type: New Feature
>  Components: CQL
>Reporter: Jonathan Ellis
>Assignee: Robert Stupp
>  Labels: cql
> Fix For: 3.x
>
> Attachments: 7396_unit_tests.txt
>
>
> Allow "SELECT map['key]" and "SELECT list[index]."  (Selecting a UDT subfield 
> is already supported.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CASSANDRA-11434) Support EQ/PREFIX queries in CONTAINS mode without tokenization by augmenting SA metadata per term

2016-04-03 Thread Pavel Yaskevich (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Yaskevich resolved CASSANDRA-11434.
-
Resolution: Fixed

+1, Committed.

> Support EQ/PREFIX queries in CONTAINS mode without tokenization by augmenting 
> SA metadata per term
> --
>
> Key: CASSANDRA-11434
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11434
> Project: Cassandra
>  Issue Type: Improvement
>  Components: sasi
>Reporter: Pavel Yaskevich
>Assignee: Jordan West
> Fix For: 3.6
>
>
> We can support EQ/PREFIX requests to CONTAINS indexes by tracking 
> "partiality" of the data stored in the OnDiskIndex and IndexMemtable, if we 
> know exactly if current match represents part of the term or it's original 
> form it would be trivial to support EQ/PREFIX since PREFIX is subset of 
> SUFFIX matches.
> Since we attach uint16 size to each term stored we can take advantage of sign 
> bit so size of the index is not impacted at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

cassandra git commit: Support EQ/PREFIX queries in SASI CONTAINS mode without tokenization

2016-04-03 Thread xedin 
Repository: cassandra
Updated Branches:
  refs/heads/trunk e375a9b1b -> 2ca2fffee


Support EQ/PREFIX queries in SASI CONTAINS mode without tokenization

patch by jrwest and xedin; reviewed by xedin for CASSANDRA-11434


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/2ca2fffe
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/2ca2fffe
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/2ca2fffe

Branch: refs/heads/trunk
Commit: 2ca2fffee80c75e3d1aa38badbefbd3b35851901
Parents: e375a9b
Author: Jordan West 
Authored: Thu Mar 24 23:32:45 2016 -0700
Committer: Pavel Yaskevich 
Committed: Sun Apr 3 00:27:54 2016 -0700

--
 CHANGES.txt |  1 +
 .../cassandra/index/sasi/SSTableIndex.java  | 11 +
 .../org/apache/cassandra/index/sasi/Term.java   | 24 +--
 .../cassandra/index/sasi/TermIterator.java  |  9 
 .../cassandra/index/sasi/conf/ColumnIndex.java  |  6 ++-
 .../cassandra/index/sasi/disk/Descriptor.java   |  2 +-
 .../cassandra/index/sasi/disk/OnDiskIndex.java  | 23 --
 .../index/sasi/disk/OnDiskIndexBuilder.java | 36 +++-
 .../index/sasi/memory/TrieMemIndex.java |  1 +
 .../cassandra/index/sasi/plan/Expression.java   | 10 +
 .../cassandra/index/sasi/sa/IndexedTerm.java| 43 +++
 .../cassandra/index/sasi/sa/IntegralSA.java |  5 ++-
 .../cassandra/index/sasi/sa/SuffixSA.java   | 41 --
 .../cassandra/index/sasi/sa/TermIterator.java   |  2 +-
 .../index/sasi/utils/CombinedTerm.java  |  5 +++
 .../index/sasi/utils/CombinedTermIterator.java  |  5 ++-
 .../cassandra/index/sasi/SASIIndexTest.java | 45 
 .../index/sasi/disk/OnDiskIndexTest.java|  9 +++-
 18 files changed, 230 insertions(+), 48 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/2ca2fffe/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index a01196f..e5ee3d8 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.6
+ * Support EQ/PREFIX queries in SASI CONTAINS mode without tokenization 
(CASSANDRA-11434)
  * Support LIKE operator in prepared statements (CASSANDRA-11456)
  * Add a command to see if a Materialized View has finished building 
(CASSANDRA-9967)
  * Log endpoint and port associated with streaming operation (CASSANDRA-8777)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/2ca2fffe/src/java/org/apache/cassandra/index/sasi/SSTableIndex.java
--
diff --git a/src/java/org/apache/cassandra/index/sasi/SSTableIndex.java 
b/src/java/org/apache/cassandra/index/sasi/SSTableIndex.java
index 7b65232..c67c39c 100644
--- a/src/java/org/apache/cassandra/index/sasi/SSTableIndex.java
+++ b/src/java/org/apache/cassandra/index/sasi/SSTableIndex.java
@@ -27,6 +27,7 @@ import org.apache.cassandra.db.DecoratedKey;
 import org.apache.cassandra.db.marshal.AbstractType;
 import org.apache.cassandra.index.sasi.conf.ColumnIndex;
 import org.apache.cassandra.index.sasi.disk.OnDiskIndex;
+import org.apache.cassandra.index.sasi.disk.OnDiskIndexBuilder;
 import org.apache.cassandra.index.sasi.disk.Token;
 import org.apache.cassandra.index.sasi.plan.Expression;
 import org.apache.cassandra.index.sasi.utils.RangeIterator;
@@ -67,6 +68,16 @@ public class SSTableIndex
 this.index = new OnDiskIndex(indexFile, validator, new 
DecoratedKeyFetcher(sstable));
 }
 
+public OnDiskIndexBuilder.Mode mode()
+{
+return index.mode();
+}
+
+public boolean hasMarkedPartials()
+{
+return index.hasMarkedPartials();
+}
+
 public ByteBuffer minTerm()
 {
 return index.minTerm();

http://git-wip-us.apache.org/repos/asf/cassandra/blob/2ca2fffe/src/java/org/apache/cassandra/index/sasi/Term.java
--
diff --git a/src/java/org/apache/cassandra/index/sasi/Term.java 
b/src/java/org/apache/cassandra/index/sasi/Term.java
index 8e8ceb2..8f42d58 100644
--- a/src/java/org/apache/cassandra/index/sasi/Term.java
+++ b/src/java/org/apache/cassandra/index/sasi/Term.java
@@ -23,30 +23,41 @@ import 
org.apache.cassandra.index.sasi.disk.OnDiskIndexBuilder.TermSize;
 import org.apache.cassandra.index.sasi.utils.MappedBuffer;
 import org.apache.cassandra.db.marshal.AbstractType;
 
+import static 
org.apache.cassandra.index.sasi.disk.OnDiskIndexBuilder.IS_PARTIAL_BIT;
+
 public class Term
 {
 protected final MappedBuffer content;
 protected final TermSize termSize;
 
+private final boolean hasMarkedPartials;
 
-public Term(MappedBuffer content, TermSize size)
+

[jira] [Commented] (CASSANDRA-11462) IncomingStreamingConnection version check message wrong

2016-04-03 Thread Robert Stupp (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15223143#comment-15223143
 ] 

Robert Stupp commented on CASSANDRA-11462:
--

Correction of the message is correct. Can you add two things?
* a {{logger.error}} in the catch block that prints the error without the stack 
trace (but leave the stack trace with trace level)
* add the remote IP to the messages in the catch block


> IncomingStreamingConnection version check message wrong
> ---
>
> Key: CASSANDRA-11462
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11462
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Priority: Trivial
>
> If compares against {{StreamMessage.CURRENT_VERSION}} but prints 
> {{MessagingService.current_version}}. The error message is confusing tho.
> {code}
> if (version != StreamMessage.CURRENT_VERSION)
> throw new IOException(String.format("Received stream using 
> protocol version %d (my version %d). Terminating connection", version, 
> MessagingService.current_version));
> {code}
> EDIT: That message is only printed at debug log level



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11462) IncomingStreamingConnection version check message wrong

2016-04-03 Thread Robert Stupp (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-11462:
-
Reviewer: Robert Stupp

> IncomingStreamingConnection version check message wrong
> ---
>
> Key: CASSANDRA-11462
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11462
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Robert Stupp
>Priority: Trivial
>
> If compares against {{StreamMessage.CURRENT_VERSION}} but prints 
> {{MessagingService.current_version}}. The error message is confusing tho.
> {code}
> if (version != StreamMessage.CURRENT_VERSION)
> throw new IOException(String.format("Received stream using 
> protocol version %d (my version %d). Terminating connection", version, 
> MessagingService.current_version));
> {code}
> EDIT: That message is only printed at debug log level



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)