[jira] [Commented] (CASSANDRA-11388) FailureDetector.java:456 - Ignoring interval time of

[Relish Chackochan (JIRA)]

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

Relish Chackochan commented on CASSANDRA-11388:
---

Thank You.

> FailureDetector.java:456 - Ignoring interval time of
> 
>
> Key: CASSANDRA-11388
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11388
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Cassandra 2.2.4
>Reporter: Relish Chackochan
>Priority: Minor
>
> We have Cassandra Cluster of 8 nodes with 2.2.4v using jdk1.8.0_65 ( RHEL 6.5 
> 64-bit ) and i am seeing the following error in the Cassandra debug.log file. 
> All the nodes are UP and running with
> "nodetool status". NTP is configured on all nodes and Time syncing well.
> DEBUG [GossipStage:1] 2016-03-21 06:45:30,700 FailureDetector.java:456 - 
> Ignoring interval time of 3069815316 for /192.168.1.153
> DEBUG [GossipStage:1] 2016-03-21 06:45:30,700 FailureDetector.java:456 - 
> Ignoring interval time of 2076119905 for /192.168.1.135
> DEBUG [GossipStage:1] 2016-03-21 06:45:30,700 FailureDetector.java:456 - 
> Ignoring interval time of 2683887772 for /192.168.1.151



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

[jira] [Commented] (CASSANDRA-11408) simple compaction defaults for common scenarios

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa commented on CASSANDRA-11408:


Apologies in advance for bikeshedding, but why limit it to compaction? Why not 
do named profiles for all metadata? Especially since compaction changes often 
necessitate bloom filter changes and read repair changes , why not:

{code:title=example, syntax variant |borderStyle=solid}
ALTER TABLE foo.bar WITH profile = 'timeseries-hourly-for-a-week';
{code}




> simple compaction defaults for common scenarios
> ---
>
> Key: CASSANDRA-11408
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11408
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Jonathan Shook
>
> As compaction strategies get more flexible over time, some users might prefer 
> to have a simple named profile for their settings.
> {code:title=example, syntax variant|borderStyle=solid}
> alter table foo.bar with compaction = 'timeseries-hourly-for-a-week';
> {code}
> {code:title=example, syntax variant |borderStyle=solid}
> alter table foo.bar with compaction = { 'profile' : 'key-value-balanced-ops' 
> };
> {code}
> These would simply be a map into sets of well-tested and documented defaults 
> across any of the core compaction strategies.
> This would simplify setting up compaction for well-understood workloads, but 
> still allow for customization where desired.



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

[jira] [Updated] (CASSANDRA-11053) COPY FROM on large datasets: fix progress report and debug performance

[Stefania (JIRA)]

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

Stefania updated CASSANDRA-11053:
-
Status: Ready to Commit  (was: Patch Available)

> COPY FROM on large datasets: fix progress report and debug performance
> --
>
> Key: CASSANDRA-11053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11053
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Stefania
>Assignee: Stefania
>  Labels: doc-impacting
> Fix For: 2.1.14, 2.2.6, 3.0.5, 3.5
>
> Attachments: bisect_test.py, copy_from_large_benchmark.txt, 
> copy_from_large_benchmark_2.txt, parent_profile.txt, parent_profile_2.txt, 
> worker_profiles.txt, worker_profiles_2.txt
>
>
> h5. Description
> Running COPY from on a large dataset (20G divided in 20M records) revealed 
> two issues:
> * The progress report is incorrect, it is very slow until almost the end of 
> the test at which point it catches up extremely quickly.
> * The performance in rows per second is similar to running smaller tests with 
> a smaller cluster locally (approx 35,000 rows per second). As a comparison, 
> cassandra-stress manages 50,000 rows per second under the same set-up, 
> therefore resulting 1.5 times faster. 
> See attached file _copy_from_large_benchmark.txt_ for the benchmark details.
> h5. Doc-impacting changes to COPY FROM options
> * A new option was added: PREPAREDSTATEMENTS - it indicates if prepared 
> statements should be used; it defaults to true.
> * The default value of CHUNKSIZE changed from 1000 to 5000.
> * The default value of MINBATCHSIZE changed from 2 to 10.



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

[jira] [Commented] (CASSANDRA-11053) COPY FROM on large datasets: fix progress report and debug performance

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-11053:
--

CI looks good, ready to commit. Merge information a few comments up.

> COPY FROM on large datasets: fix progress report and debug performance
> --
>
> Key: CASSANDRA-11053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11053
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Stefania
>Assignee: Stefania
>  Labels: doc-impacting
> Fix For: 2.1.14, 2.2.6, 3.0.5, 3.5
>
> Attachments: bisect_test.py, copy_from_large_benchmark.txt, 
> copy_from_large_benchmark_2.txt, parent_profile.txt, parent_profile_2.txt, 
> worker_profiles.txt, worker_profiles_2.txt
>
>
> h5. Description
> Running COPY from on a large dataset (20G divided in 20M records) revealed 
> two issues:
> * The progress report is incorrect, it is very slow until almost the end of 
> the test at which point it catches up extremely quickly.
> * The performance in rows per second is similar to running smaller tests with 
> a smaller cluster locally (approx 35,000 rows per second). As a comparison, 
> cassandra-stress manages 50,000 rows per second under the same set-up, 
> therefore resulting 1.5 times faster. 
> See attached file _copy_from_large_benchmark.txt_ for the benchmark details.
> h5. Doc-impacting changes to COPY FROM options
> * A new option was added: PREPAREDSTATEMENTS - it indicates if prepared 
> statements should be used; it defaults to true.
> * The default value of CHUNKSIZE changed from 1000 to 5000.
> * The default value of MINBATCHSIZE changed from 2 to 10.



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

[jira] [Updated] (CASSANDRA-11381) Node running with join_ring=false and authentication can not serve requests

[mck (JIRA)]

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

mck updated CASSANDRA-11381:

Reproduced In: 2.0.16
   Status: Patch Available  (was: In Progress)

> Node running with join_ring=false and authentication can not serve requests
> ---
>
> Key: CASSANDRA-11381
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11381
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mck
>Assignee: mck
> Attachments: 11381-2.0.txt, 11381-2.1.txt, 11381-2.2.txt, 
> 11381-3.0.txt, 11381-trunk.txt, dtest-11381-trunk.txt
>
>
> Starting up a node with {{-Dcassandra.join_ring=false}} in a cluster that has 
> authentication configured, eg PasswordAuthenticator, won't be able to serve 
> requests. This is because {{Auth.setup()}} never gets called during the 
> startup.
> Without {{Auth.setup()}} having been called in {{StorageService}} clients 
> connecting to the node fail with the node throwing
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:119)
> at 
> org.apache.cassandra.thrift.CassandraServer.login(CassandraServer.java:1471)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3505)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3489)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
> at 
> com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:695)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:689)
> at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The exception thrown from the 
> [code|https://github.com/apache/cassandra/blob/cassandra-2.0.16/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java#L119]
> {code}
> ResultMessage.Rows rows = 
> authenticateStatement.execute(QueryState.forInternalCalls(), new 
> QueryOptions(consistencyForUser(username),
>   
>Lists.newArrayList(ByteBufferUtil.bytes(username;
> {code}



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

[jira] [Commented] (CASSANDRA-11381) Node running with join_ring=false and authentication can not serve requests

[mck (JIRA)]

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

mck commented on CASSANDRA-11381:
-

[~JoshuaMcKenzie], the dtest is attached.

> Node running with join_ring=false and authentication can not serve requests
> ---
>
> Key: CASSANDRA-11381
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11381
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mck
>Assignee: mck
> Attachments: 11381-2.0.txt, 11381-2.1.txt, 11381-2.2.txt, 
> 11381-3.0.txt, 11381-trunk.txt, dtest-11381-trunk.txt
>
>
> Starting up a node with {{-Dcassandra.join_ring=false}} in a cluster that has 
> authentication configured, eg PasswordAuthenticator, won't be able to serve 
> requests. This is because {{Auth.setup()}} never gets called during the 
> startup.
> Without {{Auth.setup()}} having been called in {{StorageService}} clients 
> connecting to the node fail with the node throwing
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:119)
> at 
> org.apache.cassandra.thrift.CassandraServer.login(CassandraServer.java:1471)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3505)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3489)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
> at 
> com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:695)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:689)
> at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The exception thrown from the 
> [code|https://github.com/apache/cassandra/blob/cassandra-2.0.16/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java#L119]
> {code}
> ResultMessage.Rows rows = 
> authenticateStatement.execute(QueryState.forInternalCalls(), new 
> QueryOptions(consistencyForUser(username),
>   
>Lists.newArrayList(ByteBufferUtil.bytes(username;
> {code}



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

[jira] [Updated] (CASSANDRA-11381) Node running with join_ring=false and authentication can not serve requests

[mck (JIRA)]

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

mck updated CASSANDRA-11381:

Attachment: dtest-11381-trunk.txt

> Node running with join_ring=false and authentication can not serve requests
> ---
>
> Key: CASSANDRA-11381
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11381
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mck
>Assignee: mck
> Attachments: 11381-2.0.txt, 11381-2.1.txt, 11381-2.2.txt, 
> 11381-3.0.txt, 11381-trunk.txt, dtest-11381-trunk.txt
>
>
> Starting up a node with {{-Dcassandra.join_ring=false}} in a cluster that has 
> authentication configured, eg PasswordAuthenticator, won't be able to serve 
> requests. This is because {{Auth.setup()}} never gets called during the 
> startup.
> Without {{Auth.setup()}} having been called in {{StorageService}} clients 
> connecting to the node fail with the node throwing
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:119)
> at 
> org.apache.cassandra.thrift.CassandraServer.login(CassandraServer.java:1471)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3505)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3489)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
> at 
> com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:695)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:689)
> at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The exception thrown from the 
> [code|https://github.com/apache/cassandra/blob/cassandra-2.0.16/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java#L119]
> {code}
> ResultMessage.Rows rows = 
> authenticateStatement.execute(QueryState.forInternalCalls(), new 
> QueryOptions(consistencyForUser(username),
>   
>Lists.newArrayList(ByteBufferUtil.bytes(username;
> {code}



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

[jira] [Updated] (CASSANDRA-11381) Node running with join_ring=false and authentication can not serve requests

[mck (JIRA)]

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

mck updated CASSANDRA-11381:

Attachment: (was: dtest-11381-trunk.txt)

> Node running with join_ring=false and authentication can not serve requests
> ---
>
> Key: CASSANDRA-11381
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11381
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mck
>Assignee: mck
> Attachments: 11381-2.0.txt, 11381-2.1.txt, 11381-2.2.txt, 
> 11381-3.0.txt, 11381-trunk.txt
>
>
> Starting up a node with {{-Dcassandra.join_ring=false}} in a cluster that has 
> authentication configured, eg PasswordAuthenticator, won't be able to serve 
> requests. This is because {{Auth.setup()}} never gets called during the 
> startup.
> Without {{Auth.setup()}} having been called in {{StorageService}} clients 
> connecting to the node fail with the node throwing
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:119)
> at 
> org.apache.cassandra.thrift.CassandraServer.login(CassandraServer.java:1471)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3505)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3489)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
> at 
> com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:695)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:689)
> at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The exception thrown from the 
> [code|https://github.com/apache/cassandra/blob/cassandra-2.0.16/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java#L119]
> {code}
> ResultMessage.Rows rows = 
> authenticateStatement.execute(QueryState.forInternalCalls(), new 
> QueryOptions(consistencyForUser(username),
>   
>Lists.newArrayList(ByteBufferUtil.bytes(username;
> {code}



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

[jira] [Updated] (CASSANDRA-11381) Node running with join_ring=false and authentication can not serve requests

[mck (JIRA)]

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

mck updated CASSANDRA-11381:

Attachment: dtest-11381-trunk.txt

> Node running with join_ring=false and authentication can not serve requests
> ---
>
> Key: CASSANDRA-11381
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11381
> Project: Cassandra
>  Issue Type: Bug
>Reporter: mck
>Assignee: mck
> Attachments: 11381-2.0.txt, 11381-2.1.txt, 11381-2.2.txt, 
> 11381-3.0.txt, 11381-trunk.txt, dtest-11381-trunk.txt
>
>
> Starting up a node with {{-Dcassandra.join_ring=false}} in a cluster that has 
> authentication configured, eg PasswordAuthenticator, won't be able to serve 
> requests. This is because {{Auth.setup()}} never gets called during the 
> startup.
> Without {{Auth.setup()}} having been called in {{StorageService}} clients 
> connecting to the node fail with the node throwing
> {noformat}
> java.lang.NullPointerException
> at 
> org.apache.cassandra.auth.PasswordAuthenticator.authenticate(PasswordAuthenticator.java:119)
> at 
> org.apache.cassandra.thrift.CassandraServer.login(CassandraServer.java:1471)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3505)
> at 
> org.apache.cassandra.thrift.Cassandra$Processor$login.getResult(Cassandra.java:3489)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
> at 
> com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:695)
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:689)
> at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The exception thrown from the 
> [code|https://github.com/apache/cassandra/blob/cassandra-2.0.16/src/java/org/apache/cassandra/auth/PasswordAuthenticator.java#L119]
> {code}
> ResultMessage.Rows rows = 
> authenticateStatement.execute(QueryState.forInternalCalls(), new 
> QueryOptions(consistencyForUser(username),
>   
>Lists.newArrayList(ByteBufferUtil.bytes(username;
> {code}



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

[jira] [Commented] (CASSANDRA-11053) COPY FROM on large datasets: fix progress report and debug performance

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-11053:
--

Thank you Adam. I've rebased, squashed and restarted CI. I will change the 
status to ready to commit if CI is OK.

> COPY FROM on large datasets: fix progress report and debug performance
> --
>
> Key: CASSANDRA-11053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11053
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Stefania
>Assignee: Stefania
>  Labels: doc-impacting
> Fix For: 2.1.14, 2.2.6, 3.0.5, 3.5
>
> Attachments: bisect_test.py, copy_from_large_benchmark.txt, 
> copy_from_large_benchmark_2.txt, parent_profile.txt, parent_profile_2.txt, 
> worker_profiles.txt, worker_profiles_2.txt
>
>
> h5. Description
> Running COPY from on a large dataset (20G divided in 20M records) revealed 
> two issues:
> * The progress report is incorrect, it is very slow until almost the end of 
> the test at which point it catches up extremely quickly.
> * The performance in rows per second is similar to running smaller tests with 
> a smaller cluster locally (approx 35,000 rows per second). As a comparison, 
> cassandra-stress manages 50,000 rows per second under the same set-up, 
> therefore resulting 1.5 times faster. 
> See attached file _copy_from_large_benchmark.txt_ for the benchmark details.
> h5. Doc-impacting changes to COPY FROM options
> * A new option was added: PREPAREDSTATEMENTS - it indicates if prepared 
> statements should be used; it defaults to true.
> * The default value of CHUNKSIZE changed from 1000 to 5000.
> * The default value of MINBATCHSIZE changed from 2 to 10.



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

[jira] [Updated] (CASSANDRA-11408) simple compaction defaults for common scenarios

[Jonathan Shook (JIRA)]

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

Jonathan Shook updated CASSANDRA-11408:
---
Description: 
As compaction strategies get more flexible over time, some users might prefer 
to have a simple named profile for their settings.

{code:title=example, syntax variant|borderStyle=solid}
alter table foo.bar with compaction = 'timeseries-hourly-for-a-week';
{code}

{code:title=example, syntax variant |borderStyle=solid}
alter table foo.bar with compaction = { 'profile' : 'key-value-balanced-ops' };
{code}

These would simply be a map into sets of well-tested and documented defaults 
across any of the core compaction strategies.

This would simplify setting up compaction for well-understood workloads, but 
still allow for customization where desired.



  was:
As compaction strategies get more flexible over time, some users might prefer 
to have a simple named profile for their settings.

For example,
alter table foo.bar with compaction = 'timeseries-hourly-for-a-week';
or, with slightly different syntax:
alter table foo.bar with compaction = { 'profile' : 'key-value-balanced-ops' };

These would simply be a map into sets of well-tested and documented defaults 
across any of the core compaction strategies.

This would simplify setting up compaction for well-understood workloads, but 
still allow for customization where desired.




> simple compaction defaults for common scenarios
> ---
>
> Key: CASSANDRA-11408
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11408
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Core
>Reporter: Jonathan Shook
>
> As compaction strategies get more flexible over time, some users might prefer 
> to have a simple named profile for their settings.
> {code:title=example, syntax variant|borderStyle=solid}
> alter table foo.bar with compaction = 'timeseries-hourly-for-a-week';
> {code}
> {code:title=example, syntax variant |borderStyle=solid}
> alter table foo.bar with compaction = { 'profile' : 'key-value-balanced-ops' 
> };
> {code}
> These would simply be a map into sets of well-tested and documented defaults 
> across any of the core compaction strategies.
> This would simplify setting up compaction for well-understood workloads, but 
> still allow for customization where desired.



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

[jira] [Created] (CASSANDRA-11408) simple compaction defaults for common scenarios

[Jonathan Shook (JIRA)]

Jonathan Shook created CASSANDRA-11408:
--

 Summary: simple compaction defaults for common scenarios
 Key: CASSANDRA-11408
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11408
 Project: Cassandra
  Issue Type: Improvement
  Components: Core
Reporter: Jonathan Shook


As compaction strategies get more flexible over time, some users might prefer 
to have a simple named profile for their settings.

For example,
alter table foo.bar with compaction = 'timeseries-hourly-for-a-week';
or, with slightly different syntax:
alter table foo.bar with compaction = { 'profile' : 'key-value-balanced-ops' };

These would simply be a map into sets of well-tested and documented defaults 
across any of the core compaction strategies.

This would simplify setting up compaction for well-understood workloads, but 
still allow for customization where desired.





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

[jira] [Commented] (CASSANDRA-11396) dtest failure in upgrade_tests.cql_tests.TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD.collection_flush_test

[Russ Hatch (JIRA)]

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

Russ Hatch commented on CASSANDRA-11396:


fix here https://github.com/riptano/cassandra-dtest/pull/883

> dtest failure in 
> upgrade_tests.cql_tests.TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD.collection_flush_test
> -
>
> Key: CASSANDRA-11396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11396
> Project: Cassandra
>  Issue Type: Test
>  Components: Testing
>Reporter: Philip Thompson
>Assignee: Russ Hatch
>  Labels: dtest
>
> example failure:
> {code}
> 
> {code}
> http://cassci.datastax.com/job/upgrade_tests-all/25/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD/collection_flush_test
> Failed on CassCI build upgrade_tests-all #25
> It's an inconsistent failure that happens across a number of tests. I'll 
> include all the ones I find here.
> http://cassci.datastax.com/job/upgrade_tests-all/26/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_1_UpTo_2_2_HEAD/static_with_limit_test/
> http://cassci.datastax.com/job/upgrade_tests-all/28/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_2_2_HEAD_UpTo_Trunk/test_data_change_impacting_later_page/
> http://cassci.datastax.com/job/upgrade_tests-all/29/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_1_UpTo_Trunk/range_key_ordered_test/



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

[jira] [Updated] (CASSANDRA-11396) dtest failure in upgrade_tests.cql_tests.TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD.collection_flush_test

[Russ Hatch (JIRA)]

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

Russ Hatch updated CASSANDRA-11396:
---
Reviewer: Jim Witschey
  Status: Patch Available  (was: Open)

> dtest failure in 
> upgrade_tests.cql_tests.TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD.collection_flush_test
> -
>
> Key: CASSANDRA-11396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11396
> Project: Cassandra
>  Issue Type: Test
>  Components: Testing
>Reporter: Philip Thompson
>Assignee: Russ Hatch
>  Labels: dtest
>
> example failure:
> {code}
> 
> {code}
> http://cassci.datastax.com/job/upgrade_tests-all/25/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD/collection_flush_test
> Failed on CassCI build upgrade_tests-all #25
> It's an inconsistent failure that happens across a number of tests. I'll 
> include all the ones I find here.
> http://cassci.datastax.com/job/upgrade_tests-all/26/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_1_UpTo_2_2_HEAD/static_with_limit_test/
> http://cassci.datastax.com/job/upgrade_tests-all/28/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_2_2_HEAD_UpTo_Trunk/test_data_change_impacting_later_page/
> http://cassci.datastax.com/job/upgrade_tests-all/29/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_1_UpTo_Trunk/range_key_ordered_test/



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

[jira] [Commented] (CASSANDRA-11396) dtest failure in upgrade_tests.cql_tests.TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD.collection_flush_test

[Russ Hatch (JIRA)]

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

Russ Hatch commented on CASSANDRA-11396:


with patch above, 500 runs without error.

> dtest failure in 
> upgrade_tests.cql_tests.TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD.collection_flush_test
> -
>
> Key: CASSANDRA-11396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11396
> Project: Cassandra
>  Issue Type: Test
>  Components: Testing
>Reporter: Philip Thompson
>Assignee: Russ Hatch
>  Labels: dtest
>
> example failure:
> {code}
> 
> {code}
> http://cassci.datastax.com/job/upgrade_tests-all/25/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD/collection_flush_test
> Failed on CassCI build upgrade_tests-all #25
> It's an inconsistent failure that happens across a number of tests. I'll 
> include all the ones I find here.
> http://cassci.datastax.com/job/upgrade_tests-all/26/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_1_UpTo_2_2_HEAD/static_with_limit_test/
> http://cassci.datastax.com/job/upgrade_tests-all/28/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_2_2_HEAD_UpTo_Trunk/test_data_change_impacting_later_page/
> http://cassci.datastax.com/job/upgrade_tests-all/29/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_1_UpTo_Trunk/range_key_ordered_test/



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

[jira] [Updated] (CASSANDRA-11407) Proposal for simplified DTCS

[Jeff Jirsa (JIRA)]

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

Jeff Jirsa updated CASSANDRA-11407:
---
Labels: dtcs  (was: )

> Proposal for simplified DTCS
> 
>
> Key: CASSANDRA-11407
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11407
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Anubhav Kale
>  Labels: dtcs
> Attachments: 0001-Simple-DTCS.patch
>
>
> Today's DTCS implementation has been discussed and debated in a few JIRAs 
> already (the notable one is 
> https://issues.apache.org/jira/browse/CASSANDRA-9666). One of the main 
> challenges with the current approach is that it is very difficult to reason 
> about how the "Target" class makes buckets, thus making it difficult to 
> reason about the expected file layout on disk.
> I am proposing a simplification to current approach that keeps most of the 
> DTCS properties intact that makes it a great fit for time-series data. The 
> simplification is as follows.
> Given the min and max timestamps across all SS Tables in question, start from 
> min and make windows based on base and min_threshold. The logic in GetWindow 
> simply tries to fit maximum sized windows from min to max. 
> This keeps the DTCS properties intact except that we don't need to wait for 
> min_threshold windows before making a bigger one. I would argue this 
> simplifies the algorithm to a great extent, is easy to reason about and the 
> end result isn't drastically different than the original DTCS in most cases. 
> We give up on the "alignment" logic that exists in current implementation, 
> but I honestly don't think it buys us a lot besides complexity.
> The implementation can obviously be optimized and cleaned up more if folks 
> think this is a good idea. 



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

[jira] [Commented] (CASSANDRA-11406) Include Seed Node information in nodetool info

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-11406:
-

One small wrinkle to this is that each node can have a different set of seeds. 
While not common, there is nothing that requires all nodes to have the same 
seeds. 



> Include Seed Node information in nodetool info
> --
>
> Key: CASSANDRA-11406
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11406
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Sam Goldberg
>
> It would be helpful to include information on seed node status in the output 
> of nodetool info.
> The intent is to save the trouble of going into the cassandra.yaml to verify 
> seed node status. 



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

[jira] [Comment Edited] (CASSANDRA-9348) Nodetool move output should be more user friendly if bad token is supplied

[Abhishek Verma (JIRA)]

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

Abhishek Verma edited comment on CASSANDRA-9348 at 3/22/16 10:42 PM:
-

Thanks Joel! I have closed my pull request, submitted the patch file and 
assigned the issue to myself.

Also, here is a link to the GitHub branch: 
https://github.com/verma7/cassandra/tree/9348-trunk


was (Author: verma7):
Thanks Joel! I have closed my pull request and submitted the patch file and 
assigned the issue to myself.

Also, here is a link to the GitHub branch: 
https://github.com/verma7/cassandra/tree/9348-trunk

> Nodetool move output should be more user friendly if bad token is supplied
> --
>
> Key: CASSANDRA-9348
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9348
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sequoyha pelletier
>Assignee: Abhishek Verma
>Priority: Trivial
>  Labels: lhf
> Attachments: CASSANDRA-9348.txt
>
>
> If you put a token into nodetool move that is out of range for the 
> partitioner you get the following error:
> {noformat}
> [architect@md03-gcsarch-lapp33 11:01:06 ]$ nodetool -h 10.11.48.229 -u 
> cassandra -pw cassandra move \\-9223372036854775809 
> Exception in thread "main" java.io.IOException: For input string: 
> "-9223372036854775809" 
> at org.apache.cassandra.service.StorageService.move(StorageService.java:3104) 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75) 
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279) 
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
>  
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
>  
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) 
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) 
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) 
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
>  
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) 
> at 
> com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:468)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
>  
> at java.security.AccessController.doPrivileged(Native Method) 
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1427)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
>  
> at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) 
> at sun.rmi.transport.Transport$1.run(Transport.java:177) 
> at sun.rmi.transport.Transport$1.run(Transport.java:174) 
> at java.security.AccessController.doPrivileged(Native Method) 
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173) 
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556) 
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
>  
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  
> at java.lang.Thread.run(Thread.java:745) 
> {noformat}
> This ticket is just requesting that we catch the exception an output 
> something along the lines of "Token supplied is outside of the acceptable 
> range" for those that are still in the Cassandra learning curve.



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

[jira] [Updated] (CASSANDRA-11407) Proposal for simplified DTCS

[Anubhav Kale (JIRA)]

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

Anubhav Kale updated CASSANDRA-11407:
-
Description: 
Today's DTCS implementation has been discussed and debated in a few JIRAs 
already (the notable one is 
https://issues.apache.org/jira/browse/CASSANDRA-9666). One of the main 
challenges with the current approach is that it is very difficult to reason 
about how the "Target" class makes buckets, thus making it difficult to reason 
about the expected file layout on disk.

I am proposing a simplification to current approach that keeps most of the DTCS 
properties intact that makes it a great fit for time-series data. The 
simplification is as follows.

Given the min and max timestamps across all SS Tables in question, start from 
min and make windows based on base and min_threshold. The logic in GetWindow 
simply tries to fit maximum sized windows from min to max. 

This keeps the DTCS properties intact except that we don't need to wait for 
min_threshold windows before making a bigger one. I would argue this simplifies 
the algorithm to a great extent, is easy to reason about and the end result 
isn't drastically different than the original DTCS in most cases. We give up on 
the "alignment" logic that exists in current implementation, but I honestly 
don't think it buys us a lot besides complexity.

The implementation can obviously be optimized and cleaned up more if folks 
think this is a good idea. 






  was:
Today's DTCS implementation has been discussed and debated in a few JIRAs 
already (the notable one is 
https://issues.apache.org/jira/browse/CASSANDRA-9666). One of the main 
challenges with the current approach is that it is very difficult to reason 
about how the "Target" class makes buckets, thus making it difficult to reason 
about the expected file layout on disk.

I am proposing a simplification to current approach that keeps most of the DTCS 
properties intact that makes it a great fit for time-series data. The 
simplification is as follows.

Given the min and max timestamps across all SS Tables in question, start from 
min and make windows based on base and min_threshold. The logic in GetWindow 
simply tries to fit maximum sized windows from min to max. 

This keeps the DTCS properties intact except that we don't need to wait for 
min_threshold windows before making a bigger one. I would argue this simplifies 
the algorithm to a great extent, is easy to reason about and the end result 
isn't drastically different than the original DTCS in most cases. We give up on 
the "alignment" logic in current class, but I honestly don't think it buys us a 
lot besides complexity.

The implementation can obviously be optimized and cleaned up more if folks 
think this is a good idea. 







> Proposal for simplified DTCS
> 
>
> Key: CASSANDRA-11407
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11407
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Anubhav Kale
> Attachments: 0001-Simple-DTCS.patch
>
>
> Today's DTCS implementation has been discussed and debated in a few JIRAs 
> already (the notable one is 
> https://issues.apache.org/jira/browse/CASSANDRA-9666). One of the main 
> challenges with the current approach is that it is very difficult to reason 
> about how the "Target" class makes buckets, thus making it difficult to 
> reason about the expected file layout on disk.
> I am proposing a simplification to current approach that keeps most of the 
> DTCS properties intact that makes it a great fit for time-series data. The 
> simplification is as follows.
> Given the min and max timestamps across all SS Tables in question, start from 
> min and make windows based on base and min_threshold. The logic in GetWindow 
> simply tries to fit maximum sized windows from min to max. 
> This keeps the DTCS properties intact except that we don't need to wait for 
> min_threshold windows before making a bigger one. I would argue this 
> simplifies the algorithm to a great extent, is easy to reason about and the 
> end result isn't drastically different than the original DTCS in most cases. 
> We give up on the "alignment" logic that exists in current implementation, 
> but I honestly don't think it buys us a lot besides complexity.
> The implementation can obviously be optimized and cleaned up more if folks 
> think this is a good idea. 



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

[jira] [Created] (CASSANDRA-11407) Proposal for a simple DTCS

[Anubhav Kale (JIRA)]

Anubhav Kale created CASSANDRA-11407:


 Summary: Proposal for a simple DTCS
 Key: CASSANDRA-11407
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11407
 Project: Cassandra
  Issue Type: Improvement
  Components: Compaction
Reporter: Anubhav Kale
 Attachments: 0001-Simple-DTCS.patch

Today's DTCS implementation has been discussed and debated in a few JIRAs 
already (the notable one is 
https://issues.apache.org/jira/browse/CASSANDRA-9666). One of the main 
challenges with the current approach is that it is very difficult to reason 
about how the "Target" class makes buckets, thus making it difficult to reason 
about the expected file layout on disk.

I am proposing a simplification to current approach that keeps most of the DTCS 
properties intact that makes it a great fit for time-series data. The 
simplification is as follows.

Given the min and max timestamps across all SS Tables in question, start from 
min and make windows based on base and min_threshold. The logic in GetWindow 
simply tries to fit maximum sized windows from min to max. 

This keeps the DTCS properties intact except that we don't need to wait for 
min_threshold windows before making a bigger one. I would argue this simplifies 
the algorithm to a great extent, is easy to reason about and the end result 
isn't drastically different than the original DTCS in most cases. We give up on 
the "alignment" logic in current class, but I honestly don't think it buys us a 
lot besides complexity.

The implementation can obviously be optimized and cleaned up more if folks 
think this is a good idea. 








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

[jira] [Updated] (CASSANDRA-11407) Proposal for simplified DTCS

[Anubhav Kale (JIRA)]

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

Anubhav Kale updated CASSANDRA-11407:
-
Summary: Proposal for simplified DTCS  (was: Proposal for a simple DTCS)

> Proposal for simplified DTCS
> 
>
> Key: CASSANDRA-11407
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11407
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Compaction
>Reporter: Anubhav Kale
> Attachments: 0001-Simple-DTCS.patch
>
>
> Today's DTCS implementation has been discussed and debated in a few JIRAs 
> already (the notable one is 
> https://issues.apache.org/jira/browse/CASSANDRA-9666). One of the main 
> challenges with the current approach is that it is very difficult to reason 
> about how the "Target" class makes buckets, thus making it difficult to 
> reason about the expected file layout on disk.
> I am proposing a simplification to current approach that keeps most of the 
> DTCS properties intact that makes it a great fit for time-series data. The 
> simplification is as follows.
> Given the min and max timestamps across all SS Tables in question, start from 
> min and make windows based on base and min_threshold. The logic in GetWindow 
> simply tries to fit maximum sized windows from min to max. 
> This keeps the DTCS properties intact except that we don't need to wait for 
> min_threshold windows before making a bigger one. I would argue this 
> simplifies the algorithm to a great extent, is easy to reason about and the 
> end result isn't drastically different than the original DTCS in most cases. 
> We give up on the "alignment" logic in current class, but I honestly don't 
> think it buys us a lot besides complexity.
> The implementation can obviously be optimized and cleaned up more if folks 
> think this is a good idea. 



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

[jira] [Commented] (CASSANDRA-9348) Nodetool move output should be more user friendly if bad token is supplied

[Abhishek Verma (JIRA)]

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

Abhishek Verma commented on CASSANDRA-9348:
---

Thanks Joel! I have closed my pull request and submitted the patch file and 
assigned the issue to myself.

Also, here is a link to the GitHub branch: 
https://github.com/verma7/cassandra/tree/9348-trunk

> Nodetool move output should be more user friendly if bad token is supplied
> --
>
> Key: CASSANDRA-9348
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9348
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sequoyha pelletier
>Assignee: Abhishek Verma
>Priority: Trivial
>  Labels: lhf
> Attachments: CASSANDRA-9348.txt
>
>
> If you put a token into nodetool move that is out of range for the 
> partitioner you get the following error:
> {noformat}
> [architect@md03-gcsarch-lapp33 11:01:06 ]$ nodetool -h 10.11.48.229 -u 
> cassandra -pw cassandra move \\-9223372036854775809 
> Exception in thread "main" java.io.IOException: For input string: 
> "-9223372036854775809" 
> at org.apache.cassandra.service.StorageService.move(StorageService.java:3104) 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75) 
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279) 
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
>  
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
>  
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) 
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) 
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) 
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
>  
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) 
> at 
> com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:468)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
>  
> at java.security.AccessController.doPrivileged(Native Method) 
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1427)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
>  
> at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) 
> at sun.rmi.transport.Transport$1.run(Transport.java:177) 
> at sun.rmi.transport.Transport$1.run(Transport.java:174) 
> at java.security.AccessController.doPrivileged(Native Method) 
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173) 
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556) 
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
>  
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  
> at java.lang.Thread.run(Thread.java:745) 
> {noformat}
> This ticket is just requesting that we catch the exception an output 
> something along the lines of "Token supplied is outside of the acceptable 
> range" for those that are still in the Cassandra learning curve.



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

[jira] [Updated] (CASSANDRA-9348) Nodetool move output should be more user friendly if bad token is supplied

[Abhishek Verma (JIRA)]

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

Abhishek Verma updated CASSANDRA-9348:
--
Assignee: Abhishek Verma
  Status: Patch Available  (was: Open)

> Nodetool move output should be more user friendly if bad token is supplied
> --
>
> Key: CASSANDRA-9348
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9348
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sequoyha pelletier
>Assignee: Abhishek Verma
>Priority: Trivial
>  Labels: lhf
> Attachments: CASSANDRA-9348.txt
>
>
> If you put a token into nodetool move that is out of range for the 
> partitioner you get the following error:
> {noformat}
> [architect@md03-gcsarch-lapp33 11:01:06 ]$ nodetool -h 10.11.48.229 -u 
> cassandra -pw cassandra move \\-9223372036854775809 
> Exception in thread "main" java.io.IOException: For input string: 
> "-9223372036854775809" 
> at org.apache.cassandra.service.StorageService.move(StorageService.java:3104) 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75) 
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279) 
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
>  
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
>  
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) 
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) 
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) 
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
>  
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) 
> at 
> com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:468)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
>  
> at java.security.AccessController.doPrivileged(Native Method) 
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1427)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
>  
> at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) 
> at sun.rmi.transport.Transport$1.run(Transport.java:177) 
> at sun.rmi.transport.Transport$1.run(Transport.java:174) 
> at java.security.AccessController.doPrivileged(Native Method) 
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173) 
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556) 
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
>  
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  
> at java.lang.Thread.run(Thread.java:745) 
> {noformat}
> This ticket is just requesting that we catch the exception an output 
> something along the lines of "Token supplied is outside of the acceptable 
> range" for those that are still in the Cassandra learning curve.



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

[jira] [Updated] (CASSANDRA-9348) Nodetool move output should be more user friendly if bad token is supplied

[Abhishek Verma (JIRA)]

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

Abhishek Verma updated CASSANDRA-9348:
--
Attachment: CASSANDRA-9348.txt

> Nodetool move output should be more user friendly if bad token is supplied
> --
>
> Key: CASSANDRA-9348
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9348
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sequoyha pelletier
>Priority: Trivial
>  Labels: lhf
> Attachments: CASSANDRA-9348.txt
>
>
> If you put a token into nodetool move that is out of range for the 
> partitioner you get the following error:
> {noformat}
> [architect@md03-gcsarch-lapp33 11:01:06 ]$ nodetool -h 10.11.48.229 -u 
> cassandra -pw cassandra move \\-9223372036854775809 
> Exception in thread "main" java.io.IOException: For input string: 
> "-9223372036854775809" 
> at org.apache.cassandra.service.StorageService.move(StorageService.java:3104) 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75) 
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279) 
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
>  
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
>  
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) 
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) 
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) 
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
>  
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) 
> at 
> com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:468)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
>  
> at java.security.AccessController.doPrivileged(Native Method) 
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1427)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
>  
> at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) 
> at sun.rmi.transport.Transport$1.run(Transport.java:177) 
> at sun.rmi.transport.Transport$1.run(Transport.java:174) 
> at java.security.AccessController.doPrivileged(Native Method) 
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173) 
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556) 
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
>  
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  
> at java.lang.Thread.run(Thread.java:745) 
> {noformat}
> This ticket is just requesting that we catch the exception an output 
> something along the lines of "Token supplied is outside of the acceptable 
> range" for those that are still in the Cassandra learning curve.



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

[jira] [Created] (CASSANDRA-11406) Include Seed Node information in nodetool info

[Sam Goldberg (JIRA)]

Sam Goldberg created CASSANDRA-11406:


 Summary: Include Seed Node information in nodetool info
 Key: CASSANDRA-11406
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11406
 Project: Cassandra
  Issue Type: Improvement
Reporter: Sam Goldberg


It would be helpful to include information on seed node status in the output of 
nodetool info.

The intent is to save the trouble of going into the cassandra.yaml to verify 
seed node status. 



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

[jira] [Commented] (CASSANDRA-9935) Repair fails with RuntimeException

[Ruoran Wang (JIRA)]

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

Ruoran Wang commented on CASSANDRA-9935:


Yes, I am able to reproduce with new keyspace.
{noformat}
CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': '3'}  AND durable_writes = true;

CREATE TABLE test.ui_by_modification (
bucket int,
modified_hour timestamp,
user_id bigint,
challenge_id uuid,
created timestamp,
creator_user_id bigint,
type int,
PRIMARY KEY ((bucket, modified_hour), user_id, challenge_id)
) WITH CLUSTERING ORDER BY (user_id ASC, challenge_id ASC)
AND bloom_filter_fp_chance = 0.1
AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
AND comment = ''
AND compaction = {'class': 
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
AND compression = {'sstable_compression': 
'org.apache.cassandra.io.compress.LZ4Compressor'}
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 604800
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 = '99.0PERCENTILE';
{noformat}

Then I am generating data using
{noformat}
Long creatorId = (long) random.nextInt(1);

UUID uuid = UUID_GENERATOR.generate();
int type = random.nextInt(10);
getIdCache().put(creatorId, uuid);

Date date = DateTime.now(DateTimeZone.UTC).toDate();

try {

runQuery(
"insert into test.ui_by_modification(bucket, modified_hour, 
user_id, challenge_id, created, creator_user_id, type) VALUES (?, ?, ?, ?, ?, 
?, ?)",
new Random().nextInt(1024), date, creatorId, 
UUID_GENERATOR.generate(), date, creatorId, type
);

} catch (Exception e) {
log.error("error", e);
}
{noformat}

I insert ~200 per second. Then I start first round of incremental repairs, 
repair -pr -par --in-local-dc -inc -- test, on this 6 nodes in the cluster. 
Then I waited ~1.5 hour then run the same inc repair, and then I got the same 
error. 
I think there is a correlation between the composite partition key and this 
error.

> Repair fails with RuntimeException
> --
>
> Key: CASSANDRA-9935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9935
> Project: Cassandra
>  Issue Type: Bug
> Environment: C* 2.1.8, Debian Wheezy
>Reporter: mlowicki
>Assignee: Yuki Morishita
> Fix For: 2.1.x
>
> Attachments: db1.sync.lati.osa.cassandra.log, 
> db5.sync.lati.osa.cassandra.log, system.log.10.210.3.117, 
> system.log.10.210.3.221, system.log.10.210.3.230
>
>
> We had problems with slow repair in 2.1.7 (CASSANDRA-9702) but after upgrade 
> to 2.1.8 it started to work faster but now it fails with:
> {code}
> ...
> [2015-07-29 20:44:03,956] Repair session 23a811b0-3632-11e5-a93e-4963524a8bde 
> for range (-5474076923322749342,-5468600594078911162] finished
> [2015-07-29 20:44:03,957] Repair session 336f8740-3632-11e5-a93e-4963524a8bde 
> for range (-8631877858109464676,-8624040066373718932] finished
> [2015-07-29 20:44:03,957] Repair session 4ccd8430-3632-11e5-a93e-4963524a8bde 
> for range (-5372806541854279315,-5369354119480076785] finished
> [2015-07-29 20:44:03,957] Repair session 59f129f0-3632-11e5-a93e-4963524a8bde 
> for range (8166489034383821955,8168408930184216281] finished
> [2015-07-29 20:44:03,957] Repair session 6ae7a9a0-3632-11e5-a93e-4963524a8bde 
> for range (6084602890817326921,6088328703025510057] finished
> [2015-07-29 20:44:03,957] Repair session 8938e4a0-3632-11e5-a93e-4963524a8bde 
> for range (-781874602493000830,-781745173070807746] finished
> [2015-07-29 20:44:03,957] Repair command #4 finished
> error: nodetool failed, check server logs
> -- StackTrace --
> java.lang.RuntimeException: nodetool failed, check server logs
> at 
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:290)
> at org.apache.cassandra.tools.NodeTool.main(NodeTool.java:202)
> {code}
> After running:
> {code}
> nodetool repair --partitioner-range --parallel --in-local-dc sync
> {code}
> Last records in logs regarding repair are:
> {code}
> INFO  [Thread-173887] 2015-07-29 20:44:03,956 StorageService.java:2952 - 
> Repair session 09ff9e40-3632-11e5-a93e-4963524a8bde for range 
> (-7695808664784761779,-7693529816291585568] finished
> INFO  [Thread-173887] 2015-07-29 20:44:03,956 StorageService.java:2952 - 
> Repair session 17d8d860-3632-11e5-a93e-4963524a8bde for range 
> (806371695398849,8065203836608925992] finished
> INFO  [Thread-173887] 2015-07-29 20:44:03,956 StorageService.java:2952 - 
> Repair 

[jira] [Commented] (CASSANDRA-11396) dtest failure in upgrade_tests.cql_tests.TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD.collection_flush_test

[Russ Hatch (JIRA)]

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

Russ Hatch commented on CASSANDRA-11396:


sounds like the problem might be due to running truncate several times in quick 
succession, or perhaps it's that an upgraded node is occasionally still 
settling before when the first truncate is issued. A small amount of pause 
might be the fix, trying that out here: 
http://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/37/

> dtest failure in 
> upgrade_tests.cql_tests.TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD.collection_flush_test
> -
>
> Key: CASSANDRA-11396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11396
> Project: Cassandra
>  Issue Type: Test
>  Components: Testing
>Reporter: Philip Thompson
>Assignee: Russ Hatch
>  Labels: dtest
>
> example failure:
> {code}
> 
> {code}
> http://cassci.datastax.com/job/upgrade_tests-all/25/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD/collection_flush_test
> Failed on CassCI build upgrade_tests-all #25
> It's an inconsistent failure that happens across a number of tests. I'll 
> include all the ones I find here.
> http://cassci.datastax.com/job/upgrade_tests-all/26/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_1_UpTo_2_2_HEAD/static_with_limit_test/
> http://cassci.datastax.com/job/upgrade_tests-all/28/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_2_2_HEAD_UpTo_Trunk/test_data_change_impacting_later_page/
> http://cassci.datastax.com/job/upgrade_tests-all/29/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_1_UpTo_Trunk/range_key_ordered_test/



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

[jira] [Commented] (CASSANDRA-9348) Nodetool move output should be more user friendly if bad token is supplied

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-9348:
--

Thanks [~verma7] - the steps on how to contribute to Cassandra are available on 
the [wiki|https://wiki.apache.org/cassandra/HowToContribute].

Notably, we don't use pull requests. It would be great if you could close your 
pull request on GitHub.

I'll assign the issue to you - when you're ready, you can "Submit Patch". As 
detailed in the wiki document, either a patch file or a clear link to a branch 
on GitHub in your comment works. Someone will be assigned to review.

> Nodetool move output should be more user friendly if bad token is supplied
> --
>
> Key: CASSANDRA-9348
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9348
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sequoyha pelletier
>Priority: Trivial
>  Labels: lhf
>
> If you put a token into nodetool move that is out of range for the 
> partitioner you get the following error:
> {noformat}
> [architect@md03-gcsarch-lapp33 11:01:06 ]$ nodetool -h 10.11.48.229 -u 
> cassandra -pw cassandra move \\-9223372036854775809 
> Exception in thread "main" java.io.IOException: For input string: 
> "-9223372036854775809" 
> at org.apache.cassandra.service.StorageService.move(StorageService.java:3104) 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75) 
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279) 
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
>  
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
>  
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) 
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) 
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) 
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
>  
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) 
> at 
> com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:468)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
>  
> at java.security.AccessController.doPrivileged(Native Method) 
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1427)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
>  
> at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) 
> at sun.rmi.transport.Transport$1.run(Transport.java:177) 
> at sun.rmi.transport.Transport$1.run(Transport.java:174) 
> at java.security.AccessController.doPrivileged(Native Method) 
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173) 
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556) 
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
>  
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  
> at java.lang.Thread.run(Thread.java:745) 
> {noformat}
> This ticket is just requesting that we catch the exception an output 
> something along the lines of "Token supplied is outside of the acceptable 
> range" for those that are still in the Cassandra learning curve.



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

[jira] [Created] (CASSANDRA-11405) Server encryption cannot be enabled with the IBM JRE 1.7

[Guillermo Vega-Toro (JIRA)]

Guillermo Vega-Toro created CASSANDRA-11405:
---

 Summary: Server encryption cannot be enabled with the IBM JRE 1.7
 Key: CASSANDRA-11405
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11405
 Project: Cassandra
  Issue Type: Bug
  Components: Configuration
 Environment: Linux, IBM JRE 1.7
Reporter: Guillermo Vega-Toro
 Fix For: 2.2.6


When enabling server encryption with the IBM JRE (algorithm: IbmX509), an 
IllegalArgumentException is thrown from the IBM JSSE when the server is started:

ERROR 10:04:37,326 Exception encountered during startup
java.lang.IllegalArgumentException: SSLv2Hello
at com.ibm.jsse2.qb.a(qb.java:50)
at com.ibm.jsse2.pb.a(pb.java:101)
at com.ibm.jsse2.pb.(pb.java:77)
at com.ibm.jsse2.oc.setEnabledProtocols(oc.java:77)
at 
org.apache.cassandra.security.SSLFactory.getServerSocket(SSLFactory.java:64)
at 
org.apache.cassandra.net.MessagingService.getServerSockets(MessagingService.java:425)
at 
org.apache.cassandra.net.MessagingService.listen(MessagingService.java:409)
at 
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:693)
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:623)
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:515)
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:437)
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:567)
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:656)

The problem is that the IBM JSSE does not support SSLv2Hello, but this protocol 
is hard-coded in class org.apache.cassandra.security.SSLFactory:

public static final String[] ACCEPTED_PROTOCOLS = new String[] {"SSLv2Hello", 
"TLSv1", "TLSv1.1", "TLSv1.2"};

public static SSLServerSocket getServerSocket(EncryptionOptions options, 
InetAddress address, int port) throws IOException
{
SSLContext ctx = createSSLContext(options, true);
SSLServerSocket serverSocket = 
(SSLServerSocket)ctx.getServerSocketFactory().createServerSocket();
serverSocket.setReuseAddress(true);
String[] suits = 
filterCipherSuites(serverSocket.getSupportedCipherSuites(), 
options.cipher_suites);
serverSocket.setEnabledCipherSuites(suits);
serverSocket.setNeedClientAuth(options.require_client_auth);
serverSocket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
serverSocket.bind(new InetSocketAddress(address, port), 500);
return serverSocket;
}

This ACCEPTED_PROTOCOLS array should not be hard-coded. It should rather read 
the protocols from configuration, or if the algorithm is IbmX509, simply do not 
call setEnabledProtocols - with the IBM JSSE, the enabled protocol is 
controlled by the protocol passed to SSLContext.getInstance.



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

[jira] [Commented] (CASSANDRA-9348) Nodetool move output should be more user friendly if bad token is supplied

[Abhishek Verma (JIRA)]

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

Abhishek Verma commented on CASSANDRA-9348:
---

That's a good idea Sylvain!

Here's my pull request based on trunk: 
https://github.com/apache/cassandra/pull/64

Should I also create a patch file? And for other branches?

> Nodetool move output should be more user friendly if bad token is supplied
> --
>
> Key: CASSANDRA-9348
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9348
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sequoyha pelletier
>Priority: Trivial
>  Labels: lhf
>
> If you put a token into nodetool move that is out of range for the 
> partitioner you get the following error:
> {noformat}
> [architect@md03-gcsarch-lapp33 11:01:06 ]$ nodetool -h 10.11.48.229 -u 
> cassandra -pw cassandra move \\-9223372036854775809 
> Exception in thread "main" java.io.IOException: For input string: 
> "-9223372036854775809" 
> at org.apache.cassandra.service.StorageService.move(StorageService.java:3104) 
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75) 
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279) 
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
>  
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
>  
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) 
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) 
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) 
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
>  
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) 
> at 
> com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:468)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
>  
> at java.security.AccessController.doPrivileged(Native Method) 
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1427)
>  
> at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
>  
> at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source) 
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> at java.lang.reflect.Method.invoke(Method.java:606) 
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322) 
> at sun.rmi.transport.Transport$1.run(Transport.java:177) 
> at sun.rmi.transport.Transport$1.run(Transport.java:174) 
> at java.security.AccessController.doPrivileged(Native Method) 
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173) 
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556) 
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
>  
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  
> at java.lang.Thread.run(Thread.java:745) 
> {noformat}
> This ticket is just requesting that we catch the exception an output 
> something along the lines of "Token supplied is outside of the acceptable 
> range" for those that are still in the Cassandra learning curve.



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

[jira] [Updated] (CASSANDRA-9598) bad classapth for 'sstablerepairedset' in 'cassandra-tools' package

[Yuki Morishita (JIRA)]

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

Yuki Morishita updated CASSANDRA-9598:
--
   Resolution: Fixed
Fix Version/s: (was: 3.0.x)
   (was: 2.2.x)
   (was: 2.1.x)
   3.0.5
   2.2.6
   2.1.14
Reproduced In: 2.2.5, 2.1.6  (was: 2.1.6, 2.2.5)
   Status: Resolved  (was: Patch Available)

Thanks! Committed.

(42644c32401f35d2c4830773ef6a2b690bb21993)

> bad classapth for 'sstablerepairedset' in 'cassandra-tools' package
> ---
>
> Key: CASSANDRA-9598
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9598
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Debian 3.16.7, cassandra-tools 2.1.6, cassandra 2.1.6
>Reporter: Clément Lardeur
>Assignee: Yuki Morishita
>Priority: Minor
> Fix For: 2.1.14, 2.2.6, 3.0.5
>
>
> The script 'sstablerepairedset' is not ready out of the box for debian 
> distro, maybe due to the refactoring of CASSANDRA-7160 to pack out tools from 
> the bin directory.
> Actually in 'sstablerepairedset' the classapth is calculated with:
> {code}
> if [ "x$CLASSPATH" = "x" ]; then
> 
> # execute from the build dir.
> if [ -d `dirname $0`/../../build/classes ]; then
> for directory in `dirname $0`/../../build/classes/*; do
> CLASSPATH=$CLASSPATH:$directory
> done
> else
> if [ -f `dirname $0`/../lib/stress.jar ]; then
> CLASSPATH=`dirname $0`/../lib/stress.jar
> fi
> fi
> for jar in `dirname $0`/../../lib/*.jar; do
> CLASSPATH=$CLASSPATH:$jar
> done
> fi
> {code}
> Whereas in other scripts from the 'bin/tools', the classpath is calculated 
> with:
> {code}
> if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
> for include in "`dirname "$0"`/cassandra.in.sh" \
>"$HOME/.cassandra.in.sh" \
>/usr/share/cassandra/cassandra.in.sh \
>/usr/local/share/cassandra/cassandra.in.sh \
>/opt/cassandra/cassandra.in.sh; do
> if [ -r "$include" ]; then
> . "$include"
> break
> fi
> done
> elif [ -r "$CASSANDRA_INCLUDE" ]; then
> . "$CASSANDRA_INCLUDE"
> fi
> {code}
> I think that a little refactoring could be good to extract the common part of 
> these scripts like the computation of the CLASSPATH and the set of JAVA_HOME.



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

[03/15] cassandra git commit: Backport CASSANDRA-10679

[yukim]

Backport CASSANDRA-10679

patch by yukim; reviewed by Jeremiah Jordan for CASSANDRA-9598


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

Branch: refs/heads/trunk
Commit: 42644c32401f35d2c4830773ef6a2b690bb21993
Parents: 41bb4bc
Author: Jeremiah D Jordan 
Authored: Wed Dec 2 10:48:27 2015 -0600
Committer: Yuki Morishita 
Committed: Tue Mar 22 15:56:06 2016 -0500

--
 CHANGES.txt |  1 +
 bin/cassandra-cli   | 20 ++--
 bin/nodetool| 38 ---
 bin/sstablekeys | 21 +---
 bin/sstableloader   | 13 +++--
 bin/sstablescrub|  7 ++-
 bin/sstableupgrade  | 24 ++
 .../apache/cassandra/tools/SSTableExport.java   |  1 +
 tools/bin/cassandra-stress  | 37 +--
 tools/bin/cassandra-stressd | 50 ++--
 tools/bin/json2sstable  | 19 ++--
 tools/bin/sstable2json  | 20 +---
 tools/bin/sstableexpiredblockers| 10 +++-
 tools/bin/sstablelevelreset | 36 +-
 tools/bin/sstablemetadata   | 22 ++---
 tools/bin/sstableofflinerelevel | 10 +++-
 tools/bin/sstablerepairedset| 49 ---
 tools/bin/sstablesplit  | 29 
 18 files changed, 263 insertions(+), 144 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/42644c32/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 04c9204..5f01114 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.14
+ * Backport CASSANDRA-10679 (CASSANDRA-9598)
  * Don't do defragmentation if reading from repaired sstables (CASSANDRA-10342)
  * Fix streaming_socket_timeout_in_ms not enforced (CASSANDRA-11286)
  * Avoid dropping message too quickly due to missing unit conversion 
(CASSANDRA-11302)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/42644c32/bin/cassandra-cli
--
diff --git a/bin/cassandra-cli b/bin/cassandra-cli
index a2696da..88c9d2f 100755
--- a/bin/cassandra-cli
+++ b/bin/cassandra-cli
@@ -17,11 +17,11 @@
 # limitations under the License.
 
 if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
-for include in "`dirname "$0"`/cassandra.in.sh" \
-   "$HOME/.cassandra.in.sh" \
-   /usr/share/cassandra/cassandra.in.sh \
+for include in /usr/share/cassandra/cassandra.in.sh \
/usr/local/share/cassandra/cassandra.in.sh \
-   /opt/cassandra/cassandra.in.sh; do
+   /opt/cassandra/cassandra.in.sh \
+   "$HOME/.cassandra.in.sh" \
+   "`dirname "$0"`/cassandra.in.sh"; do
 if [ -r "$include" ]; then
 . "$include"
 break
@@ -38,14 +38,24 @@ else
 JAVA="`which java`"
 fi
 
+if [ "x$JAVA" = "x" ]; then
+echo "Java executable not found (hint: set JAVA_HOME)" >&2
+exit 1
+fi
+
 if [ -z "$CLASSPATH" ]; then
 echo "You must set the CLASSPATH var" >&2
 exit 1
 fi
 
-"$JAVA" -ea -cp "$CLASSPATH" -Xmx256M \
+if [ "x$MAX_HEAP_SIZE" = "x" ]; then
+MAX_HEAP_SIZE="256M"
+fi
+
+"$JAVA" $JAVA_AGENT -ea -cp "$CLASSPATH" $JVM_OPTS -Xmx$MAX_HEAP_SIZE \
 -Dcassandra.storagedir="$cassandra_storagedir" \
 -Dlogback.configurationFile=logback-tools.xml \
+$JVM_ARGS \
 org.apache.cassandra.cli.CliMain "$@"
 
 # vi:ai sw=4 ts=4 tw=0 et

http://git-wip-us.apache.org/repos/asf/cassandra/blob/42644c32/bin/nodetool
--
diff --git a/bin/nodetool b/bin/nodetool
index d211459..0ea078f 100755
--- a/bin/nodetool
+++ b/bin/nodetool
@@ -1,4 +1,5 @@
 #!/bin/sh
+
 # Licensed to the Apache Software Foundation (ASF) under one
 # or more contributor license agreements.  See the NOTICE file
 # distributed with this work for additional information
@@ -22,11 +23,11 @@ if [ "`basename "$0"`" = 'nodeprobe' ]; then
 fi
 
 if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
-for include in "`dirname "$0"`/cassandra.in.sh" \
-   "$HOME/.cassandra.in.sh" \
-   /usr/share/cassandra/cassandra.in.sh \
+for include in /usr/share/cassandra/cassandra.in.sh \

[06/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[yukim]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/trunk
Commit: b6d0a752e4f681d409518c13bded34086d3d
Parents: c74df40 42644c3
Author: Yuki Morishita 
Authored: Tue Mar 22 16:04:58 2016 -0500
Committer: Yuki Morishita 
Committed: Tue Mar 22 16:04:58 2016 -0500

--
 CHANGES.txt |  1 +
 bin/nodetool| 38 ---
 bin/sstablekeys | 21 +---
 bin/sstableloader   | 13 +++--
 bin/sstablescrub|  7 ++-
 bin/sstableupgrade  | 24 ++
 bin/sstableverify   |  9 +++-
 .../apache/cassandra/tools/SSTableExport.java   |  1 +
 tools/bin/cassandra-stress  | 37 +--
 tools/bin/cassandra-stressd | 50 ++--
 tools/bin/json2sstable  | 19 ++--
 tools/bin/sstable2json  | 20 +---
 tools/bin/sstableexpiredblockers| 10 +++-
 tools/bin/sstablelevelreset | 36 +-
 tools/bin/sstablemetadata   | 22 ++---
 tools/bin/sstableofflinerelevel | 10 +++-
 tools/bin/sstablerepairedset| 49 ---
 tools/bin/sstablesplit  | 29 
 18 files changed, 255 insertions(+), 141 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b6d0a752/CHANGES.txt
--
diff --cc CHANGES.txt
index e4db50e,5f01114..91dc588
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,39 -1,5 +1,40 @@@
 -2.1.14
 +2.2.6
 + * cqlsh: COPY FROM should check that explicit column names are valid 
(CASSANDRA-11333)
 + * Add -Dcassandra.start_gossip startup option (CASSANDRA-10809)
 + * Fix UTF8Validator.validate() for modified UTF-8 (CASSANDRA-10748)
 + * Clarify that now() function is calculated on the coordinator node in CQL 
documentation (CASSANDRA-10900)
 + * Fix bloom filter sizing with LCS (CASSANDRA-11344)
 + * (cqlsh) Fix error when result is 0 rows with EXPAND ON (CASSANDRA-11092)
 + * Fix intra-node serialization issue for multicolumn-restrictions 
(CASSANDRA-11196)
 + * Non-obsoleting compaction operations over compressed files can impose rate 
limit on normal reads (CASSANDRA-11301)
 + * Add missing newline at end of bin/cqlsh (CASSANDRA-11325)
 + * Fix AE in nodetool cfstats (backport CASSANDRA-10859) (CASSANDRA-11297)
 + * Unresolved hostname leads to replace being ignored (CASSANDRA-11210)
 + * Fix filtering on non-primary key columns for thrift static column families
 +   (CASSANDRA-6377)
 + * Only log yaml config once, at startup (CASSANDRA-11217)
 + * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
 + * Reference leak with parallel repairs on the same table (CASSANDRA-11215)
 + * Range.compareTo() violates the contract of Comparable (CASSANDRA-11216)
 + * Avoid NPE when serializing ErrorMessage with null message (CASSANDRA-11167)
 + * Replacing an aggregate with a new version doesn't reset INITCOND 
(CASSANDRA-10840)
 + * (cqlsh) cqlsh cannot be called through symlink (CASSANDRA-11037)
 + * fix ohc and java-driver pom dependencies in build.xml (CASSANDRA-10793)
 + * Protect from keyspace dropped during repair (CASSANDRA-11065)
 + * Handle adding fields to a UDT in SELECT JSON and toJson() (CASSANDRA-11146)
 + * Better error message for cleanup (CASSANDRA-10991)
 + * cqlsh pg-style-strings broken if line ends with ';' (CASSANDRA-11123)
 + * Use cloned TokenMetadata in size estimates to avoid race against 
membership check
 +   (CASSANDRA-10736)
 + * Always persist upsampled index summaries (CASSANDRA-10512)
 + * (cqlsh) Fix inconsistent auto-complete (CASSANDRA-10733)
 + * Make SELECT JSON and toJson() threadsafe (CASSANDRA-11048)
 + * Fix SELECT on tuple relations for mixed ASC/DESC clustering order 
(CASSANDRA-7281)
 + * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030)
 + * Fix paging on DISTINCT queries repeats result when first row in partition 
changes
 +   (CASSANDRA-10010)
 +Merged from 2.1:
+  * Backport CASSANDRA-10679 (CASSANDRA-9598)
   * Don't do defragmentation if reading from repaired sstables 
(CASSANDRA-10342)
   * Fix streaming_socket_timeout_in_ms not enforced (CASSANDRA-11286)
   * Avoid dropping message too quickly due to missing unit conversion 
(CASSANDRA-11302)

[07/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[yukim]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-2.2
Commit: b6d0a752e4f681d409518c13bded34086d3d
Parents: c74df40 42644c3
Author: Yuki Morishita 
Authored: Tue Mar 22 16:04:58 2016 -0500
Committer: Yuki Morishita 
Committed: Tue Mar 22 16:04:58 2016 -0500

--
 CHANGES.txt |  1 +
 bin/nodetool| 38 ---
 bin/sstablekeys | 21 +---
 bin/sstableloader   | 13 +++--
 bin/sstablescrub|  7 ++-
 bin/sstableupgrade  | 24 ++
 bin/sstableverify   |  9 +++-
 .../apache/cassandra/tools/SSTableExport.java   |  1 +
 tools/bin/cassandra-stress  | 37 +--
 tools/bin/cassandra-stressd | 50 ++--
 tools/bin/json2sstable  | 19 ++--
 tools/bin/sstable2json  | 20 +---
 tools/bin/sstableexpiredblockers| 10 +++-
 tools/bin/sstablelevelreset | 36 +-
 tools/bin/sstablemetadata   | 22 ++---
 tools/bin/sstableofflinerelevel | 10 +++-
 tools/bin/sstablerepairedset| 49 ---
 tools/bin/sstablesplit  | 29 
 18 files changed, 255 insertions(+), 141 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b6d0a752/CHANGES.txt
--
diff --cc CHANGES.txt
index e4db50e,5f01114..91dc588
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,39 -1,5 +1,40 @@@
 -2.1.14
 +2.2.6
 + * cqlsh: COPY FROM should check that explicit column names are valid 
(CASSANDRA-11333)
 + * Add -Dcassandra.start_gossip startup option (CASSANDRA-10809)
 + * Fix UTF8Validator.validate() for modified UTF-8 (CASSANDRA-10748)
 + * Clarify that now() function is calculated on the coordinator node in CQL 
documentation (CASSANDRA-10900)
 + * Fix bloom filter sizing with LCS (CASSANDRA-11344)
 + * (cqlsh) Fix error when result is 0 rows with EXPAND ON (CASSANDRA-11092)
 + * Fix intra-node serialization issue for multicolumn-restrictions 
(CASSANDRA-11196)
 + * Non-obsoleting compaction operations over compressed files can impose rate 
limit on normal reads (CASSANDRA-11301)
 + * Add missing newline at end of bin/cqlsh (CASSANDRA-11325)
 + * Fix AE in nodetool cfstats (backport CASSANDRA-10859) (CASSANDRA-11297)
 + * Unresolved hostname leads to replace being ignored (CASSANDRA-11210)
 + * Fix filtering on non-primary key columns for thrift static column families
 +   (CASSANDRA-6377)
 + * Only log yaml config once, at startup (CASSANDRA-11217)
 + * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
 + * Reference leak with parallel repairs on the same table (CASSANDRA-11215)
 + * Range.compareTo() violates the contract of Comparable (CASSANDRA-11216)
 + * Avoid NPE when serializing ErrorMessage with null message (CASSANDRA-11167)
 + * Replacing an aggregate with a new version doesn't reset INITCOND 
(CASSANDRA-10840)
 + * (cqlsh) cqlsh cannot be called through symlink (CASSANDRA-11037)
 + * fix ohc and java-driver pom dependencies in build.xml (CASSANDRA-10793)
 + * Protect from keyspace dropped during repair (CASSANDRA-11065)
 + * Handle adding fields to a UDT in SELECT JSON and toJson() (CASSANDRA-11146)
 + * Better error message for cleanup (CASSANDRA-10991)
 + * cqlsh pg-style-strings broken if line ends with ';' (CASSANDRA-11123)
 + * Use cloned TokenMetadata in size estimates to avoid race against 
membership check
 +   (CASSANDRA-10736)
 + * Always persist upsampled index summaries (CASSANDRA-10512)
 + * (cqlsh) Fix inconsistent auto-complete (CASSANDRA-10733)
 + * Make SELECT JSON and toJson() threadsafe (CASSANDRA-11048)
 + * Fix SELECT on tuple relations for mixed ASC/DESC clustering order 
(CASSANDRA-7281)
 + * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030)
 + * Fix paging on DISTINCT queries repeats result when first row in partition 
changes
 +   (CASSANDRA-10010)
 +Merged from 2.1:
+  * Backport CASSANDRA-10679 (CASSANDRA-9598)
   * Don't do defragmentation if reading from repaired sstables 
(CASSANDRA-10342)
   * Fix streaming_socket_timeout_in_ms not enforced (CASSANDRA-11286)
   * Avoid dropping message too quickly due to missing unit conversion 
(CASSANDRA-11302)

[11/15] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[yukim]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.5
Commit: 5e722ee0a0360a589c0497235ead0ea5ee85a805
Parents: 842e7c3 b6d0a75
Author: Yuki Morishita 
Authored: Tue Mar 22 16:09:06 2016 -0500
Committer: Yuki Morishita 
Committed: Tue Mar 22 16:09:06 2016 -0500

--
 CHANGES.txt  |  1 +
 bin/nodetool | 38 +-
 bin/sstableloader| 13 ++---
 bin/sstablescrub |  7 -
 bin/sstableupgrade   | 24 ++---
 bin/sstableutil  |  7 -
 bin/sstableverify|  9 +--
 tools/bin/cassandra-stress   | 37 --
 tools/bin/cassandra-stressd  | 50 ++-
 tools/bin/sstabledump| 20 +-
 tools/bin/sstableexpiredblockers | 10 +--
 tools/bin/sstablelevelreset  | 36 -
 tools/bin/sstablemetadata| 22 ++-
 tools/bin/sstableofflinerelevel  | 10 +--
 tools/bin/sstablerepairedset | 49 +-
 tools/bin/sstablesplit   | 29 +---
 16 files changed, 231 insertions(+), 131 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e722ee0/CHANGES.txt
--
diff --cc CHANGES.txt
index 21eb3e5,91dc588..904206b
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -18,35 -8,13 +18,36 @@@ Merged from 2.2
   * Add missing newline at end of bin/cqlsh (CASSANDRA-11325)
   * Fix AE in nodetool cfstats (backport CASSANDRA-10859) (CASSANDRA-11297)
   * Unresolved hostname leads to replace being ignored (CASSANDRA-11210)
 - * Fix filtering on non-primary key columns for thrift static column families
 -   (CASSANDRA-6377)
   * Only log yaml config once, at startup (CASSANDRA-11217)
 - * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
   * Reference leak with parallel repairs on the same table (CASSANDRA-11215)
 +Merged from 2.1:
++ * Backport CASSANDRA-10679 (CASSANDRA-9598)
 + * InvalidateKeys should have a weak ref to key cache (CASSANDRA-11176)
 + * COPY FROM on large datasets: fix progress report and debug performance 
(CASSANDRA-11053)
 +
 +3.0.4
 + * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
 + * MV should only query complex columns included in the view (CASSANDRA-11069)
 + * Failed aggregate creation breaks server permanently (CASSANDRA-11064)
 + * Add sstabledump tool (CASSANDRA-7464)
 + * Introduce backpressure for hints (CASSANDRA-10972)
 + * Fix ClusteringPrefix not being able to read tombstone range boundaries 
(CASSANDRA-11158)
 + * Prevent logging in sandboxed state (CASSANDRA-11033)
 + * Disallow drop/alter operations of UDTs used by UDAs (CASSANDRA-10721)
 + * Add query time validation method on Index (CASSANDRA-11043)
 + * Avoid potential AssertionError in mixed version cluster (CASSANDRA-11128)
 + * Properly handle hinted handoff after topology changes (CASSANDRA-5902)
 + * AssertionError when listing sstable files on inconsistent disk state 
(CASSANDRA-11156)
 + * Fix wrong rack counting and invalid conditions check for TokenAllocation
 +   (CASSANDRA-11139)
 + * Avoid creating empty hint files (CASSANDRA-11090)
 + * Fix leak detection strong reference loop using weak reference 
(CASSANDRA-11120)
 + * Configurie BatchlogManager to stop delayed tasks on shutdown 
(CASSANDRA-11062)
 + * Hadoop integration is incompatible with Cassandra Driver 3.0.0 
(CASSANDRA-11001)
 + * Add dropped_columns to the list of schema table so it gets handled
 +   properly (CASSANDRA-11050)
 + * Fix NPE when using forceRepairRangeAsync without DC (CASSANDRA-11239)
 +Merged from 2.2:
   * Range.compareTo() violates the contract of Comparable (CASSANDRA-11216)
   * Avoid NPE when serializing ErrorMessage with null message (CASSANDRA-11167)
   * Replacing an aggregate with a new version doesn't reset INITCOND 
(CASSANDRA-10840)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e722ee0/bin/sstableutil
--
diff --cc bin/sstableutil
index 2860729,000..9f07785
mode 100755,00..100755
--- a/bin/sstableutil
+++ b/bin/sstableutil
@@@ -1,55 -1,0 +1,60 @@@
 +#!/bin/sh
 +
 +# Licensed to the Apache Software Foundation (ASF) under one
 +# or more contributor license agreements.  See the NOTICE file
 +# distributed with this work for additional information
 +# regarding copyright 

[01/15] cassandra git commit: Backport CASSANDRA-10679

[yukim]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.1 41bb4bcd0 -> 42644c324
  refs/heads/cassandra-2.2 c74df4017 -> b6d0a752e
  refs/heads/cassandra-3.0 842e7c3fb -> 5e722ee0a
  refs/heads/cassandra-3.5 1ee550262 -> 76241eb02
  refs/heads/trunk 207d08f86 -> a1940a157


Backport CASSANDRA-10679

patch by yukim; reviewed by Jeremiah Jordan for CASSANDRA-9598


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

Branch: refs/heads/cassandra-2.1
Commit: 42644c32401f35d2c4830773ef6a2b690bb21993
Parents: 41bb4bc
Author: Jeremiah D Jordan 
Authored: Wed Dec 2 10:48:27 2015 -0600
Committer: Yuki Morishita 
Committed: Tue Mar 22 15:56:06 2016 -0500

--
 CHANGES.txt |  1 +
 bin/cassandra-cli   | 20 ++--
 bin/nodetool| 38 ---
 bin/sstablekeys | 21 +---
 bin/sstableloader   | 13 +++--
 bin/sstablescrub|  7 ++-
 bin/sstableupgrade  | 24 ++
 .../apache/cassandra/tools/SSTableExport.java   |  1 +
 tools/bin/cassandra-stress  | 37 +--
 tools/bin/cassandra-stressd | 50 ++--
 tools/bin/json2sstable  | 19 ++--
 tools/bin/sstable2json  | 20 +---
 tools/bin/sstableexpiredblockers| 10 +++-
 tools/bin/sstablelevelreset | 36 +-
 tools/bin/sstablemetadata   | 22 ++---
 tools/bin/sstableofflinerelevel | 10 +++-
 tools/bin/sstablerepairedset| 49 ---
 tools/bin/sstablesplit  | 29 
 18 files changed, 263 insertions(+), 144 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/42644c32/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 04c9204..5f01114 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.14
+ * Backport CASSANDRA-10679 (CASSANDRA-9598)
  * Don't do defragmentation if reading from repaired sstables (CASSANDRA-10342)
  * Fix streaming_socket_timeout_in_ms not enforced (CASSANDRA-11286)
  * Avoid dropping message too quickly due to missing unit conversion 
(CASSANDRA-11302)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/42644c32/bin/cassandra-cli
--
diff --git a/bin/cassandra-cli b/bin/cassandra-cli
index a2696da..88c9d2f 100755
--- a/bin/cassandra-cli
+++ b/bin/cassandra-cli
@@ -17,11 +17,11 @@
 # limitations under the License.
 
 if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
-for include in "`dirname "$0"`/cassandra.in.sh" \
-   "$HOME/.cassandra.in.sh" \
-   /usr/share/cassandra/cassandra.in.sh \
+for include in /usr/share/cassandra/cassandra.in.sh \
/usr/local/share/cassandra/cassandra.in.sh \
-   /opt/cassandra/cassandra.in.sh; do
+   /opt/cassandra/cassandra.in.sh \
+   "$HOME/.cassandra.in.sh" \
+   "`dirname "$0"`/cassandra.in.sh"; do
 if [ -r "$include" ]; then
 . "$include"
 break
@@ -38,14 +38,24 @@ else
 JAVA="`which java`"
 fi
 
+if [ "x$JAVA" = "x" ]; then
+echo "Java executable not found (hint: set JAVA_HOME)" >&2
+exit 1
+fi
+
 if [ -z "$CLASSPATH" ]; then
 echo "You must set the CLASSPATH var" >&2
 exit 1
 fi
 
-"$JAVA" -ea -cp "$CLASSPATH" -Xmx256M \
+if [ "x$MAX_HEAP_SIZE" = "x" ]; then
+MAX_HEAP_SIZE="256M"
+fi
+
+"$JAVA" $JAVA_AGENT -ea -cp "$CLASSPATH" $JVM_OPTS -Xmx$MAX_HEAP_SIZE \
 -Dcassandra.storagedir="$cassandra_storagedir" \
 -Dlogback.configurationFile=logback-tools.xml \
+$JVM_ARGS \
 org.apache.cassandra.cli.CliMain "$@"
 
 # vi:ai sw=4 ts=4 tw=0 et

http://git-wip-us.apache.org/repos/asf/cassandra/blob/42644c32/bin/nodetool
--
diff --git a/bin/nodetool b/bin/nodetool
index d211459..0ea078f 100755
--- a/bin/nodetool
+++ b/bin/nodetool
@@ -1,4 +1,5 @@
 #!/bin/sh
+
 # Licensed to the Apache Software Foundation (ASF) under one
 # or more contributor license agreements.  See the NOTICE file
 # distributed with this work for additional information
@@ -22,11 +23,11 @@ if [ "`basename "$0"`" = 'nodeprobe' ]; then
 fi
 
 

[14/15] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.5

[yukim]

Merge branch 'cassandra-3.0' into cassandra-3.5


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

Branch: refs/heads/trunk
Commit: 76241eb02158824a979fc2ee6846d6a3f8d499f2
Parents: 1ee5502 5e722ee
Author: Yuki Morishita 
Authored: Tue Mar 22 16:10:08 2016 -0500
Committer: Yuki Morishita 
Committed: Tue Mar 22 16:10:08 2016 -0500

--

--

[08/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[yukim]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-3.0
Commit: b6d0a752e4f681d409518c13bded34086d3d
Parents: c74df40 42644c3
Author: Yuki Morishita 
Authored: Tue Mar 22 16:04:58 2016 -0500
Committer: Yuki Morishita 
Committed: Tue Mar 22 16:04:58 2016 -0500

--
 CHANGES.txt |  1 +
 bin/nodetool| 38 ---
 bin/sstablekeys | 21 +---
 bin/sstableloader   | 13 +++--
 bin/sstablescrub|  7 ++-
 bin/sstableupgrade  | 24 ++
 bin/sstableverify   |  9 +++-
 .../apache/cassandra/tools/SSTableExport.java   |  1 +
 tools/bin/cassandra-stress  | 37 +--
 tools/bin/cassandra-stressd | 50 ++--
 tools/bin/json2sstable  | 19 ++--
 tools/bin/sstable2json  | 20 +---
 tools/bin/sstableexpiredblockers| 10 +++-
 tools/bin/sstablelevelreset | 36 +-
 tools/bin/sstablemetadata   | 22 ++---
 tools/bin/sstableofflinerelevel | 10 +++-
 tools/bin/sstablerepairedset| 49 ---
 tools/bin/sstablesplit  | 29 
 18 files changed, 255 insertions(+), 141 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b6d0a752/CHANGES.txt
--
diff --cc CHANGES.txt
index e4db50e,5f01114..91dc588
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,39 -1,5 +1,40 @@@
 -2.1.14
 +2.2.6
 + * cqlsh: COPY FROM should check that explicit column names are valid 
(CASSANDRA-11333)
 + * Add -Dcassandra.start_gossip startup option (CASSANDRA-10809)
 + * Fix UTF8Validator.validate() for modified UTF-8 (CASSANDRA-10748)
 + * Clarify that now() function is calculated on the coordinator node in CQL 
documentation (CASSANDRA-10900)
 + * Fix bloom filter sizing with LCS (CASSANDRA-11344)
 + * (cqlsh) Fix error when result is 0 rows with EXPAND ON (CASSANDRA-11092)
 + * Fix intra-node serialization issue for multicolumn-restrictions 
(CASSANDRA-11196)
 + * Non-obsoleting compaction operations over compressed files can impose rate 
limit on normal reads (CASSANDRA-11301)
 + * Add missing newline at end of bin/cqlsh (CASSANDRA-11325)
 + * Fix AE in nodetool cfstats (backport CASSANDRA-10859) (CASSANDRA-11297)
 + * Unresolved hostname leads to replace being ignored (CASSANDRA-11210)
 + * Fix filtering on non-primary key columns for thrift static column families
 +   (CASSANDRA-6377)
 + * Only log yaml config once, at startup (CASSANDRA-11217)
 + * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
 + * Reference leak with parallel repairs on the same table (CASSANDRA-11215)
 + * Range.compareTo() violates the contract of Comparable (CASSANDRA-11216)
 + * Avoid NPE when serializing ErrorMessage with null message (CASSANDRA-11167)
 + * Replacing an aggregate with a new version doesn't reset INITCOND 
(CASSANDRA-10840)
 + * (cqlsh) cqlsh cannot be called through symlink (CASSANDRA-11037)
 + * fix ohc and java-driver pom dependencies in build.xml (CASSANDRA-10793)
 + * Protect from keyspace dropped during repair (CASSANDRA-11065)
 + * Handle adding fields to a UDT in SELECT JSON and toJson() (CASSANDRA-11146)
 + * Better error message for cleanup (CASSANDRA-10991)
 + * cqlsh pg-style-strings broken if line ends with ';' (CASSANDRA-11123)
 + * Use cloned TokenMetadata in size estimates to avoid race against 
membership check
 +   (CASSANDRA-10736)
 + * Always persist upsampled index summaries (CASSANDRA-10512)
 + * (cqlsh) Fix inconsistent auto-complete (CASSANDRA-10733)
 + * Make SELECT JSON and toJson() threadsafe (CASSANDRA-11048)
 + * Fix SELECT on tuple relations for mixed ASC/DESC clustering order 
(CASSANDRA-7281)
 + * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030)
 + * Fix paging on DISTINCT queries repeats result when first row in partition 
changes
 +   (CASSANDRA-10010)
 +Merged from 2.1:
+  * Backport CASSANDRA-10679 (CASSANDRA-9598)
   * Don't do defragmentation if reading from repaired sstables 
(CASSANDRA-10342)
   * Fix streaming_socket_timeout_in_ms not enforced (CASSANDRA-11286)
   * Avoid dropping message too quickly due to missing unit conversion 
(CASSANDRA-11302)

[10/15] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[yukim]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/trunk
Commit: 5e722ee0a0360a589c0497235ead0ea5ee85a805
Parents: 842e7c3 b6d0a75
Author: Yuki Morishita 
Authored: Tue Mar 22 16:09:06 2016 -0500
Committer: Yuki Morishita 
Committed: Tue Mar 22 16:09:06 2016 -0500

--
 CHANGES.txt  |  1 +
 bin/nodetool | 38 +-
 bin/sstableloader| 13 ++---
 bin/sstablescrub |  7 -
 bin/sstableupgrade   | 24 ++---
 bin/sstableutil  |  7 -
 bin/sstableverify|  9 +--
 tools/bin/cassandra-stress   | 37 --
 tools/bin/cassandra-stressd  | 50 ++-
 tools/bin/sstabledump| 20 +-
 tools/bin/sstableexpiredblockers | 10 +--
 tools/bin/sstablelevelreset  | 36 -
 tools/bin/sstablemetadata| 22 ++-
 tools/bin/sstableofflinerelevel  | 10 +--
 tools/bin/sstablerepairedset | 49 +-
 tools/bin/sstablesplit   | 29 +---
 16 files changed, 231 insertions(+), 131 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e722ee0/CHANGES.txt
--
diff --cc CHANGES.txt
index 21eb3e5,91dc588..904206b
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -18,35 -8,13 +18,36 @@@ Merged from 2.2
   * Add missing newline at end of bin/cqlsh (CASSANDRA-11325)
   * Fix AE in nodetool cfstats (backport CASSANDRA-10859) (CASSANDRA-11297)
   * Unresolved hostname leads to replace being ignored (CASSANDRA-11210)
 - * Fix filtering on non-primary key columns for thrift static column families
 -   (CASSANDRA-6377)
   * Only log yaml config once, at startup (CASSANDRA-11217)
 - * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
   * Reference leak with parallel repairs on the same table (CASSANDRA-11215)
 +Merged from 2.1:
++ * Backport CASSANDRA-10679 (CASSANDRA-9598)
 + * InvalidateKeys should have a weak ref to key cache (CASSANDRA-11176)
 + * COPY FROM on large datasets: fix progress report and debug performance 
(CASSANDRA-11053)
 +
 +3.0.4
 + * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
 + * MV should only query complex columns included in the view (CASSANDRA-11069)
 + * Failed aggregate creation breaks server permanently (CASSANDRA-11064)
 + * Add sstabledump tool (CASSANDRA-7464)
 + * Introduce backpressure for hints (CASSANDRA-10972)
 + * Fix ClusteringPrefix not being able to read tombstone range boundaries 
(CASSANDRA-11158)
 + * Prevent logging in sandboxed state (CASSANDRA-11033)
 + * Disallow drop/alter operations of UDTs used by UDAs (CASSANDRA-10721)
 + * Add query time validation method on Index (CASSANDRA-11043)
 + * Avoid potential AssertionError in mixed version cluster (CASSANDRA-11128)
 + * Properly handle hinted handoff after topology changes (CASSANDRA-5902)
 + * AssertionError when listing sstable files on inconsistent disk state 
(CASSANDRA-11156)
 + * Fix wrong rack counting and invalid conditions check for TokenAllocation
 +   (CASSANDRA-11139)
 + * Avoid creating empty hint files (CASSANDRA-11090)
 + * Fix leak detection strong reference loop using weak reference 
(CASSANDRA-11120)
 + * Configurie BatchlogManager to stop delayed tasks on shutdown 
(CASSANDRA-11062)
 + * Hadoop integration is incompatible with Cassandra Driver 3.0.0 
(CASSANDRA-11001)
 + * Add dropped_columns to the list of schema table so it gets handled
 +   properly (CASSANDRA-11050)
 + * Fix NPE when using forceRepairRangeAsync without DC (CASSANDRA-11239)
 +Merged from 2.2:
   * Range.compareTo() violates the contract of Comparable (CASSANDRA-11216)
   * Avoid NPE when serializing ErrorMessage with null message (CASSANDRA-11167)
   * Replacing an aggregate with a new version doesn't reset INITCOND 
(CASSANDRA-10840)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e722ee0/bin/sstableutil
--
diff --cc bin/sstableutil
index 2860729,000..9f07785
mode 100755,00..100755
--- a/bin/sstableutil
+++ b/bin/sstableutil
@@@ -1,55 -1,0 +1,60 @@@
 +#!/bin/sh
 +
 +# Licensed to the Apache Software Foundation (ASF) under one
 +# or more contributor license agreements.  See the NOTICE file
 +# distributed with this work for additional information
 +# regarding copyright 

[15/15] cassandra git commit: Merge branch 'cassandra-3.5' into trunk

[yukim]

Merge branch 'cassandra-3.5' into trunk


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

Branch: refs/heads/trunk
Commit: a1940a1571007c73ab0855a568f073d4d523ee37
Parents: 207d08f 76241eb
Author: Yuki Morishita 
Authored: Tue Mar 22 16:10:20 2016 -0500
Committer: Yuki Morishita 
Committed: Tue Mar 22 16:10:20 2016 -0500

--

--

[02/15] cassandra git commit: Backport CASSANDRA-10679

[yukim]

Backport CASSANDRA-10679

patch by yukim; reviewed by Jeremiah Jordan for CASSANDRA-9598


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

Branch: refs/heads/cassandra-2.2
Commit: 42644c32401f35d2c4830773ef6a2b690bb21993
Parents: 41bb4bc
Author: Jeremiah D Jordan 
Authored: Wed Dec 2 10:48:27 2015 -0600
Committer: Yuki Morishita 
Committed: Tue Mar 22 15:56:06 2016 -0500

--
 CHANGES.txt |  1 +
 bin/cassandra-cli   | 20 ++--
 bin/nodetool| 38 ---
 bin/sstablekeys | 21 +---
 bin/sstableloader   | 13 +++--
 bin/sstablescrub|  7 ++-
 bin/sstableupgrade  | 24 ++
 .../apache/cassandra/tools/SSTableExport.java   |  1 +
 tools/bin/cassandra-stress  | 37 +--
 tools/bin/cassandra-stressd | 50 ++--
 tools/bin/json2sstable  | 19 ++--
 tools/bin/sstable2json  | 20 +---
 tools/bin/sstableexpiredblockers| 10 +++-
 tools/bin/sstablelevelreset | 36 +-
 tools/bin/sstablemetadata   | 22 ++---
 tools/bin/sstableofflinerelevel | 10 +++-
 tools/bin/sstablerepairedset| 49 ---
 tools/bin/sstablesplit  | 29 
 18 files changed, 263 insertions(+), 144 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/42644c32/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 04c9204..5f01114 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.14
+ * Backport CASSANDRA-10679 (CASSANDRA-9598)
  * Don't do defragmentation if reading from repaired sstables (CASSANDRA-10342)
  * Fix streaming_socket_timeout_in_ms not enforced (CASSANDRA-11286)
  * Avoid dropping message too quickly due to missing unit conversion 
(CASSANDRA-11302)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/42644c32/bin/cassandra-cli
--
diff --git a/bin/cassandra-cli b/bin/cassandra-cli
index a2696da..88c9d2f 100755
--- a/bin/cassandra-cli
+++ b/bin/cassandra-cli
@@ -17,11 +17,11 @@
 # limitations under the License.
 
 if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
-for include in "`dirname "$0"`/cassandra.in.sh" \
-   "$HOME/.cassandra.in.sh" \
-   /usr/share/cassandra/cassandra.in.sh \
+for include in /usr/share/cassandra/cassandra.in.sh \
/usr/local/share/cassandra/cassandra.in.sh \
-   /opt/cassandra/cassandra.in.sh; do
+   /opt/cassandra/cassandra.in.sh \
+   "$HOME/.cassandra.in.sh" \
+   "`dirname "$0"`/cassandra.in.sh"; do
 if [ -r "$include" ]; then
 . "$include"
 break
@@ -38,14 +38,24 @@ else
 JAVA="`which java`"
 fi
 
+if [ "x$JAVA" = "x" ]; then
+echo "Java executable not found (hint: set JAVA_HOME)" >&2
+exit 1
+fi
+
 if [ -z "$CLASSPATH" ]; then
 echo "You must set the CLASSPATH var" >&2
 exit 1
 fi
 
-"$JAVA" -ea -cp "$CLASSPATH" -Xmx256M \
+if [ "x$MAX_HEAP_SIZE" = "x" ]; then
+MAX_HEAP_SIZE="256M"
+fi
+
+"$JAVA" $JAVA_AGENT -ea -cp "$CLASSPATH" $JVM_OPTS -Xmx$MAX_HEAP_SIZE \
 -Dcassandra.storagedir="$cassandra_storagedir" \
 -Dlogback.configurationFile=logback-tools.xml \
+$JVM_ARGS \
 org.apache.cassandra.cli.CliMain "$@"
 
 # vi:ai sw=4 ts=4 tw=0 et

http://git-wip-us.apache.org/repos/asf/cassandra/blob/42644c32/bin/nodetool
--
diff --git a/bin/nodetool b/bin/nodetool
index d211459..0ea078f 100755
--- a/bin/nodetool
+++ b/bin/nodetool
@@ -1,4 +1,5 @@
 #!/bin/sh
+
 # Licensed to the Apache Software Foundation (ASF) under one
 # or more contributor license agreements.  See the NOTICE file
 # distributed with this work for additional information
@@ -22,11 +23,11 @@ if [ "`basename "$0"`" = 'nodeprobe' ]; then
 fi
 
 if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
-for include in "`dirname "$0"`/cassandra.in.sh" \
-   "$HOME/.cassandra.in.sh" \
-   /usr/share/cassandra/cassandra.in.sh \
+for include in /usr/share/cassandra/cassandra.in.sh \

[13/15] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.5

[yukim]

Merge branch 'cassandra-3.0' into cassandra-3.5


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

Branch: refs/heads/cassandra-3.5
Commit: 76241eb02158824a979fc2ee6846d6a3f8d499f2
Parents: 1ee5502 5e722ee
Author: Yuki Morishita 
Authored: Tue Mar 22 16:10:08 2016 -0500
Committer: Yuki Morishita 
Committed: Tue Mar 22 16:10:08 2016 -0500

--

--

[04/15] cassandra git commit: Backport CASSANDRA-10679

[yukim]

Backport CASSANDRA-10679

patch by yukim; reviewed by Jeremiah Jordan for CASSANDRA-9598


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

Branch: refs/heads/cassandra-3.0
Commit: 42644c32401f35d2c4830773ef6a2b690bb21993
Parents: 41bb4bc
Author: Jeremiah D Jordan 
Authored: Wed Dec 2 10:48:27 2015 -0600
Committer: Yuki Morishita 
Committed: Tue Mar 22 15:56:06 2016 -0500

--
 CHANGES.txt |  1 +
 bin/cassandra-cli   | 20 ++--
 bin/nodetool| 38 ---
 bin/sstablekeys | 21 +---
 bin/sstableloader   | 13 +++--
 bin/sstablescrub|  7 ++-
 bin/sstableupgrade  | 24 ++
 .../apache/cassandra/tools/SSTableExport.java   |  1 +
 tools/bin/cassandra-stress  | 37 +--
 tools/bin/cassandra-stressd | 50 ++--
 tools/bin/json2sstable  | 19 ++--
 tools/bin/sstable2json  | 20 +---
 tools/bin/sstableexpiredblockers| 10 +++-
 tools/bin/sstablelevelreset | 36 +-
 tools/bin/sstablemetadata   | 22 ++---
 tools/bin/sstableofflinerelevel | 10 +++-
 tools/bin/sstablerepairedset| 49 ---
 tools/bin/sstablesplit  | 29 
 18 files changed, 263 insertions(+), 144 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/42644c32/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 04c9204..5f01114 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.14
+ * Backport CASSANDRA-10679 (CASSANDRA-9598)
  * Don't do defragmentation if reading from repaired sstables (CASSANDRA-10342)
  * Fix streaming_socket_timeout_in_ms not enforced (CASSANDRA-11286)
  * Avoid dropping message too quickly due to missing unit conversion 
(CASSANDRA-11302)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/42644c32/bin/cassandra-cli
--
diff --git a/bin/cassandra-cli b/bin/cassandra-cli
index a2696da..88c9d2f 100755
--- a/bin/cassandra-cli
+++ b/bin/cassandra-cli
@@ -17,11 +17,11 @@
 # limitations under the License.
 
 if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
-for include in "`dirname "$0"`/cassandra.in.sh" \
-   "$HOME/.cassandra.in.sh" \
-   /usr/share/cassandra/cassandra.in.sh \
+for include in /usr/share/cassandra/cassandra.in.sh \
/usr/local/share/cassandra/cassandra.in.sh \
-   /opt/cassandra/cassandra.in.sh; do
+   /opt/cassandra/cassandra.in.sh \
+   "$HOME/.cassandra.in.sh" \
+   "`dirname "$0"`/cassandra.in.sh"; do
 if [ -r "$include" ]; then
 . "$include"
 break
@@ -38,14 +38,24 @@ else
 JAVA="`which java`"
 fi
 
+if [ "x$JAVA" = "x" ]; then
+echo "Java executable not found (hint: set JAVA_HOME)" >&2
+exit 1
+fi
+
 if [ -z "$CLASSPATH" ]; then
 echo "You must set the CLASSPATH var" >&2
 exit 1
 fi
 
-"$JAVA" -ea -cp "$CLASSPATH" -Xmx256M \
+if [ "x$MAX_HEAP_SIZE" = "x" ]; then
+MAX_HEAP_SIZE="256M"
+fi
+
+"$JAVA" $JAVA_AGENT -ea -cp "$CLASSPATH" $JVM_OPTS -Xmx$MAX_HEAP_SIZE \
 -Dcassandra.storagedir="$cassandra_storagedir" \
 -Dlogback.configurationFile=logback-tools.xml \
+$JVM_ARGS \
 org.apache.cassandra.cli.CliMain "$@"
 
 # vi:ai sw=4 ts=4 tw=0 et

http://git-wip-us.apache.org/repos/asf/cassandra/blob/42644c32/bin/nodetool
--
diff --git a/bin/nodetool b/bin/nodetool
index d211459..0ea078f 100755
--- a/bin/nodetool
+++ b/bin/nodetool
@@ -1,4 +1,5 @@
 #!/bin/sh
+
 # Licensed to the Apache Software Foundation (ASF) under one
 # or more contributor license agreements.  See the NOTICE file
 # distributed with this work for additional information
@@ -22,11 +23,11 @@ if [ "`basename "$0"`" = 'nodeprobe' ]; then
 fi
 
 if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
-for include in "`dirname "$0"`/cassandra.in.sh" \
-   "$HOME/.cassandra.in.sh" \
-   /usr/share/cassandra/cassandra.in.sh \
+for include in /usr/share/cassandra/cassandra.in.sh \

[05/15] cassandra git commit: Backport CASSANDRA-10679

[yukim]

Backport CASSANDRA-10679

patch by yukim; reviewed by Jeremiah Jordan for CASSANDRA-9598


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

Branch: refs/heads/cassandra-3.5
Commit: 42644c32401f35d2c4830773ef6a2b690bb21993
Parents: 41bb4bc
Author: Jeremiah D Jordan 
Authored: Wed Dec 2 10:48:27 2015 -0600
Committer: Yuki Morishita 
Committed: Tue Mar 22 15:56:06 2016 -0500

--
 CHANGES.txt |  1 +
 bin/cassandra-cli   | 20 ++--
 bin/nodetool| 38 ---
 bin/sstablekeys | 21 +---
 bin/sstableloader   | 13 +++--
 bin/sstablescrub|  7 ++-
 bin/sstableupgrade  | 24 ++
 .../apache/cassandra/tools/SSTableExport.java   |  1 +
 tools/bin/cassandra-stress  | 37 +--
 tools/bin/cassandra-stressd | 50 ++--
 tools/bin/json2sstable  | 19 ++--
 tools/bin/sstable2json  | 20 +---
 tools/bin/sstableexpiredblockers| 10 +++-
 tools/bin/sstablelevelreset | 36 +-
 tools/bin/sstablemetadata   | 22 ++---
 tools/bin/sstableofflinerelevel | 10 +++-
 tools/bin/sstablerepairedset| 49 ---
 tools/bin/sstablesplit  | 29 
 18 files changed, 263 insertions(+), 144 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/42644c32/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 04c9204..5f01114 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.1.14
+ * Backport CASSANDRA-10679 (CASSANDRA-9598)
  * Don't do defragmentation if reading from repaired sstables (CASSANDRA-10342)
  * Fix streaming_socket_timeout_in_ms not enforced (CASSANDRA-11286)
  * Avoid dropping message too quickly due to missing unit conversion 
(CASSANDRA-11302)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/42644c32/bin/cassandra-cli
--
diff --git a/bin/cassandra-cli b/bin/cassandra-cli
index a2696da..88c9d2f 100755
--- a/bin/cassandra-cli
+++ b/bin/cassandra-cli
@@ -17,11 +17,11 @@
 # limitations under the License.
 
 if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
-for include in "`dirname "$0"`/cassandra.in.sh" \
-   "$HOME/.cassandra.in.sh" \
-   /usr/share/cassandra/cassandra.in.sh \
+for include in /usr/share/cassandra/cassandra.in.sh \
/usr/local/share/cassandra/cassandra.in.sh \
-   /opt/cassandra/cassandra.in.sh; do
+   /opt/cassandra/cassandra.in.sh \
+   "$HOME/.cassandra.in.sh" \
+   "`dirname "$0"`/cassandra.in.sh"; do
 if [ -r "$include" ]; then
 . "$include"
 break
@@ -38,14 +38,24 @@ else
 JAVA="`which java`"
 fi
 
+if [ "x$JAVA" = "x" ]; then
+echo "Java executable not found (hint: set JAVA_HOME)" >&2
+exit 1
+fi
+
 if [ -z "$CLASSPATH" ]; then
 echo "You must set the CLASSPATH var" >&2
 exit 1
 fi
 
-"$JAVA" -ea -cp "$CLASSPATH" -Xmx256M \
+if [ "x$MAX_HEAP_SIZE" = "x" ]; then
+MAX_HEAP_SIZE="256M"
+fi
+
+"$JAVA" $JAVA_AGENT -ea -cp "$CLASSPATH" $JVM_OPTS -Xmx$MAX_HEAP_SIZE \
 -Dcassandra.storagedir="$cassandra_storagedir" \
 -Dlogback.configurationFile=logback-tools.xml \
+$JVM_ARGS \
 org.apache.cassandra.cli.CliMain "$@"
 
 # vi:ai sw=4 ts=4 tw=0 et

http://git-wip-us.apache.org/repos/asf/cassandra/blob/42644c32/bin/nodetool
--
diff --git a/bin/nodetool b/bin/nodetool
index d211459..0ea078f 100755
--- a/bin/nodetool
+++ b/bin/nodetool
@@ -1,4 +1,5 @@
 #!/bin/sh
+
 # Licensed to the Apache Software Foundation (ASF) under one
 # or more contributor license agreements.  See the NOTICE file
 # distributed with this work for additional information
@@ -22,11 +23,11 @@ if [ "`basename "$0"`" = 'nodeprobe' ]; then
 fi
 
 if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
-for include in "`dirname "$0"`/cassandra.in.sh" \
-   "$HOME/.cassandra.in.sh" \
-   /usr/share/cassandra/cassandra.in.sh \
+for include in /usr/share/cassandra/cassandra.in.sh \

[12/15] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[yukim]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.0
Commit: 5e722ee0a0360a589c0497235ead0ea5ee85a805
Parents: 842e7c3 b6d0a75
Author: Yuki Morishita 
Authored: Tue Mar 22 16:09:06 2016 -0500
Committer: Yuki Morishita 
Committed: Tue Mar 22 16:09:06 2016 -0500

--
 CHANGES.txt  |  1 +
 bin/nodetool | 38 +-
 bin/sstableloader| 13 ++---
 bin/sstablescrub |  7 -
 bin/sstableupgrade   | 24 ++---
 bin/sstableutil  |  7 -
 bin/sstableverify|  9 +--
 tools/bin/cassandra-stress   | 37 --
 tools/bin/cassandra-stressd  | 50 ++-
 tools/bin/sstabledump| 20 +-
 tools/bin/sstableexpiredblockers | 10 +--
 tools/bin/sstablelevelreset  | 36 -
 tools/bin/sstablemetadata| 22 ++-
 tools/bin/sstableofflinerelevel  | 10 +--
 tools/bin/sstablerepairedset | 49 +-
 tools/bin/sstablesplit   | 29 +---
 16 files changed, 231 insertions(+), 131 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e722ee0/CHANGES.txt
--
diff --cc CHANGES.txt
index 21eb3e5,91dc588..904206b
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -18,35 -8,13 +18,36 @@@ Merged from 2.2
   * Add missing newline at end of bin/cqlsh (CASSANDRA-11325)
   * Fix AE in nodetool cfstats (backport CASSANDRA-10859) (CASSANDRA-11297)
   * Unresolved hostname leads to replace being ignored (CASSANDRA-11210)
 - * Fix filtering on non-primary key columns for thrift static column families
 -   (CASSANDRA-6377)
   * Only log yaml config once, at startup (CASSANDRA-11217)
 - * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
   * Reference leak with parallel repairs on the same table (CASSANDRA-11215)
 +Merged from 2.1:
++ * Backport CASSANDRA-10679 (CASSANDRA-9598)
 + * InvalidateKeys should have a weak ref to key cache (CASSANDRA-11176)
 + * COPY FROM on large datasets: fix progress report and debug performance 
(CASSANDRA-11053)
 +
 +3.0.4
 + * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
 + * MV should only query complex columns included in the view (CASSANDRA-11069)
 + * Failed aggregate creation breaks server permanently (CASSANDRA-11064)
 + * Add sstabledump tool (CASSANDRA-7464)
 + * Introduce backpressure for hints (CASSANDRA-10972)
 + * Fix ClusteringPrefix not being able to read tombstone range boundaries 
(CASSANDRA-11158)
 + * Prevent logging in sandboxed state (CASSANDRA-11033)
 + * Disallow drop/alter operations of UDTs used by UDAs (CASSANDRA-10721)
 + * Add query time validation method on Index (CASSANDRA-11043)
 + * Avoid potential AssertionError in mixed version cluster (CASSANDRA-11128)
 + * Properly handle hinted handoff after topology changes (CASSANDRA-5902)
 + * AssertionError when listing sstable files on inconsistent disk state 
(CASSANDRA-11156)
 + * Fix wrong rack counting and invalid conditions check for TokenAllocation
 +   (CASSANDRA-11139)
 + * Avoid creating empty hint files (CASSANDRA-11090)
 + * Fix leak detection strong reference loop using weak reference 
(CASSANDRA-11120)
 + * Configurie BatchlogManager to stop delayed tasks on shutdown 
(CASSANDRA-11062)
 + * Hadoop integration is incompatible with Cassandra Driver 3.0.0 
(CASSANDRA-11001)
 + * Add dropped_columns to the list of schema table so it gets handled
 +   properly (CASSANDRA-11050)
 + * Fix NPE when using forceRepairRangeAsync without DC (CASSANDRA-11239)
 +Merged from 2.2:
   * Range.compareTo() violates the contract of Comparable (CASSANDRA-11216)
   * Avoid NPE when serializing ErrorMessage with null message (CASSANDRA-11167)
   * Replacing an aggregate with a new version doesn't reset INITCOND 
(CASSANDRA-10840)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5e722ee0/bin/sstableutil
--
diff --cc bin/sstableutil
index 2860729,000..9f07785
mode 100755,00..100755
--- a/bin/sstableutil
+++ b/bin/sstableutil
@@@ -1,55 -1,0 +1,60 @@@
 +#!/bin/sh
 +
 +# Licensed to the Apache Software Foundation (ASF) under one
 +# or more contributor license agreements.  See the NOTICE file
 +# distributed with this work for additional information
 +# regarding copyright 

[09/15] cassandra git commit: Merge branch 'cassandra-2.1' into cassandra-2.2

[yukim]

Merge branch 'cassandra-2.1' into cassandra-2.2


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

Branch: refs/heads/cassandra-3.5
Commit: b6d0a752e4f681d409518c13bded34086d3d
Parents: c74df40 42644c3
Author: Yuki Morishita 
Authored: Tue Mar 22 16:04:58 2016 -0500
Committer: Yuki Morishita 
Committed: Tue Mar 22 16:04:58 2016 -0500

--
 CHANGES.txt |  1 +
 bin/nodetool| 38 ---
 bin/sstablekeys | 21 +---
 bin/sstableloader   | 13 +++--
 bin/sstablescrub|  7 ++-
 bin/sstableupgrade  | 24 ++
 bin/sstableverify   |  9 +++-
 .../apache/cassandra/tools/SSTableExport.java   |  1 +
 tools/bin/cassandra-stress  | 37 +--
 tools/bin/cassandra-stressd | 50 ++--
 tools/bin/json2sstable  | 19 ++--
 tools/bin/sstable2json  | 20 +---
 tools/bin/sstableexpiredblockers| 10 +++-
 tools/bin/sstablelevelreset | 36 +-
 tools/bin/sstablemetadata   | 22 ++---
 tools/bin/sstableofflinerelevel | 10 +++-
 tools/bin/sstablerepairedset| 49 ---
 tools/bin/sstablesplit  | 29 
 18 files changed, 255 insertions(+), 141 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b6d0a752/CHANGES.txt
--
diff --cc CHANGES.txt
index e4db50e,5f01114..91dc588
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,39 -1,5 +1,40 @@@
 -2.1.14
 +2.2.6
 + * cqlsh: COPY FROM should check that explicit column names are valid 
(CASSANDRA-11333)
 + * Add -Dcassandra.start_gossip startup option (CASSANDRA-10809)
 + * Fix UTF8Validator.validate() for modified UTF-8 (CASSANDRA-10748)
 + * Clarify that now() function is calculated on the coordinator node in CQL 
documentation (CASSANDRA-10900)
 + * Fix bloom filter sizing with LCS (CASSANDRA-11344)
 + * (cqlsh) Fix error when result is 0 rows with EXPAND ON (CASSANDRA-11092)
 + * Fix intra-node serialization issue for multicolumn-restrictions 
(CASSANDRA-11196)
 + * Non-obsoleting compaction operations over compressed files can impose rate 
limit on normal reads (CASSANDRA-11301)
 + * Add missing newline at end of bin/cqlsh (CASSANDRA-11325)
 + * Fix AE in nodetool cfstats (backport CASSANDRA-10859) (CASSANDRA-11297)
 + * Unresolved hostname leads to replace being ignored (CASSANDRA-11210)
 + * Fix filtering on non-primary key columns for thrift static column families
 +   (CASSANDRA-6377)
 + * Only log yaml config once, at startup (CASSANDRA-11217)
 + * Preserve order for preferred SSL cipher suites (CASSANDRA-11164)
 + * Reference leak with parallel repairs on the same table (CASSANDRA-11215)
 + * Range.compareTo() violates the contract of Comparable (CASSANDRA-11216)
 + * Avoid NPE when serializing ErrorMessage with null message (CASSANDRA-11167)
 + * Replacing an aggregate with a new version doesn't reset INITCOND 
(CASSANDRA-10840)
 + * (cqlsh) cqlsh cannot be called through symlink (CASSANDRA-11037)
 + * fix ohc and java-driver pom dependencies in build.xml (CASSANDRA-10793)
 + * Protect from keyspace dropped during repair (CASSANDRA-11065)
 + * Handle adding fields to a UDT in SELECT JSON and toJson() (CASSANDRA-11146)
 + * Better error message for cleanup (CASSANDRA-10991)
 + * cqlsh pg-style-strings broken if line ends with ';' (CASSANDRA-11123)
 + * Use cloned TokenMetadata in size estimates to avoid race against 
membership check
 +   (CASSANDRA-10736)
 + * Always persist upsampled index summaries (CASSANDRA-10512)
 + * (cqlsh) Fix inconsistent auto-complete (CASSANDRA-10733)
 + * Make SELECT JSON and toJson() threadsafe (CASSANDRA-11048)
 + * Fix SELECT on tuple relations for mixed ASC/DESC clustering order 
(CASSANDRA-7281)
 + * (cqlsh) Support utf-8/cp65001 encoding on Windows (CASSANDRA-11030)
 + * Fix paging on DISTINCT queries repeats result when first row in partition 
changes
 +   (CASSANDRA-10010)
 +Merged from 2.1:
+  * Backport CASSANDRA-10679 (CASSANDRA-9598)
   * Don't do defragmentation if reading from repaired sstables 
(CASSANDRA-10342)
   * Fix streaming_socket_timeout_in_ms not enforced (CASSANDRA-11286)
   * Avoid dropping message too quickly due to missing unit conversion 
(CASSANDRA-11302)

[jira] [Updated] (CASSANDRA-11333) cqlsh: COPY FROM should check that explicit column names are valid

[Yuki Morishita (JIRA)]

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

Yuki Morishita updated CASSANDRA-11333:
---
   Resolution: Fixed
Fix Version/s: (was: 3.0.x)
   (was: 2.2.x)
   (was: 3.x)
   3.5
   3.0.5
   2.2.6
   Status: Resolved  (was: Ready to Commit)

Committed. sha1 is c74df401768fe25eb80f9d328cad974c8ab220ad.

> cqlsh: COPY FROM should check that explicit column names are valid
> --
>
> Key: CASSANDRA-11333
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11333
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
>Reporter: Stefania
>Assignee: Stefania
>Priority: Minor
>  Labels: lhf
> Fix For: 2.2.6, 3.0.5, 3.5
>
>
> If an invalid column is specified in the COPY FROM command, then it fails 
> without an appropriate error notification.
> For example using this schema:
> {code}
> CREATE TABLE bulk_read.value500k_cluster1 (
> pk int,
> c1 int,
> v1 text,
> v2 text,
> PRIMARY KEY (pk, c1)
> );
> {code}
> and this COPY FROM command (note the third column name is wrong:
> {code}
> COPY bulk_read.value500k_cluster1 (pk, c1, vv, v2) FROM 'test.csv';
> {code}
> we get the following error:
> {code}
> Starting copy of bulk_read.value500k_cluster1 with columns ['pk', 'c1', 'vv', 
> 'v2'].
> 1 child process(es) died unexpectedly, aborting
> Processed: 0 rows; Rate:   0 rows/s; Avg. rate:   0 rows/s
> 0 rows imported from 0 files in 0.109 seconds (0 skipped).
> {code}
> Running cqlsh with {{--debug}} reveals where the problem is:
> {code}
> Starting copy of bulk_read.value500k_cluster1 with columns ['pk', 'c1', 'vv', 
> 'v2'].
> Traceback (most recent call last):
>   File "/home/automaton/cassandra-src/bin/../pylib/cqlshlib/copyutil.py", 
> line 2005, in run
> self.inner_run(*self.make_params())
>   File "/home/automaton/cassandra-src/bin/../pylib/cqlshlib/copyutil.py", 
> line 2027, in make_params
> is_counter = ("counter" in [table_meta.columns[name].cql_type for name in 
> self.valid_columns])
> {code}
> The parent process should check that all column names are valid and output an 
> appropriate error message rather than letting worker processes crash.



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

[01/13] cassandra git commit: Add -Dcassandra.start_gossip option to skip starting gossip

[yukim]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 b06bcf73f -> c74df4017
  refs/heads/cassandra-3.0 db10cb25c -> 842e7c3fb
  refs/heads/cassandra-3.5 16d1c8116 -> 1ee550262
  refs/heads/trunk e24da8f7f -> 207d08f86


Add -Dcassandra.start_gossip option to skip starting gossip

patch by slebresne; reviewed by brandon.williams for CASSANDRA-10809


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

Branch: refs/heads/trunk
Commit: b06bcf73fb50c8e887d4469042543a9d78f7848c
Parents: 42cd66a
Author: Sylvain Lebresne 
Authored: Thu Mar 17 17:21:06 2016 +0100
Committer: Sylvain Lebresne 
Committed: Fri Mar 18 10:53:33 2016 +0100

--
 CHANGES.txt   | 1 +
 src/java/org/apache/cassandra/service/StorageService.java | 7 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/b06bcf73/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index fa4a726..bcdf189 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.6
+ * Add -Dcassandra.start_gossip startup option (CASSANDRA-10809)
  * Fix UTF8Validator.validate() for modified UTF-8 (CASSANDRA-10748)
  * Clarify that now() function is calculated on the coordinator node in CQL 
documentation (CASSANDRA-10900)
  * Fix bloom filter sizing with LCS (CASSANDRA-11344)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/b06bcf73/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index 0e716e8..9a0ba5d 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -690,6 +690,12 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 
 replacing = DatabaseDescriptor.isReplacing();
 
+if (!Boolean.parseBoolean(System.getProperty("cassandra.start_gossip", 
"true")))
+{
+logger.info("Not starting gossip as requested.");
+return;
+}
+
 prepareToJoin();
 
 // Has to be called after the host id has potentially changed in 
prepareToJoin().
@@ -703,7 +709,6 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 logger.warn("Error loading counter cache", t);
 }
 
-
 if (Boolean.parseBoolean(System.getProperty("cassandra.join_ring", 
"true")))
 {
 joinTokenRing(delay);

[11/13] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.5

[yukim]

Merge branch 'cassandra-3.0' into cassandra-3.5


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

Branch: refs/heads/trunk
Commit: 1ee550262b9b0c88b4082218e41c93d6c1520c98
Parents: 16d1c81 842e7c3
Author: Yuki Morishita 
Authored: Tue Mar 22 15:50:35 2016 -0500
Committer: Yuki Morishita 
Committed: Tue Mar 22 15:50:35 2016 -0500

--
 CHANGES.txt|  1 +
 pylib/cqlshlib/copyutil.py | 43 +++--
 2 files changed, 34 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1ee55026/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1ee55026/pylib/cqlshlib/copyutil.py
--

[09/13] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[yukim]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.5
Commit: 842e7c3fbf93c7a0191c7314f00d84057634bf92
Parents: db10cb2 c74df40
Author: Yuki Morishita 
Authored: Tue Mar 22 15:50:21 2016 -0500
Committer: Yuki Morishita 
Committed: Tue Mar 22 15:50:21 2016 -0500

--
 CHANGES.txt|  1 +
 pylib/cqlshlib/copyutil.py | 43 +++--
 2 files changed, 34 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/842e7c3f/CHANGES.txt
--
diff --cc CHANGES.txt
index a077551,e4db50e..21eb3e5
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,14 -1,5 +1,15 @@@
 -2.2.6
 +3.0.5
 + * Support streaming pre-3.0 sstables (CASSANDRA-10990)
 + * Add backpressure to compressed commit log (CASSANDRA-10971)
 + * SSTableExport supports secondary index tables (CASSANDRA-11330)
 + * Fix sstabledump to include missing info in debug output (CASSANDRA-11321)
 + * Establish and implement canonical bulk reading workload(s) 
(CASSANDRA-10331)
 + * Fix paging for IN queries on tables without clustering columns 
(CASSANDRA-11208)
 + * Remove recursive call from CompositesSearcher (CASSANDRA-11304)
 + * Fix filtering on non-primary key columns for queries without index 
(CASSANDRA-6377)
 + * Fix sstableloader fail when using materialized view (CASSANDRA-11275)
 +Merged from 2.2:
+  * cqlsh: COPY FROM should check that explicit column names are valid 
(CASSANDRA-11333)
   * Add -Dcassandra.start_gossip startup option (CASSANDRA-10809)
   * Fix UTF8Validator.validate() for modified UTF-8 (CASSANDRA-10748)
   * Clarify that now() function is calculated on the coordinator node in CQL 
documentation (CASSANDRA-10900)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/842e7c3f/pylib/cqlshlib/copyutil.py
--

[10/13] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[yukim]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/trunk
Commit: 842e7c3fbf93c7a0191c7314f00d84057634bf92
Parents: db10cb2 c74df40
Author: Yuki Morishita 
Authored: Tue Mar 22 15:50:21 2016 -0500
Committer: Yuki Morishita 
Committed: Tue Mar 22 15:50:21 2016 -0500

--
 CHANGES.txt|  1 +
 pylib/cqlshlib/copyutil.py | 43 +++--
 2 files changed, 34 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/842e7c3f/CHANGES.txt
--
diff --cc CHANGES.txt
index a077551,e4db50e..21eb3e5
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,14 -1,5 +1,15 @@@
 -2.2.6
 +3.0.5
 + * Support streaming pre-3.0 sstables (CASSANDRA-10990)
 + * Add backpressure to compressed commit log (CASSANDRA-10971)
 + * SSTableExport supports secondary index tables (CASSANDRA-11330)
 + * Fix sstabledump to include missing info in debug output (CASSANDRA-11321)
 + * Establish and implement canonical bulk reading workload(s) 
(CASSANDRA-10331)
 + * Fix paging for IN queries on tables without clustering columns 
(CASSANDRA-11208)
 + * Remove recursive call from CompositesSearcher (CASSANDRA-11304)
 + * Fix filtering on non-primary key columns for queries without index 
(CASSANDRA-6377)
 + * Fix sstableloader fail when using materialized view (CASSANDRA-11275)
 +Merged from 2.2:
+  * cqlsh: COPY FROM should check that explicit column names are valid 
(CASSANDRA-11333)
   * Add -Dcassandra.start_gossip startup option (CASSANDRA-10809)
   * Fix UTF8Validator.validate() for modified UTF-8 (CASSANDRA-10748)
   * Clarify that now() function is calculated on the coordinator node in CQL 
documentation (CASSANDRA-10900)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/842e7c3f/pylib/cqlshlib/copyutil.py
--

[12/13] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.5

[yukim]

Merge branch 'cassandra-3.0' into cassandra-3.5


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

Branch: refs/heads/cassandra-3.5
Commit: 1ee550262b9b0c88b4082218e41c93d6c1520c98
Parents: 16d1c81 842e7c3
Author: Yuki Morishita 
Authored: Tue Mar 22 15:50:35 2016 -0500
Committer: Yuki Morishita 
Committed: Tue Mar 22 15:50:35 2016 -0500

--
 CHANGES.txt|  1 +
 pylib/cqlshlib/copyutil.py | 43 +++--
 2 files changed, 34 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/1ee55026/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/1ee55026/pylib/cqlshlib/copyutil.py
--

[03/13] cassandra git commit: Merge branch 'cassandra-3.0' into cassandra-3.5

[yukim]

Merge branch 'cassandra-3.0' into cassandra-3.5


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

Branch: refs/heads/trunk
Commit: 16d1c81163ea67363cdd402dff828e4e4d425998
Parents: ef86d91 db10cb2
Author: Sylvain Lebresne 
Authored: Fri Mar 18 10:54:31 2016 +0100
Committer: Sylvain Lebresne 
Committed: Fri Mar 18 10:54:31 2016 +0100

--

--

[07/13] cassandra git commit: cqlsh: COPY FROM should check that explicit column names are valid

[yukim]

cqlsh: COPY FROM should check that explicit column names are valid

patch by Stefania Alborghetti; reviewed by Paulo Motta for CASSANDRA-11333


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

Branch: refs/heads/trunk
Commit: c74df401768fe25eb80f9d328cad974c8ab220ad
Parents: b06bcf7
Author: Stefania Alborghetti 
Authored: Wed Mar 16 17:42:54 2016 +0800
Committer: Yuki Morishita 
Committed: Tue Mar 22 15:49:20 2016 -0500

--
 CHANGES.txt|  1 +
 pylib/cqlshlib/copyutil.py | 43 +++--
 2 files changed, 34 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c74df401/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index bcdf189..e4db50e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.6
+ * cqlsh: COPY FROM should check that explicit column names are valid 
(CASSANDRA-11333)
  * Add -Dcassandra.start_gossip startup option (CASSANDRA-10809)
  * Fix UTF8Validator.validate() for modified UTF-8 (CASSANDRA-10748)
  * Clarify that now() function is calculated on the coordinator node in CQL 
documentation (CASSANDRA-10900)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c74df401/pylib/cqlshlib/copyutil.py
--
diff --git a/pylib/cqlshlib/copyutil.py b/pylib/cqlshlib/copyutil.py
index 2755dd5..d08a4fd 100644
--- a/pylib/cqlshlib/copyutil.py
+++ b/pylib/cqlshlib/copyutil.py
@@ -152,6 +152,7 @@ class CopyTask(object):
 self.shell = shell
 self.ks = ks
 self.table = table
+self.table_meta = self.shell.get_table_meta(self.ks, self.table)
 self.local_dc = shell.conn.metadata.get_host(shell.hostname).datacenter
 self.fname = safe_normpath(fname)
 self.protocol_version = protocol_version
@@ -386,6 +387,20 @@ class CopyTask(object):
 debug=shell.debug
 )
 
+def validate_columns(self):
+shell = self.shell
+
+if not self.columns:
+shell.printerr("No column specified")
+return False
+
+for c in self.columns:
+if c not in self.table_meta.columns:
+shell.printerr('Invalid column name %s' % (c,))
+return False
+
+return True
+
 def update_params(self, params, i):
 """
 Add the communication channels to the parameters to be passed to the 
worker process:
@@ -515,8 +530,7 @@ class ExportTask(CopyTask):
 shell.printerr('Unrecognized COPY TO options: %s' % ', 
'.join(self.options.unrecognized.keys()))
 return
 
-if not self.columns:
-shell.printerr("No column specified")
+if not self.validate_columns():
 return 0
 
 ranges = self.get_ranges()
@@ -987,7 +1001,6 @@ class ImportTask(CopyTask):
 options = self.options
 self.skip_columns = [c.strip() for c in 
self.options.copy['skipcols'].split(',')]
 self.valid_columns = [c for c in self.columns if c not in 
self.skip_columns]
-self.table_meta = self.shell.get_table_meta(self.ks, self.table)
 self.receive_meter = RateMeter(log_fcn=self.printmsg,

update_interval=options.copy['reportfrequency'],
log_file=options.copy['ratefile'])
@@ -1001,6 +1014,22 @@ class ImportTask(CopyTask):
 ret['valid_columns'] = self.valid_columns
 return ret
 
+def validate_columns(self):
+if not CopyTask.validate_columns(self):
+return False
+
+shell = self.shell
+if not self.valid_columns:
+shell.printerr("No valid column specified")
+return False
+
+for c in self.table_meta.primary_key:
+if c.name not in self.valid_columns:
+shell.printerr("Primary key column '%s' missing or skipped" % 
(c.name,))
+return False
+
+return True
+
 def run(self):
 shell = self.shell
 
@@ -1008,15 +1037,9 @@ class ImportTask(CopyTask):
 shell.printerr('Unrecognized COPY FROM options: %s' % ', 
'.join(self.options.unrecognized.keys()))
 return
 
-if not self.valid_columns:
-shell.printerr("No column specified")
+if not self.validate_columns():
 return 0
 
-for c in self.table_meta.primary_key:
-if c.name not in self.valid_columns:
-

[13/13] cassandra git commit: Merge branch 'cassandra-3.5' into trunk

[yukim]

Merge branch 'cassandra-3.5' into trunk


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

Branch: refs/heads/trunk
Commit: 207d08f86c5027a7dc332778b59e705adbab031f
Parents: e24da8f 1ee5502
Author: Yuki Morishita 
Authored: Tue Mar 22 15:50:42 2016 -0500
Committer: Yuki Morishita 
Committed: Tue Mar 22 15:50:42 2016 -0500

--
 CHANGES.txt|  1 +
 pylib/cqlshlib/copyutil.py | 43 +++--
 2 files changed, 34 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/207d08f8/CHANGES.txt
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/207d08f8/pylib/cqlshlib/copyutil.py
--

[05/13] cassandra git commit: cqlsh: COPY FROM should check that explicit column names are valid

[yukim]

cqlsh: COPY FROM should check that explicit column names are valid

patch by Stefania Alborghetti; reviewed by Paulo Motta for CASSANDRA-11333


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

Branch: refs/heads/cassandra-3.0
Commit: c74df401768fe25eb80f9d328cad974c8ab220ad
Parents: b06bcf7
Author: Stefania Alborghetti 
Authored: Wed Mar 16 17:42:54 2016 +0800
Committer: Yuki Morishita 
Committed: Tue Mar 22 15:49:20 2016 -0500

--
 CHANGES.txt|  1 +
 pylib/cqlshlib/copyutil.py | 43 +++--
 2 files changed, 34 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c74df401/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index bcdf189..e4db50e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.6
+ * cqlsh: COPY FROM should check that explicit column names are valid 
(CASSANDRA-11333)
  * Add -Dcassandra.start_gossip startup option (CASSANDRA-10809)
  * Fix UTF8Validator.validate() for modified UTF-8 (CASSANDRA-10748)
  * Clarify that now() function is calculated on the coordinator node in CQL 
documentation (CASSANDRA-10900)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c74df401/pylib/cqlshlib/copyutil.py
--
diff --git a/pylib/cqlshlib/copyutil.py b/pylib/cqlshlib/copyutil.py
index 2755dd5..d08a4fd 100644
--- a/pylib/cqlshlib/copyutil.py
+++ b/pylib/cqlshlib/copyutil.py
@@ -152,6 +152,7 @@ class CopyTask(object):
 self.shell = shell
 self.ks = ks
 self.table = table
+self.table_meta = self.shell.get_table_meta(self.ks, self.table)
 self.local_dc = shell.conn.metadata.get_host(shell.hostname).datacenter
 self.fname = safe_normpath(fname)
 self.protocol_version = protocol_version
@@ -386,6 +387,20 @@ class CopyTask(object):
 debug=shell.debug
 )
 
+def validate_columns(self):
+shell = self.shell
+
+if not self.columns:
+shell.printerr("No column specified")
+return False
+
+for c in self.columns:
+if c not in self.table_meta.columns:
+shell.printerr('Invalid column name %s' % (c,))
+return False
+
+return True
+
 def update_params(self, params, i):
 """
 Add the communication channels to the parameters to be passed to the 
worker process:
@@ -515,8 +530,7 @@ class ExportTask(CopyTask):
 shell.printerr('Unrecognized COPY TO options: %s' % ', 
'.join(self.options.unrecognized.keys()))
 return
 
-if not self.columns:
-shell.printerr("No column specified")
+if not self.validate_columns():
 return 0
 
 ranges = self.get_ranges()
@@ -987,7 +1001,6 @@ class ImportTask(CopyTask):
 options = self.options
 self.skip_columns = [c.strip() for c in 
self.options.copy['skipcols'].split(',')]
 self.valid_columns = [c for c in self.columns if c not in 
self.skip_columns]
-self.table_meta = self.shell.get_table_meta(self.ks, self.table)
 self.receive_meter = RateMeter(log_fcn=self.printmsg,

update_interval=options.copy['reportfrequency'],
log_file=options.copy['ratefile'])
@@ -1001,6 +1014,22 @@ class ImportTask(CopyTask):
 ret['valid_columns'] = self.valid_columns
 return ret
 
+def validate_columns(self):
+if not CopyTask.validate_columns(self):
+return False
+
+shell = self.shell
+if not self.valid_columns:
+shell.printerr("No valid column specified")
+return False
+
+for c in self.table_meta.primary_key:
+if c.name not in self.valid_columns:
+shell.printerr("Primary key column '%s' missing or skipped" % 
(c.name,))
+return False
+
+return True
+
 def run(self):
 shell = self.shell
 
@@ -1008,15 +1037,9 @@ class ImportTask(CopyTask):
 shell.printerr('Unrecognized COPY FROM options: %s' % ', 
'.join(self.options.unrecognized.keys()))
 return
 
-if not self.valid_columns:
-shell.printerr("No column specified")
+if not self.validate_columns():
 return 0
 
-for c in self.table_meta.primary_key:
-if c.name not in self.valid_columns:
-

[04/13] cassandra git commit: cqlsh: COPY FROM should check that explicit column names are valid

[yukim]

cqlsh: COPY FROM should check that explicit column names are valid

patch by Stefania Alborghetti; reviewed by Paulo Motta for CASSANDRA-11333


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

Branch: refs/heads/cassandra-3.5
Commit: c74df401768fe25eb80f9d328cad974c8ab220ad
Parents: b06bcf7
Author: Stefania Alborghetti 
Authored: Wed Mar 16 17:42:54 2016 +0800
Committer: Yuki Morishita 
Committed: Tue Mar 22 15:49:20 2016 -0500

--
 CHANGES.txt|  1 +
 pylib/cqlshlib/copyutil.py | 43 +++--
 2 files changed, 34 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c74df401/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index bcdf189..e4db50e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.6
+ * cqlsh: COPY FROM should check that explicit column names are valid 
(CASSANDRA-11333)
  * Add -Dcassandra.start_gossip startup option (CASSANDRA-10809)
  * Fix UTF8Validator.validate() for modified UTF-8 (CASSANDRA-10748)
  * Clarify that now() function is calculated on the coordinator node in CQL 
documentation (CASSANDRA-10900)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c74df401/pylib/cqlshlib/copyutil.py
--
diff --git a/pylib/cqlshlib/copyutil.py b/pylib/cqlshlib/copyutil.py
index 2755dd5..d08a4fd 100644
--- a/pylib/cqlshlib/copyutil.py
+++ b/pylib/cqlshlib/copyutil.py
@@ -152,6 +152,7 @@ class CopyTask(object):
 self.shell = shell
 self.ks = ks
 self.table = table
+self.table_meta = self.shell.get_table_meta(self.ks, self.table)
 self.local_dc = shell.conn.metadata.get_host(shell.hostname).datacenter
 self.fname = safe_normpath(fname)
 self.protocol_version = protocol_version
@@ -386,6 +387,20 @@ class CopyTask(object):
 debug=shell.debug
 )
 
+def validate_columns(self):
+shell = self.shell
+
+if not self.columns:
+shell.printerr("No column specified")
+return False
+
+for c in self.columns:
+if c not in self.table_meta.columns:
+shell.printerr('Invalid column name %s' % (c,))
+return False
+
+return True
+
 def update_params(self, params, i):
 """
 Add the communication channels to the parameters to be passed to the 
worker process:
@@ -515,8 +530,7 @@ class ExportTask(CopyTask):
 shell.printerr('Unrecognized COPY TO options: %s' % ', 
'.join(self.options.unrecognized.keys()))
 return
 
-if not self.columns:
-shell.printerr("No column specified")
+if not self.validate_columns():
 return 0
 
 ranges = self.get_ranges()
@@ -987,7 +1001,6 @@ class ImportTask(CopyTask):
 options = self.options
 self.skip_columns = [c.strip() for c in 
self.options.copy['skipcols'].split(',')]
 self.valid_columns = [c for c in self.columns if c not in 
self.skip_columns]
-self.table_meta = self.shell.get_table_meta(self.ks, self.table)
 self.receive_meter = RateMeter(log_fcn=self.printmsg,

update_interval=options.copy['reportfrequency'],
log_file=options.copy['ratefile'])
@@ -1001,6 +1014,22 @@ class ImportTask(CopyTask):
 ret['valid_columns'] = self.valid_columns
 return ret
 
+def validate_columns(self):
+if not CopyTask.validate_columns(self):
+return False
+
+shell = self.shell
+if not self.valid_columns:
+shell.printerr("No valid column specified")
+return False
+
+for c in self.table_meta.primary_key:
+if c.name not in self.valid_columns:
+shell.printerr("Primary key column '%s' missing or skipped" % 
(c.name,))
+return False
+
+return True
+
 def run(self):
 shell = self.shell
 
@@ -1008,15 +1037,9 @@ class ImportTask(CopyTask):
 shell.printerr('Unrecognized COPY FROM options: %s' % ', 
'.join(self.options.unrecognized.keys()))
 return
 
-if not self.valid_columns:
-shell.printerr("No column specified")
+if not self.validate_columns():
 return 0
 
-for c in self.table_meta.primary_key:
-if c.name not in self.valid_columns:
-

[06/13] cassandra git commit: cqlsh: COPY FROM should check that explicit column names are valid

[yukim]

cqlsh: COPY FROM should check that explicit column names are valid

patch by Stefania Alborghetti; reviewed by Paulo Motta for CASSANDRA-11333


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

Branch: refs/heads/cassandra-2.2
Commit: c74df401768fe25eb80f9d328cad974c8ab220ad
Parents: b06bcf7
Author: Stefania Alborghetti 
Authored: Wed Mar 16 17:42:54 2016 +0800
Committer: Yuki Morishita 
Committed: Tue Mar 22 15:49:20 2016 -0500

--
 CHANGES.txt|  1 +
 pylib/cqlshlib/copyutil.py | 43 +++--
 2 files changed, 34 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/c74df401/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index bcdf189..e4db50e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 2.2.6
+ * cqlsh: COPY FROM should check that explicit column names are valid 
(CASSANDRA-11333)
  * Add -Dcassandra.start_gossip startup option (CASSANDRA-10809)
  * Fix UTF8Validator.validate() for modified UTF-8 (CASSANDRA-10748)
  * Clarify that now() function is calculated on the coordinator node in CQL 
documentation (CASSANDRA-10900)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/c74df401/pylib/cqlshlib/copyutil.py
--
diff --git a/pylib/cqlshlib/copyutil.py b/pylib/cqlshlib/copyutil.py
index 2755dd5..d08a4fd 100644
--- a/pylib/cqlshlib/copyutil.py
+++ b/pylib/cqlshlib/copyutil.py
@@ -152,6 +152,7 @@ class CopyTask(object):
 self.shell = shell
 self.ks = ks
 self.table = table
+self.table_meta = self.shell.get_table_meta(self.ks, self.table)
 self.local_dc = shell.conn.metadata.get_host(shell.hostname).datacenter
 self.fname = safe_normpath(fname)
 self.protocol_version = protocol_version
@@ -386,6 +387,20 @@ class CopyTask(object):
 debug=shell.debug
 )
 
+def validate_columns(self):
+shell = self.shell
+
+if not self.columns:
+shell.printerr("No column specified")
+return False
+
+for c in self.columns:
+if c not in self.table_meta.columns:
+shell.printerr('Invalid column name %s' % (c,))
+return False
+
+return True
+
 def update_params(self, params, i):
 """
 Add the communication channels to the parameters to be passed to the 
worker process:
@@ -515,8 +530,7 @@ class ExportTask(CopyTask):
 shell.printerr('Unrecognized COPY TO options: %s' % ', 
'.join(self.options.unrecognized.keys()))
 return
 
-if not self.columns:
-shell.printerr("No column specified")
+if not self.validate_columns():
 return 0
 
 ranges = self.get_ranges()
@@ -987,7 +1001,6 @@ class ImportTask(CopyTask):
 options = self.options
 self.skip_columns = [c.strip() for c in 
self.options.copy['skipcols'].split(',')]
 self.valid_columns = [c for c in self.columns if c not in 
self.skip_columns]
-self.table_meta = self.shell.get_table_meta(self.ks, self.table)
 self.receive_meter = RateMeter(log_fcn=self.printmsg,

update_interval=options.copy['reportfrequency'],
log_file=options.copy['ratefile'])
@@ -1001,6 +1014,22 @@ class ImportTask(CopyTask):
 ret['valid_columns'] = self.valid_columns
 return ret
 
+def validate_columns(self):
+if not CopyTask.validate_columns(self):
+return False
+
+shell = self.shell
+if not self.valid_columns:
+shell.printerr("No valid column specified")
+return False
+
+for c in self.table_meta.primary_key:
+if c.name not in self.valid_columns:
+shell.printerr("Primary key column '%s' missing or skipped" % 
(c.name,))
+return False
+
+return True
+
 def run(self):
 shell = self.shell
 
@@ -1008,15 +1037,9 @@ class ImportTask(CopyTask):
 shell.printerr('Unrecognized COPY FROM options: %s' % ', 
'.join(self.options.unrecognized.keys()))
 return
 
-if not self.valid_columns:
-shell.printerr("No column specified")
+if not self.validate_columns():
 return 0
 
-for c in self.table_meta.primary_key:
-if c.name not in self.valid_columns:
-

[08/13] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[yukim]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/cassandra-3.0
Commit: 842e7c3fbf93c7a0191c7314f00d84057634bf92
Parents: db10cb2 c74df40
Author: Yuki Morishita 
Authored: Tue Mar 22 15:50:21 2016 -0500
Committer: Yuki Morishita 
Committed: Tue Mar 22 15:50:21 2016 -0500

--
 CHANGES.txt|  1 +
 pylib/cqlshlib/copyutil.py | 43 +++--
 2 files changed, 34 insertions(+), 10 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/842e7c3f/CHANGES.txt
--
diff --cc CHANGES.txt
index a077551,e4db50e..21eb3e5
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,14 -1,5 +1,15 @@@
 -2.2.6
 +3.0.5
 + * Support streaming pre-3.0 sstables (CASSANDRA-10990)
 + * Add backpressure to compressed commit log (CASSANDRA-10971)
 + * SSTableExport supports secondary index tables (CASSANDRA-11330)
 + * Fix sstabledump to include missing info in debug output (CASSANDRA-11321)
 + * Establish and implement canonical bulk reading workload(s) 
(CASSANDRA-10331)
 + * Fix paging for IN queries on tables without clustering columns 
(CASSANDRA-11208)
 + * Remove recursive call from CompositesSearcher (CASSANDRA-11304)
 + * Fix filtering on non-primary key columns for queries without index 
(CASSANDRA-6377)
 + * Fix sstableloader fail when using materialized view (CASSANDRA-11275)
 +Merged from 2.2:
+  * cqlsh: COPY FROM should check that explicit column names are valid 
(CASSANDRA-11333)
   * Add -Dcassandra.start_gossip startup option (CASSANDRA-10809)
   * Fix UTF8Validator.validate() for modified UTF-8 (CASSANDRA-10748)
   * Clarify that now() function is calculated on the coordinator node in CQL 
documentation (CASSANDRA-10900)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/842e7c3f/pylib/cqlshlib/copyutil.py
--

[02/13] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[yukim]

Merge branch 'cassandra-2.2' into cassandra-3.0


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

Branch: refs/heads/trunk
Commit: db10cb25c036175ac51474ea1e1169524d0e98a6
Parents: 1dbfa4b b06bcf7
Author: Sylvain Lebresne 
Authored: Fri Mar 18 10:54:16 2016 +0100
Committer: Sylvain Lebresne 
Committed: Fri Mar 18 10:54:16 2016 +0100

--

--

[jira] [Updated] (CASSANDRA-11392) Add auto import java.util for UDF code block

[DOAN DuyHai (JIRA)]

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

DOAN DuyHai updated CASSANDRA-11392:

Attachment: patch.txt

Patch attached

Just adding {{import java.util.*}} in the {{JavaSourceUDF.txt}} template file 
and added an unit test to check that it works

> Add auto import java.util for UDF code block
> 
>
> Key: CASSANDRA-11392
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11392
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
> Environment: C* 3.4
>Reporter: DOAN DuyHai
>Priority: Minor
> Fix For: 3.6
>
> Attachments: patch.txt
>
>
> Right now, when creating Java source code for UDF, since we cannot define 
> import, we need to use fully qualified class name, ex:
> {noformat}
> CREATE FUNCTION toSet(li list)
> CALLED ON NULL INPUT
> RETURNS text
> LANGUAGE java
> AS $$
> java.util.Set set = new java.util.HashSet();
> for(String txt: list) {
> set.add(txt);
> }
> return set;
> $$;
> {noformat}
> Classes from {{java.util}} package are so commonly used that it makes 
> developer life easier to import automatically {{java.util.*}} in the 
> {{JavaUDF}} base class so that developers don't need to use FQCN for common 
> classes.
>  The only drawback I can see is the risk of class name clash but since:
> 1. it is not allow to create new class
> 2. classes that can be used in UDF are restricted
>  I don't see serious clash name issues either
> [~snazy] WDYT ?
>  



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

[jira] [Updated] (CASSANDRA-11392) Add auto import java.util for UDF code block

[DOAN DuyHai (JIRA)]

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

DOAN DuyHai updated CASSANDRA-11392:

Fix Version/s: 3.6
Reproduced In: 3.4
   Status: Patch Available  (was: Open)

> Add auto import java.util for UDF code block
> 
>
> Key: CASSANDRA-11392
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11392
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
> Environment: C* 3.4
>Reporter: DOAN DuyHai
>Priority: Minor
> Fix For: 3.6
>
>
> Right now, when creating Java source code for UDF, since we cannot define 
> import, we need to use fully qualified class name, ex:
> {noformat}
> CREATE FUNCTION toSet(li list)
> CALLED ON NULL INPUT
> RETURNS text
> LANGUAGE java
> AS $$
> java.util.Set set = new java.util.HashSet();
> for(String txt: list) {
> set.add(txt);
> }
> return set;
> $$;
> {noformat}
> Classes from {{java.util}} package are so commonly used that it makes 
> developer life easier to import automatically {{java.util.*}} in the 
> {{JavaUDF}} base class so that developers don't need to use FQCN for common 
> classes.
>  The only drawback I can see is the risk of class name clash but since:
> 1. it is not allow to create new class
> 2. classes that can be used in UDF are restricted
>  I don't see serious clash name issues either
> [~snazy] WDYT ?
>  



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

[jira] [Comment Edited] (CASSANDRA-11388) FailureDetector.java:456 - Ignoring interval time of

[Joel Knighton (JIRA)]

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

Joel Knighton edited comment on CASSANDRA-11388 at 3/22/16 8:38 PM:


This message alone is not cause for concern. 

In the future, the bug tracker is for reports of issues you've identified or 
concrete improvements you'd like to propose.

The Cassandra user mailing list or Cassandra IRC can help you determine if 
something is likely an issue if you aren't sure.


was (Author: jkni):
This message alone is not cause for concern. 

In the future, the bug tracker is for reports of issues you've identified or 
concrete improvements you'd like to propose.

The Cassandra user mailing list or Cassandra IRC can help you determinate if 
something is likely an issue if you aren't sure.

> FailureDetector.java:456 - Ignoring interval time of
> 
>
> Key: CASSANDRA-11388
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11388
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Cassandra 2.2.4
>Reporter: Relish Chackochan
>Priority: Minor
>
> We have Cassandra Cluster of 8 nodes with 2.2.4v using jdk1.8.0_65 ( RHEL 6.5 
> 64-bit ) and i am seeing the following error in the Cassandra debug.log file. 
> All the nodes are UP and running with
> "nodetool status". NTP is configured on all nodes and Time syncing well.
> DEBUG [GossipStage:1] 2016-03-21 06:45:30,700 FailureDetector.java:456 - 
> Ignoring interval time of 3069815316 for /192.168.1.153
> DEBUG [GossipStage:1] 2016-03-21 06:45:30,700 FailureDetector.java:456 - 
> Ignoring interval time of 2076119905 for /192.168.1.135
> DEBUG [GossipStage:1] 2016-03-21 06:45:30,700 FailureDetector.java:456 - 
> Ignoring interval time of 2683887772 for /192.168.1.151



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

[jira] [Resolved] (CASSANDRA-11388) FailureDetector.java:456 - Ignoring interval time of

[Joel Knighton (JIRA)]

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

Joel Knighton resolved CASSANDRA-11388.
---
Resolution: Not A Problem

This message alone is not cause for concern. 

In the future, the bug tracker is for reports of issues you've identified or 
concrete improvements you'd like to propose.

The Cassandra user mailing list or Cassandra IRC can help you determinate if 
something is likely an issue if you aren't sure.

> FailureDetector.java:456 - Ignoring interval time of
> 
>
> Key: CASSANDRA-11388
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11388
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Cassandra 2.2.4
>Reporter: Relish Chackochan
>Priority: Minor
>
> We have Cassandra Cluster of 8 nodes with 2.2.4v using jdk1.8.0_65 ( RHEL 6.5 
> 64-bit ) and i am seeing the following error in the Cassandra debug.log file. 
> All the nodes are UP and running with
> "nodetool status". NTP is configured on all nodes and Time syncing well.
> DEBUG [GossipStage:1] 2016-03-21 06:45:30,700 FailureDetector.java:456 - 
> Ignoring interval time of 3069815316 for /192.168.1.153
> DEBUG [GossipStage:1] 2016-03-21 06:45:30,700 FailureDetector.java:456 - 
> Ignoring interval time of 2076119905 for /192.168.1.135
> DEBUG [GossipStage:1] 2016-03-21 06:45:30,700 FailureDetector.java:456 - 
> Ignoring interval time of 2683887772 for /192.168.1.151



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

[jira] [Resolved] (CASSANDRA-11401) [Regression] Incorrect results for clustering tuples query

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs resolved CASSANDRA-11401.
-
Resolution: Not A Problem

Okay, resolving as Not a Problem, then.

It's worth noting that if we supported {{OR}}, we could perform the contiguous 
slices you're looking for as explained in [this 
comment|https://issues.apache.org/jira/browse/CASSANDRA-6875?focusedCommentId=13992153=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13992153].
  However, it's probably not worth introducing all of the complexities of 
{{OR}} just for that, at this time.

> [Regression] Incorrect results for clustering tuples query
> --
>
> Key: CASSANDRA-11401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11401
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: *Cassandra 3.4*
>Reporter: DOAN DuyHai
>Priority: Critical
>
> There is a regression since *Cassandra 3.4* with query using clustering tuple 
> values:
> {noformat}
> cqlsh:test> CREATE TABLE IF NOT EXISTS entity_with_clusterings(
>   id bigint,
>   uuid uuid,
>   date timestamp,
>   value text,
>   PRIMARY KEY(id, uuid, date))
> WITH CLUSTERING ORDER BY(uuid ASC, date DESC);
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-01 
> 00:00:00+', 'val1');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-02 
> 00:00:00+', 'val2');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-03 
> 00:00:00+', 'val3');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----0001, '2015-10-04 
> 00:00:00+', 'val4');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----0001, '2015-10-05 
> 00:00:00+', 'val5');
> cqlsh:test> SELECT * FROM entity_with_clusterings;
>  id  | uuid | date
>  | value
> -+--+--+---
>  3233835834146573312 | ---- | 2015-10-03 
> 00:00:00+ |  val3
>  3233835834146573312 | ---- | 2015-10-02 
> 00:00:00+ |  val2
>  3233835834146573312 | ---- | 2015-10-01 
> 00:00:00+ |  val1
>  3233835834146573312 | ----0001 | 2015-10-05 
> 00:00:00+ |  val5
>  3233835834146573312 | ----0001 | 2015-10-04 
> 00:00:00+ |  val4
> (5 rows)
> cqlsh:test > SELECT uuid,date,value 
> FROM entity_with_clusterings 
> WHERE id=3233835834146573312 
> AND (uuid,date)>=(----,'2015-10-02 
> 00:00:00+') 
> AND (uuid,date)<(----0001, '2015-10-04 
> 00:00:00+');
>  uuid | date| 
> value
> --+-+---
>  ---- | 2015-10-03 00:00:00.00+ |  
> val3
>  ---- | 2015-10-02 00:00:00.00+ |  
> val2
> {noformat}
> The same query with *Cassandra 3.3* returns correct answer:
> {noformat}
> cqlsh:test> SELECT uuid,date,value
> FROM entity_with_clusterings
> WHERE id=3233835834146573312
> AND (uuid,date)>=(----,'2015-10-02 
> 00:00:00+')
> AND (uuid,date)<(----0001, '2015-10-04 
> 00:00:00+');
>  uuid | date | value
> --+--+---
>  ---- | 2015-10-02 00:00:00+ |  val2
>  ---- | 2015-10-01 00:00:00+ |  val1
>  ----0001 | 2015-10-05 00:00:00+ |  val5
> {noformat}



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

[jira] [Commented] (CASSANDRA-9967) Determine if a Materialized View is finished building, without having to query each node

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-9967:
---

I just pushed an update to address Joel's comments and CI is rerunning now.

> Determine if a Materialized View is finished building, without having to 
> query each node
> 
>
> Key: CASSANDRA-9967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9967
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Alan Boudreault
>Assignee: Carl Yeksigian
>Priority: Minor
>  Labels: lhf
> Fix For: 3.x
>
>
> Since MVs are eventually consistent with its base table, It would nice if we 
> could easily know the state of the MV after its creation, so we could wait 
> until the MV is built before doing some operations.
> // cc [~mbroecheler] [~tjake] [~carlyeks] [~enigmacurry]



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

[jira] [Commented] (CASSANDRA-8844) Change Data Capture (CDC)

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-8844:
---

This change seems simple to me. We might want to be able to have the cdc 
overflow in a different directory, just so that they could put on a separate 
disk from our live commit logs, but having the cdc commit log files themselves 
in a separate directory makes sense.

> Change Data Capture (CDC)
> -
>
> Key: CASSANDRA-8844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8844
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Coordination, Local Write-Read Paths
>Reporter: Tupshin Harper
>Assignee: Joshua McKenzie
>Priority: Critical
> Fix For: 3.x
>
>
> "In databases, change data capture (CDC) is a set of software design patterns 
> used to determine (and track) the data that has changed so that action can be 
> taken using the changed data. Also, Change data capture (CDC) is an approach 
> to data integration that is based on the identification, capture and delivery 
> of the changes made to enterprise data sources."
> -Wikipedia
> As Cassandra is increasingly being used as the Source of Record (SoR) for 
> mission critical data in large enterprises, it is increasingly being called 
> upon to act as the central hub of traffic and data flow to other systems. In 
> order to try to address the general need, we (cc [~brianmhess]), propose 
> implementing a simple data logging mechanism to enable per-table CDC patterns.
> h2. The goals:
> # Use CQL as the primary ingestion mechanism, in order to leverage its 
> Consistency Level semantics, and in order to treat it as the single 
> reliable/durable SoR for the data.
> # To provide a mechanism for implementing good and reliable 
> (deliver-at-least-once with possible mechanisms for deliver-exactly-once ) 
> continuous semi-realtime feeds of mutations going into a Cassandra cluster.
> # To eliminate the developmental and operational burden of users so that they 
> don't have to do dual writes to other systems.
> # For users that are currently doing batch export from a Cassandra system, 
> give them the opportunity to make that realtime with a minimum of coding.
> h2. The mechanism:
> We propose a durable logging mechanism that functions similar to a commitlog, 
> with the following nuances:
> - Takes place on every node, not just the coordinator, so RF number of copies 
> are logged.
> - Separate log per table.
> - Per-table configuration. Only tables that are specified as CDC_LOG would do 
> any logging.
> - Per DC. We are trying to keep the complexity to a minimum to make this an 
> easy enhancement, but most likely use cases would prefer to only implement 
> CDC logging in one (or a subset) of the DCs that are being replicated to
> - In the critical path of ConsistencyLevel acknowledgment. Just as with the 
> commitlog, failure to write to the CDC log should fail that node's write. If 
> that means the requested consistency level was not met, then clients *should* 
> experience UnavailableExceptions.
> - Be written in a Row-centric manner such that it is easy for consumers to 
> reconstitute rows atomically.
> - Written in a simple format designed to be consumed *directly* by daemons 
> written in non JVM languages
> h2. Nice-to-haves
> I strongly suspect that the following features will be asked for, but I also 
> believe that they can be deferred for a subsequent release, and to guage 
> actual interest.
> - Multiple logs per table. This would make it easy to have multiple 
> "subscribers" to a single table's changes. A workaround would be to create a 
> forking daemon listener, but that's not a great answer.
> - Log filtering. Being able to apply filters, including UDF-based filters 
> would make Casandra a much more versatile feeder into other systems, and 
> again, reduce complexity that would otherwise need to be built into the 
> daemons.
> h2. Format and Consumption
> - Cassandra would only write to the CDC log, and never delete from it. 
> - Cleaning up consumed logfiles would be the client daemon's responibility
> - Logfile size should probably be configurable.
> - Logfiles should be named with a predictable naming schema, making it 
> triivial to process them in order.
> - Daemons should be able to checkpoint their work, and resume from where they 
> left off. This means they would have to leave some file artifact in the CDC 
> log's directory.
> - A sophisticated daemon should be able to be written that could 
> -- Catch up, in written-order, even when it is multiple logfiles behind in 
> processing
> -- Be able to continuously "tail" the most recent logfile and get 
> low-latency(ms?) access to the data as it is written.
> h2. Alternate approach
> In 

[jira] [Comment Edited] (CASSANDRA-9666) Provide an alternative to DTCS

[Jon Haddad (JIRA)]

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

Jon Haddad edited comment on CASSANDRA-9666 at 3/22/16 7:32 PM:


I talk to a lot of people using TWCS who have switched it to from DTCS due to 
it's operational simplicity.  +1 to including it.


was (Author: rustyrazorblade):
I talk to a lot of people using TWCS who have switched it to from DTCS due to 
it's operational simplicity.

> Provide an alternative to DTCS
> --
>
> Key: CASSANDRA-9666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9666
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 2.1.x, 2.2.x
>
> Attachments: dtcs-twcs-io.png, dtcs-twcs-load.png
>
>
> DTCS is great for time series data, but it comes with caveats that make it 
> difficult to use in production (typical operator behaviors such as bootstrap, 
> removenode, and repair have MAJOR caveats as they relate to 
> max_sstable_age_days, and hints/read repair break the selection algorithm).
> I'm proposing an alternative, TimeWindowCompactionStrategy, that sacrifices 
> the tiered nature of DTCS in order to address some of DTCS' operational 
> shortcomings. I believe it is necessary to propose an alternative rather than 
> simply adjusting DTCS, because it fundamentally removes the tiered nature in 
> order to remove the parameter max_sstable_age_days - the result is very very 
> different, even if it is heavily inspired by DTCS. 
> Specifically, rather than creating a number of windows of ever increasing 
> sizes, this strategy allows an operator to choose the window size, compact 
> with STCS within the first window of that size, and aggressive compact down 
> to a single sstable once that window is no longer current. The window size is 
> a combination of unit (minutes, hours, days) and size (1, etc), such that an 
> operator can expect all data using a block of that size to be compacted 
> together (that is, if your unit is hours, and size is 6, you will create 
> roughly 4 sstables per day, each one containing roughly 6 hours of data). 
> The result addresses a number of the problems with 
> DateTieredCompactionStrategy:
> - At the present time, DTCS’s first window is compacted using an unusual 
> selection criteria, which prefers files with earlier timestamps, but ignores 
> sizes. In TimeWindowCompactionStrategy, the first window data will be 
> compacted with the well tested, fast, reliable STCS. All STCS options can be 
> passed to TimeWindowCompactionStrategy to configure the first window’s 
> compaction behavior.
> - HintedHandoff may put old data in new sstables, but it will have little 
> impact other than slightly reduced efficiency (sstables will cover a wider 
> range, but the old timestamps will not impact sstable selection criteria 
> during compaction)
> - ReadRepair may put old data in new sstables, but it will have little impact 
> other than slightly reduced efficiency (sstables will cover a wider range, 
> but the old timestamps will not impact sstable selection criteria during 
> compaction)
> - Small, old sstables resulting from streams of any kind will be swiftly and 
> aggressively compacted with the other sstables matching their similar 
> maxTimestamp, without causing sstables in neighboring windows to grow in size.
> - The configuration options are explicit and straightforward - the tuning 
> parameters leave little room for error. The window is set in common, easily 
> understandable terms such as “12 hours”, “1 Day”, “30 days”. The 
> minute/hour/day options are granular enough for users keeping data for hours, 
> and users keeping data for years. 
> - There is no explicitly configurable max sstable age, though sstables will 
> naturally stop compacting once new data is written in that window. 
> - Streaming operations can create sstables with old timestamps, and they'll 
> naturally be joined together with sstables in the same time bucket. This is 
> true for bootstrap/repair/sstableloader/removenode. 
> - It remains true that if old data and new data is written into the memtable 
> at the same time, the resulting sstables will be treated as if they were new 
> sstables, however, that no longer negatively impacts the compaction 
> strategy’s selection criteria for older windows. 
> Patch provided for : 
> - 2.1: https://github.com/jeffjirsa/cassandra/commits/twcs-2.1 
> - 2.2: https://github.com/jeffjirsa/cassandra/commits/twcs-2.2
> - trunk (post-8099):  https://github.com/jeffjirsa/cassandra/commits/twcs 
> Rebased, force-pushed July 18, with bug fixes for estimated pending 
> compactions and potential starvation if more than min_threshold tables 
> existed in current window but STCS did not 

[jira] [Commented] (CASSANDRA-9666) Provide an alternative to DTCS

[Jon Haddad (JIRA)]

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

Jon Haddad commented on CASSANDRA-9666:
---

I talk to a lot of people using TWCS who have switched it to from DTCS due to 
it's operational simplicity.

> Provide an alternative to DTCS
> --
>
> Key: CASSANDRA-9666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9666
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 2.1.x, 2.2.x
>
> Attachments: dtcs-twcs-io.png, dtcs-twcs-load.png
>
>
> DTCS is great for time series data, but it comes with caveats that make it 
> difficult to use in production (typical operator behaviors such as bootstrap, 
> removenode, and repair have MAJOR caveats as they relate to 
> max_sstable_age_days, and hints/read repair break the selection algorithm).
> I'm proposing an alternative, TimeWindowCompactionStrategy, that sacrifices 
> the tiered nature of DTCS in order to address some of DTCS' operational 
> shortcomings. I believe it is necessary to propose an alternative rather than 
> simply adjusting DTCS, because it fundamentally removes the tiered nature in 
> order to remove the parameter max_sstable_age_days - the result is very very 
> different, even if it is heavily inspired by DTCS. 
> Specifically, rather than creating a number of windows of ever increasing 
> sizes, this strategy allows an operator to choose the window size, compact 
> with STCS within the first window of that size, and aggressive compact down 
> to a single sstable once that window is no longer current. The window size is 
> a combination of unit (minutes, hours, days) and size (1, etc), such that an 
> operator can expect all data using a block of that size to be compacted 
> together (that is, if your unit is hours, and size is 6, you will create 
> roughly 4 sstables per day, each one containing roughly 6 hours of data). 
> The result addresses a number of the problems with 
> DateTieredCompactionStrategy:
> - At the present time, DTCS’s first window is compacted using an unusual 
> selection criteria, which prefers files with earlier timestamps, but ignores 
> sizes. In TimeWindowCompactionStrategy, the first window data will be 
> compacted with the well tested, fast, reliable STCS. All STCS options can be 
> passed to TimeWindowCompactionStrategy to configure the first window’s 
> compaction behavior.
> - HintedHandoff may put old data in new sstables, but it will have little 
> impact other than slightly reduced efficiency (sstables will cover a wider 
> range, but the old timestamps will not impact sstable selection criteria 
> during compaction)
> - ReadRepair may put old data in new sstables, but it will have little impact 
> other than slightly reduced efficiency (sstables will cover a wider range, 
> but the old timestamps will not impact sstable selection criteria during 
> compaction)
> - Small, old sstables resulting from streams of any kind will be swiftly and 
> aggressively compacted with the other sstables matching their similar 
> maxTimestamp, without causing sstables in neighboring windows to grow in size.
> - The configuration options are explicit and straightforward - the tuning 
> parameters leave little room for error. The window is set in common, easily 
> understandable terms such as “12 hours”, “1 Day”, “30 days”. The 
> minute/hour/day options are granular enough for users keeping data for hours, 
> and users keeping data for years. 
> - There is no explicitly configurable max sstable age, though sstables will 
> naturally stop compacting once new data is written in that window. 
> - Streaming operations can create sstables with old timestamps, and they'll 
> naturally be joined together with sstables in the same time bucket. This is 
> true for bootstrap/repair/sstableloader/removenode. 
> - It remains true that if old data and new data is written into the memtable 
> at the same time, the resulting sstables will be treated as if they were new 
> sstables, however, that no longer negatively impacts the compaction 
> strategy’s selection criteria for older windows. 
> Patch provided for : 
> - 2.1: https://github.com/jeffjirsa/cassandra/commits/twcs-2.1 
> - 2.2: https://github.com/jeffjirsa/cassandra/commits/twcs-2.2
> - trunk (post-8099):  https://github.com/jeffjirsa/cassandra/commits/twcs 
> Rebased, force-pushed July 18, with bug fixes for estimated pending 
> compactions and potential starvation if more than min_threshold tables 
> existed in current window but STCS did not consider them viable candidates
> Rebased, force-pushed Aug 20 to bring in relevant logic from CASSANDRA-9882



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

[jira] [Commented] (CASSANDRA-9666) Provide an alternative to DTCS

[Brandon Williams (JIRA)]

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

Brandon Williams commented on CASSANDRA-9666:
-

It seems clear that there is some desire and use of TWCS in the community, so I 
am +1 on just adding it so those people don't have to bother with dropping jars 
in.

> Provide an alternative to DTCS
> --
>
> Key: CASSANDRA-9666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9666
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
> Fix For: 2.1.x, 2.2.x
>
> Attachments: dtcs-twcs-io.png, dtcs-twcs-load.png
>
>
> DTCS is great for time series data, but it comes with caveats that make it 
> difficult to use in production (typical operator behaviors such as bootstrap, 
> removenode, and repair have MAJOR caveats as they relate to 
> max_sstable_age_days, and hints/read repair break the selection algorithm).
> I'm proposing an alternative, TimeWindowCompactionStrategy, that sacrifices 
> the tiered nature of DTCS in order to address some of DTCS' operational 
> shortcomings. I believe it is necessary to propose an alternative rather than 
> simply adjusting DTCS, because it fundamentally removes the tiered nature in 
> order to remove the parameter max_sstable_age_days - the result is very very 
> different, even if it is heavily inspired by DTCS. 
> Specifically, rather than creating a number of windows of ever increasing 
> sizes, this strategy allows an operator to choose the window size, compact 
> with STCS within the first window of that size, and aggressive compact down 
> to a single sstable once that window is no longer current. The window size is 
> a combination of unit (minutes, hours, days) and size (1, etc), such that an 
> operator can expect all data using a block of that size to be compacted 
> together (that is, if your unit is hours, and size is 6, you will create 
> roughly 4 sstables per day, each one containing roughly 6 hours of data). 
> The result addresses a number of the problems with 
> DateTieredCompactionStrategy:
> - At the present time, DTCS’s first window is compacted using an unusual 
> selection criteria, which prefers files with earlier timestamps, but ignores 
> sizes. In TimeWindowCompactionStrategy, the first window data will be 
> compacted with the well tested, fast, reliable STCS. All STCS options can be 
> passed to TimeWindowCompactionStrategy to configure the first window’s 
> compaction behavior.
> - HintedHandoff may put old data in new sstables, but it will have little 
> impact other than slightly reduced efficiency (sstables will cover a wider 
> range, but the old timestamps will not impact sstable selection criteria 
> during compaction)
> - ReadRepair may put old data in new sstables, but it will have little impact 
> other than slightly reduced efficiency (sstables will cover a wider range, 
> but the old timestamps will not impact sstable selection criteria during 
> compaction)
> - Small, old sstables resulting from streams of any kind will be swiftly and 
> aggressively compacted with the other sstables matching their similar 
> maxTimestamp, without causing sstables in neighboring windows to grow in size.
> - The configuration options are explicit and straightforward - the tuning 
> parameters leave little room for error. The window is set in common, easily 
> understandable terms such as “12 hours”, “1 Day”, “30 days”. The 
> minute/hour/day options are granular enough for users keeping data for hours, 
> and users keeping data for years. 
> - There is no explicitly configurable max sstable age, though sstables will 
> naturally stop compacting once new data is written in that window. 
> - Streaming operations can create sstables with old timestamps, and they'll 
> naturally be joined together with sstables in the same time bucket. This is 
> true for bootstrap/repair/sstableloader/removenode. 
> - It remains true that if old data and new data is written into the memtable 
> at the same time, the resulting sstables will be treated as if they were new 
> sstables, however, that no longer negatively impacts the compaction 
> strategy’s selection criteria for older windows. 
> Patch provided for : 
> - 2.1: https://github.com/jeffjirsa/cassandra/commits/twcs-2.1 
> - 2.2: https://github.com/jeffjirsa/cassandra/commits/twcs-2.2
> - trunk (post-8099):  https://github.com/jeffjirsa/cassandra/commits/twcs 
> Rebased, force-pushed July 18, with bug fixes for estimated pending 
> compactions and potential starvation if more than min_threshold tables 
> existed in current window but STCS did not consider them viable candidates
> Rebased, force-pushed Aug 20 to bring in relevant logic from CASSANDRA-9882



--
This message was sent by 

[jira] [Commented] (CASSANDRA-11401) [Regression] Incorrect results for clustering tuples query

[DOAN DuyHai (JIRA)]

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

DOAN DuyHai commented on CASSANDRA-11401:
-

Didn't know about this new stance on logical ordering vs physical layout. In 
this case, this JIRA can be closed, Not A Problem according to [CASSANDRA-7281]

> [Regression] Incorrect results for clustering tuples query
> --
>
> Key: CASSANDRA-11401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11401
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: *Cassandra 3.4*
>Reporter: DOAN DuyHai
>Priority: Critical
>
> There is a regression since *Cassandra 3.4* with query using clustering tuple 
> values:
> {noformat}
> cqlsh:test> CREATE TABLE IF NOT EXISTS entity_with_clusterings(
>   id bigint,
>   uuid uuid,
>   date timestamp,
>   value text,
>   PRIMARY KEY(id, uuid, date))
> WITH CLUSTERING ORDER BY(uuid ASC, date DESC);
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-01 
> 00:00:00+', 'val1');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-02 
> 00:00:00+', 'val2');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-03 
> 00:00:00+', 'val3');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----0001, '2015-10-04 
> 00:00:00+', 'val4');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----0001, '2015-10-05 
> 00:00:00+', 'val5');
> cqlsh:test> SELECT * FROM entity_with_clusterings;
>  id  | uuid | date
>  | value
> -+--+--+---
>  3233835834146573312 | ---- | 2015-10-03 
> 00:00:00+ |  val3
>  3233835834146573312 | ---- | 2015-10-02 
> 00:00:00+ |  val2
>  3233835834146573312 | ---- | 2015-10-01 
> 00:00:00+ |  val1
>  3233835834146573312 | ----0001 | 2015-10-05 
> 00:00:00+ |  val5
>  3233835834146573312 | ----0001 | 2015-10-04 
> 00:00:00+ |  val4
> (5 rows)
> cqlsh:test > SELECT uuid,date,value 
> FROM entity_with_clusterings 
> WHERE id=3233835834146573312 
> AND (uuid,date)>=(----,'2015-10-02 
> 00:00:00+') 
> AND (uuid,date)<(----0001, '2015-10-04 
> 00:00:00+');
>  uuid | date| 
> value
> --+-+---
>  ---- | 2015-10-03 00:00:00.00+ |  
> val3
>  ---- | 2015-10-02 00:00:00.00+ |  
> val2
> {noformat}
> The same query with *Cassandra 3.3* returns correct answer:
> {noformat}
> cqlsh:test> SELECT uuid,date,value
> FROM entity_with_clusterings
> WHERE id=3233835834146573312
> AND (uuid,date)>=(----,'2015-10-02 
> 00:00:00+')
> AND (uuid,date)<(----0001, '2015-10-04 
> 00:00:00+');
>  uuid | date | value
> --+--+---
>  ---- | 2015-10-02 00:00:00+ |  val2
>  ---- | 2015-10-01 00:00:00+ |  val1
>  ----0001 | 2015-10-05 00:00:00+ |  val5
> {noformat}



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

[jira] [Resolved] (CASSANDRA-11398) Missing results when merging from SASI index sources

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe resolved CASSANDRA-11398.
-
   Resolution: Not A Problem
Fix Version/s: (was: 3.x)

This was down to an bug in my CASSANDRA-11397 patch, with the updated version 
it's not a problem.

> Missing results when merging from SASI index sources
> 
>
> Key: CASSANDRA-11398
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11398
> Project: Cassandra
>  Issue Type: Bug
>  Components: sasi
>Reporter: Sam Tunnicliffe
>
> There seems to be a problem in {{QueryPlan.ResultIterator}} or 
> {{RangeIterator}} when merging results from mulitple index locations. I've 
> only repro'd using a prefix index on a clustering column, but in that case it 
> seems to manifest whenever the search results are drawn from > 1 index, 
> either multiple sstable indexes or a combination of memtable and sstable 
> indexes). 
> Note, the following repro case is masked by CASSANDRA-11397, so the patch 
> attached to that issue needs to be applied to expose this.
> {code}
> cqlsh> create table ks.t1 (k text, c1 text, c2 text, c3 text, v text, primary 
> key (k,c1,c2,c3));
> cqlsh> create custom index on ks.t1(c2) using 
> 'org.apache.cassandra.index.sasi.SASIIndex';
> cqlsh> insert into ks.t1(k, c1, c2, c3, v) values ('a', 'ba', 'ca', 'da', 
> 'va');
> cqlsh> select * from ks.t1 where c1 = 'ba' and c2 like 'c%' and c3 = 'da' 
> allow filtering;
>  k | c1 | c2 | c3 | v
> ---++++
>  a | ba | ca | da | va
> (1 rows)
> # flush 
> cqlsh> insert into ks.t1(k, c1, c2, c3, v) values ('a', 'ba', 'ca', 'db', 
> 'va');
> cqlsh> select * from ks.t1 where c1 = 'ba' and c2 like 'c%' and c3 = 'da' 
> allow filtering;
>  k | c1 | c2 | c3 | v
> ---++++---
> (0 rows)
> # flush again 
> cqlsh> select * from ks.t1 where c1 = 'ba' and c2 like 'c%' and c3 = 'da' 
> allow filtering;
>  k | c1 | c2 | c3 | v
> ---++++---
> (0 rows)
> # compact
> cqlsh> select * from ks.t1 where c1 = 'ba' and c2 like 'c%' and c3 = 'da' 
> allow filtering;
>  k | c1 | c2 | c3 | v
> ---++++
>  a | ba | ca | da | va
> (1 rows)
> {code}



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

[jira] [Updated] (CASSANDRA-11397) LIKE query on clustering column index returns incorrect results

[Jordan West (JIRA)]

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

Jordan West updated CASSANDRA-11397:

Reviewer: Jordan West  (was: Pavel Yaskevich)

> LIKE query on clustering column index returns incorrect results
> ---
>
> Key: CASSANDRA-11397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11397
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>  Labels: sasi
> Fix For: 3.5
>
>
> The way that {{ClusteringIndexFilter}} and {{RowFilter}} are constructed when 
> a {{LIKE}} restriction on a clustering column is present is incorrect. For 
> example:
> {code}
> cqlsh> create table ks.t1 (k text, c1 text, c2 text, c3 text, v text, primary 
> key (k,c1,c2,c3));
> cqlsh> create custom index on ks.t1(c2) using 
> 'org.apache.cassandra.index.sasi.SASIIndex';
> cqlsh> select * from ks.t1;
>  k | c1 | c2 | c3 | v
> ---++++-
>  a | ba | ca | da | val
>  a | bb | cb | db | val
>  a | bc | cc | dc | val
> (3 rows)
>  
> cqlsh> select * from ks.t1 where c1 = 'ba' and c3 = 'da' and c2 LIKE 'c%' 
> ALLOW FILTERING;
>  k | c1 | c2 | c3 | v
> ---++++---
> (0 rows)
> {code}



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

[jira] [Commented] (CASSANDRA-11401) [Regression] Incorrect results for clustering tuples query

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-11401:
-

bq.  My problem here is that if you say that Cassandra 3.4 is returning the 
correct result, then it is not consistent with what is displayed by SELECT * 
... 

You're still thinking in terms of how things are stored on disk, not the 
logical ordering.  With the mixed ASC/DESC clustering order, you've explicitly 
specified that the rows should be stored in a non-logical order on disk.

What CASSANDRA-7281 did was to break the old restriction of requiring a single 
contiguous slice in order to return logically correct results.  When you do 
{{SELECT * WHERE (uuid, date) >= (00000, 2015-10-02 00:00:00+)}}, 
you're asking Cassandra to return rows where {{(uuid, date)}} is logically >= 
{{(00000, 2015-10-02 00:00:00+)}}.  You are _not_ asking Cassandra to 
return rows that are stored on disk after {{(00000, 2015-10-02 
00:00:00+)}}, regardless of how they logically compare -- we don't even 
have a way to express that request in CQL.

> [Regression] Incorrect results for clustering tuples query
> --
>
> Key: CASSANDRA-11401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11401
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: *Cassandra 3.4*
>Reporter: DOAN DuyHai
>Priority: Critical
>
> There is a regression since *Cassandra 3.4* with query using clustering tuple 
> values:
> {noformat}
> cqlsh:test> CREATE TABLE IF NOT EXISTS entity_with_clusterings(
>   id bigint,
>   uuid uuid,
>   date timestamp,
>   value text,
>   PRIMARY KEY(id, uuid, date))
> WITH CLUSTERING ORDER BY(uuid ASC, date DESC);
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-01 
> 00:00:00+', 'val1');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-02 
> 00:00:00+', 'val2');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-03 
> 00:00:00+', 'val3');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----0001, '2015-10-04 
> 00:00:00+', 'val4');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----0001, '2015-10-05 
> 00:00:00+', 'val5');
> cqlsh:test> SELECT * FROM entity_with_clusterings;
>  id  | uuid | date
>  | value
> -+--+--+---
>  3233835834146573312 | ---- | 2015-10-03 
> 00:00:00+ |  val3
>  3233835834146573312 | ---- | 2015-10-02 
> 00:00:00+ |  val2
>  3233835834146573312 | ---- | 2015-10-01 
> 00:00:00+ |  val1
>  3233835834146573312 | ----0001 | 2015-10-05 
> 00:00:00+ |  val5
>  3233835834146573312 | ----0001 | 2015-10-04 
> 00:00:00+ |  val4
> (5 rows)
> cqlsh:test > SELECT uuid,date,value 
> FROM entity_with_clusterings 
> WHERE id=3233835834146573312 
> AND (uuid,date)>=(----,'2015-10-02 
> 00:00:00+') 
> AND (uuid,date)<(----0001, '2015-10-04 
> 00:00:00+');
>  uuid | date| 
> value
> --+-+---
>  ---- | 2015-10-03 00:00:00.00+ |  
> val3
>  ---- | 2015-10-02 00:00:00.00+ |  
> val2
> {noformat}
> The same query with *Cassandra 3.3* returns correct answer:
> {noformat}
> cqlsh:test> SELECT uuid,date,value
> FROM entity_with_clusterings
> WHERE id=3233835834146573312
> AND (uuid,date)>=(----,'2015-10-02 
> 00:00:00+')
> AND (uuid,date)<(----0001, '2015-10-04 
> 00:00:00+');
>  uuid | date | value
> --+--+---
>  ---- | 2015-10-02 00:00:00+ |  val2
>  ---- | 2015-10-01 00:00:00+ |  val1
>  

[jira] [Commented] (CASSANDRA-11397) LIKE query on clustering column index returns incorrect results

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-11397:
-

Stupidly I'd made the queries produce invalid {{ClusteringIndexNamesFilter}} 
instead of {{ClusteringIndexSliceFilter}}. Fixed and pushed, CI is running now.

> LIKE query on clustering column index returns incorrect results
> ---
>
> Key: CASSANDRA-11397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11397
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>  Labels: sasi
> Fix For: 3.5
>
>
> The way that {{ClusteringIndexFilter}} and {{RowFilter}} are constructed when 
> a {{LIKE}} restriction on a clustering column is present is incorrect. For 
> example:
> {code}
> cqlsh> create table ks.t1 (k text, c1 text, c2 text, c3 text, v text, primary 
> key (k,c1,c2,c3));
> cqlsh> create custom index on ks.t1(c2) using 
> 'org.apache.cassandra.index.sasi.SASIIndex';
> cqlsh> select * from ks.t1;
>  k | c1 | c2 | c3 | v
> ---++++-
>  a | ba | ca | da | val
>  a | bb | cb | db | val
>  a | bc | cc | dc | val
> (3 rows)
>  
> cqlsh> select * from ks.t1 where c1 = 'ba' and c3 = 'da' and c2 LIKE 'c%' 
> ALLOW FILTERING;
>  k | c1 | c2 | c3 | v
> ---++++---
> (0 rows)
> {code}



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

[jira] [Comment Edited] (CASSANDRA-11401) [Regression] Incorrect results for clustering tuples query

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs edited comment on CASSANDRA-11401 at 3/22/16 6:30 PM:
--

This is related to CASSANDRA-7281.  The 3.4 behavior is actually the correct 
behavior, logically.  If you ignore the order that Cassandra stores the rows on 
disk, you can see that logically speaking, 3.3 returns incorrect results.  For 
example, {{(----, '2015-10-01 00:00:00+')}} 
is returned, despite being less than your minimum bound of 
{{(----, '2015-10-02 00:00:00+')}}.  The 
fix in CASSANDRA-7281 changed the behavior from always executing a single 
contiguous slice (even if it would return incorrect results) to performing 
multiple slices if necessary in order to return the correct logical results.

EDIT: I meant CASSANDRA-7281, not CASSANDRA-7821


was (Author: thobbs):
This is related to CASSANDRA-7821.  The 3.4 behavior is actually the correct 
behavior, logically.  If you ignore the order that Cassandra stores the rows on 
disk, you can see that logically speaking, 3.3 returns incorrect results.  For 
example, {{(----, '2015-10-01 00:00:00+')}} 
is returned, despite being less than your minimum bound of 
{{(----, '2015-10-02 00:00:00+')}}.  The 
fix in CASSANDRA-7821 changed the behavior from always executing a single 
contiguous slice (even if it would return incorrect results) to performing 
multiple slices if necessary in order to return the correct logical results.

> [Regression] Incorrect results for clustering tuples query
> --
>
> Key: CASSANDRA-11401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11401
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: *Cassandra 3.4*
>Reporter: DOAN DuyHai
>Priority: Critical
>
> There is a regression since *Cassandra 3.4* with query using clustering tuple 
> values:
> {noformat}
> cqlsh:test> CREATE TABLE IF NOT EXISTS entity_with_clusterings(
>   id bigint,
>   uuid uuid,
>   date timestamp,
>   value text,
>   PRIMARY KEY(id, uuid, date))
> WITH CLUSTERING ORDER BY(uuid ASC, date DESC);
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-01 
> 00:00:00+', 'val1');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-02 
> 00:00:00+', 'val2');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-03 
> 00:00:00+', 'val3');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----0001, '2015-10-04 
> 00:00:00+', 'val4');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----0001, '2015-10-05 
> 00:00:00+', 'val5');
> cqlsh:test> SELECT * FROM entity_with_clusterings;
>  id  | uuid | date
>  | value
> -+--+--+---
>  3233835834146573312 | ---- | 2015-10-03 
> 00:00:00+ |  val3
>  3233835834146573312 | ---- | 2015-10-02 
> 00:00:00+ |  val2
>  3233835834146573312 | ---- | 2015-10-01 
> 00:00:00+ |  val1
>  3233835834146573312 | ----0001 | 2015-10-05 
> 00:00:00+ |  val5
>  3233835834146573312 | ----0001 | 2015-10-04 
> 00:00:00+ |  val4
> (5 rows)
> cqlsh:test > SELECT uuid,date,value 
> FROM entity_with_clusterings 
> WHERE id=3233835834146573312 
> AND (uuid,date)>=(----,'2015-10-02 
> 00:00:00+') 
> AND (uuid,date)<(----0001, '2015-10-04 
> 00:00:00+');
>  uuid | date| 
> value
> --+-+---
>  ---- | 2015-10-03 00:00:00.00+ |  
> val3
>  ---- | 2015-10-02 00:00:00.00+ |  
> val2
> {noformat}
> The same query with *Cassandra 3.3* returns correct answer:
> {noformat}
> cqlsh:test> SELECT uuid,date,value
> FROM 

[jira] [Updated] (CASSANDRA-11404) Document metrics mbeans org.apache.cassandra.metrics

[Michael Schurter (JIRA)]

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

Michael Schurter updated CASSANDRA-11404:
-
Description: 
Was bemoaning the lack of documentation for Cassandra's extensive metrics in 
IRC and [~thobbs] told me to file a ticket: 

I started stealing comments from 
{{src/java/org/apache/cassandra/metrics/TableMetrics.java}}:

||mbean||description||
| {{ColumnFamily.$keyspace.$table.MemtableOnHeapSize}} | Total amount of data 
stored in the memtable that resides on-heap, including column related overhead 
and partitions overwritten.
|
| {{ColumnFamily.$keyspace.$table.MemtableOffHeapSize}} | Total amount of data 
stored in the memtable that resides off-heap, including column related overhead 
and partitions overwritten. |
| {{ColumnFamily.$keyspace.$table.CompressionRatio}} | Current compression 
ratio for all SSTables |
| {{ColumnFamily.$keyspace.$table.Estimated{Partition,Row}SizeHistogram}} | 
Histogram of estimated partition size (in bytes). |
| {{ColumnFamily.$keyspace.$table.ReadLatency}} | Local read metrics. |
| {{ColumnFamily.$keyspace.$table.WriteLatency}} | Local Write metrics. |
| {{ColumnFamily.$keyspace.$table.MemstableLiveDataSize}} | Total amount of 
live data stored in the memtable, excluding any data structure overhead. |
| {{ColumnFamily.$keyspace.$table.CoordinatorReadLatency}} | Read request 
latency from the perspective of the coordinating node |
| {{ColumnFamily.$keyspace.$table.CoordinatorScanLatency}} | ??? |

  was:
Was bemoaning the lack of documentation for Cassandra's extensive metrics in 
IRC and [~thobbs] told me to file a ticket: 

I started stealing comments from 
{{src/java/org/apache/cassandra/metrics/TableMetrics.java}}:

||mbean||description||
| {{ColumnFamily.$keyspace.$table.MemtableOnHeapSize}} | Total amount of data 
stored in the memtable that resides on-heap, including column related overhead 
and partitions overwritten.
|
| {{ColumnFamily.$keyspace.$table.MemtableOffHeapSize}} | Total amount of data 
stored in the memtable that resides off-heap, including column related overhead 
and partitions overwritten. |
| {{ColumnFamily.$keyspace.$table.CompressionRatio}} | Current compression 
ratio for all SSTables |
| {{ColumnFamily.$keyspace.$table.Estimated{Partition,Row}SizeHistogram}} | 
Histogram of estimated partition size (in bytes). |
| {{ColumnFamily.$keyspace.$table.ReadLatency}} | Local read metrics. |
| {{ColumnFamily.$keyspace.$table.WriteLatency}} | Local Write metrics. |

| {{ColumnFamily.$keyspace.$table.MemstableLiveDataSize}} | Total amount of 
live data stored in the memtable, excluding any data structure overhead. |
| {{ColumnFamily.$keyspace.$table.CoordinatorReadLatency}} | Read request 
latency from the perspective of the coordinating node |
| {{ColumnFamily.$keyspace.$table.CoordinatorScanLatency}} | ??? |


> Document metrics mbeans org.apache.cassandra.metrics
> 
>
> Key: CASSANDRA-11404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11404
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation and Website
>Reporter: Michael Schurter
>
> Was bemoaning the lack of documentation for Cassandra's extensive metrics in 
> IRC and [~thobbs] told me to file a ticket: 
> I started stealing comments from 
> {{src/java/org/apache/cassandra/metrics/TableMetrics.java}}:
> ||mbean||description||
> | {{ColumnFamily.$keyspace.$table.MemtableOnHeapSize}} | Total amount of data 
> stored in the memtable that resides on-heap, including column related 
> overhead and partitions overwritten.
> |
> | {{ColumnFamily.$keyspace.$table.MemtableOffHeapSize}} | Total amount of 
> data stored in the memtable that resides off-heap, including column related 
> overhead and partitions overwritten. |
> | {{ColumnFamily.$keyspace.$table.CompressionRatio}} | Current compression 
> ratio for all SSTables |
> | {{ColumnFamily.$keyspace.$table.Estimated{Partition,Row}SizeHistogram}} | 
> Histogram of estimated partition size (in bytes). |
> | {{ColumnFamily.$keyspace.$table.ReadLatency}} | Local read metrics. |
> | {{ColumnFamily.$keyspace.$table.WriteLatency}} | Local Write metrics. |
> | {{ColumnFamily.$keyspace.$table.MemstableLiveDataSize}} | Total amount of 
> live data stored in the memtable, excluding any data structure overhead. |
> | {{ColumnFamily.$keyspace.$table.CoordinatorReadLatency}} | Read request 
> latency from the perspective of the coordinating node |
> | {{ColumnFamily.$keyspace.$table.CoordinatorScanLatency}} | ??? |



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

[jira] [Commented] (CASSANDRA-11290) dtest failure in materialized_views_test.TestMaterializedViewsConsistency.single_partition_consistent_reads_after_write_test

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-11290:


This looks like a real bug, but I'm not sure what is causing this. We don't 
allow a null lock in the {{locks}} array, instead following a path that 
includes rescheduling, so it doesn't seem like we should get to the end and 
have a null. The only other thing would be if the {{columnFamilyIds}} changed 
during execution, so that {{size()}} was different, but other threads don't 
have access to it, and we should also get a {{ConcurrentModificationException}}.

> dtest failure in 
> materialized_views_test.TestMaterializedViewsConsistency.single_partition_consistent_reads_after_write_test
> 
>
> Key: CASSANDRA-11290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11290
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Russ Hatch
>Assignee: Carl Yeksigian
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/26/testReport/materialized_views_test/TestMaterializedViewsConsistency/single_partition_consistent_reads_after_write_test
> Failed on CassCI build trunk_offheap_dtest #26
> Failing infrequently but same error on at least two of those infrequent flaps:
> {noformat}
> Connection to 127.0.0.2 was closed
> {noformat}



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

[jira] [Assigned] (CASSANDRA-11290) dtest failure in materialized_views_test.TestMaterializedViewsConsistency.single_partition_consistent_reads_after_write_test

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian reassigned CASSANDRA-11290:
--

Assignee: Carl Yeksigian

> dtest failure in 
> materialized_views_test.TestMaterializedViewsConsistency.single_partition_consistent_reads_after_write_test
> 
>
> Key: CASSANDRA-11290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11290
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Russ Hatch
>Assignee: Carl Yeksigian
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/26/testReport/materialized_views_test/TestMaterializedViewsConsistency/single_partition_consistent_reads_after_write_test
> Failed on CassCI build trunk_offheap_dtest #26
> Failing infrequently but same error on at least two of those infrequent flaps:
> {noformat}
> Connection to 127.0.0.2 was closed
> {noformat}



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

[jira] [Created] (CASSANDRA-11404) Document metrics mbeans org.apache.cassandra.metrics

[Michael Schurter (JIRA)]

Michael Schurter created CASSANDRA-11404:


 Summary: Document metrics mbeans org.apache.cassandra.metrics
 Key: CASSANDRA-11404
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11404
 Project: Cassandra
  Issue Type: Improvement
  Components: Documentation and Website
Reporter: Michael Schurter


Was bemoaning the lack of documentation for Cassandra's extensive metrics in 
IRC and [~thobbs] told me to file a ticket: 

I started stealing comments from 
{{src/java/org/apache/cassandra/metrics/TableMetrics.java}}:

||mbean||description||
| {{ColumnFamily.$keyspace.$table.MemtableOnHeapSize}} | Total amount of data 
stored in the memtable that resides on-heap, including column related overhead 
and partitions overwritten.
|
| {{ColumnFamily.$keyspace.$table.MemtableOffHeapSize}} | Total amount of data 
stored in the memtable that resides off-heap, including column related overhead 
and partitions overwritten. |
| {{ColumnFamily.$keyspace.$table.CompressionRatio}} | Current compression 
ratio for all SSTables |
| {{ColumnFamily.$keyspace.$table.Estimated{Partition,Row}SizeHistogram}} | 
Histogram of estimated partition size (in bytes). |
| {{ColumnFamily.$keyspace.$table.ReadLatency}} | Local read metrics. |
| {{ColumnFamily.$keyspace.$table.WriteLatency}} | Local Write metrics. |

| {{ColumnFamily.$keyspace.$table.MemstableLiveDataSize}} | Total amount of 
live data stored in the memtable, excluding any data structure overhead. |
| {{ColumnFamily.$keyspace.$table.CoordinatorReadLatency}} | Read request 
latency from the perspective of the coordinating node |
| {{ColumnFamily.$keyspace.$table.CoordinatorScanLatency}} | ??? |



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

[jira] [Commented] (CASSANDRA-11401) [Regression] Incorrect results for clustering tuples query

[DOAN DuyHai (JIRA)]

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

DOAN DuyHai commented on CASSANDRA-11401:
-

bq. If you ignore the order that Cassandra stores the rows on disk, you can see 
that logically speaking, 3.3 returns incorrect results

 The problem is that I have designed the table with DESC clustering order for 
the {{date}} column. Also the {{SELECT * FROM entity_with_clusterings;}} is 
showing the result as Cassandra stores data on disk, which is consistent with 
the defined clustering order:

{noformat}
 id  | uuid | date  
   | value
-+--+--+---
 3233835834146573312 | ---- | 2015-10-03 
00:00:00+ |  val3
 3233835834146573312 | ---- | 2015-10-02 
00:00:00+ |  val2
 3233835834146573312 | ---- | 2015-10-01 
00:00:00+ |  val1
 3233835834146573312 | ----0001 | 2015-10-05 
00:00:00+ |  val5
 3233835834146573312 | ----0001 | 2015-10-04 
00:00:00+ |  val4
{noformat}

 So if the SELECT returns the above result, logically, all clustering tuples 
(uuid, date) >= {{(00000, 2015-10-02 00:00:00+)}} should be {{val2}}, 
{{val1}}, {{val5}} and {{val4}} and exactly in this order ...

 The trick is that the ordering is done on the couple {{(uuid,date)}} and 
neither {{uuid}} nor {{date}} alone ...

 My problem here is that if you say that *Cassandra 3.4* is returning the 
correct result, then it is not consistent with what is displayed by {{SELECT * 
...}} 

 

> [Regression] Incorrect results for clustering tuples query
> --
>
> Key: CASSANDRA-11401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11401
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: *Cassandra 3.4*
>Reporter: DOAN DuyHai
>Priority: Critical
>
> There is a regression since *Cassandra 3.4* with query using clustering tuple 
> values:
> {noformat}
> cqlsh:test> CREATE TABLE IF NOT EXISTS entity_with_clusterings(
>   id bigint,
>   uuid uuid,
>   date timestamp,
>   value text,
>   PRIMARY KEY(id, uuid, date))
> WITH CLUSTERING ORDER BY(uuid ASC, date DESC);
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-01 
> 00:00:00+', 'val1');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-02 
> 00:00:00+', 'val2');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-03 
> 00:00:00+', 'val3');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----0001, '2015-10-04 
> 00:00:00+', 'val4');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----0001, '2015-10-05 
> 00:00:00+', 'val5');
> cqlsh:test> SELECT * FROM entity_with_clusterings;
>  id  | uuid | date
>  | value
> -+--+--+---
>  3233835834146573312 | ---- | 2015-10-03 
> 00:00:00+ |  val3
>  3233835834146573312 | ---- | 2015-10-02 
> 00:00:00+ |  val2
>  3233835834146573312 | ---- | 2015-10-01 
> 00:00:00+ |  val1
>  3233835834146573312 | ----0001 | 2015-10-05 
> 00:00:00+ |  val5
>  3233835834146573312 | ----0001 | 2015-10-04 
> 00:00:00+ |  val4
> (5 rows)
> cqlsh:test > SELECT uuid,date,value 
> FROM entity_with_clusterings 
> WHERE id=3233835834146573312 
> AND (uuid,date)>=(----,'2015-10-02 
> 00:00:00+') 
> AND (uuid,date)<(----0001, '2015-10-04 
> 00:00:00+');
>  uuid | date| 
> value
> --+-+---
>  ---- | 2015-10-03 00:00:00.00+ |  
> val3
>  ---- | 2015-10-02 00:00:00.00+ |  
> val2
> {noformat}
> The same query with *Cassandra 

[jira] [Comment Edited] (CASSANDRA-8844) Change Data Capture (CDC)

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie edited comment on CASSANDRA-8844 at 3/22/16 5:32 PM:
-

Something that came up during impl that got me thinking: we currently rely on 
all segments for a {{CommitLogSegmentManager}} to be located in the same 
directory. Easy enough design, reliable, rely on OS for separation etc. Good 
enough for our use-case thus far.

Adding a 2nd CommitLogSegmentManager muddies that water as we'd have some 
segments allocated by 1 allocator, some by another. Rather than go the route of 
sharing a directory for both CommitLogSegmentManagers and flagging type / 
ownership / responsibility by file name regex / filter, I'm leaning towards 
having cdc commit log segments exist in a subdirectory under commitlog, so:

{noformat}
data/commitlog
data/commitlog/cdc
{noformat}

This leads to the next observation that there's little point in having a 
cdc_overflow folder with this design as we can simply fail allocation when our 
/cdc folder reaches our configured size threshold. It's a little dicier on the 
"consumer deletes segments" front as there's no longer the differentiator of 
"any segment in this folder, we're done with it", however it's trivial to write 
the names of completed segment files to a local metadata file to indicate to 
consumers when we're done with segments.

The only other thing I can think of that's a downside: this will be a change 
for any other external tools / code that's relying on all segments to be stored 
in a single directory, hence my update here. Can anyone think of a really good 
reason why storing commit log segments in 2 separate directories for 2 separate 
managers would be a Bad Thing?

Edit: Just to clarify one thing: having flushed-to-sstable cdc files in the 
commitlog/cdc folder vs. in a cdc_overflow folder is a trivial delta w/some 
bookkeeping differences. Not a big deal nor what I was trying to get at above, 
so I'll probably end up moving those into cdc_overflow anyway just for 
separation.


was (Author: joshuamckenzie):
Something that came up during impl that got me thinking: we currently rely on 
all segments for a {{CommitLogSegmentManager}} to be located in the same 
directory. Easy enough design, reliable, rely on OS for separation etc. Good 
enough for our use-case thus far.

Adding a 2nd CommitLogSegmentManager muddies that water as we'd have some 
segments allocated by 1 allocator, some by another. Rather than go the route of 
sharing a directory for both CommitLogSegmentManagers and flagging type / 
ownership / responsibility by file name regex / filter, I'm leaning towards 
having cdc commit log segments exist in a subdirectory under commitlog, so:

{noformat}
data/commitlog
data/commitlog/cdc
{noformat}

This leads to the next observation that there's little point in having a 
cdc_overflow folder with this design as we can simply fail allocation when our 
/cdc folder reaches our configured size threshold. It's a little dicier on the 
"consumer deletes segments" front as there's no longer the differentiator of 
"any segment in this folder, we're done with it", however it's trivial to write 
the names of completed segment files to a local metadata file to indicate to 
consumers when we're done with segments.

The only other thing I can think of that's a downside: this will be a change 
for any other external tools / code that's relying on all segments to be stored 
in a single directory, hence my update here. Can anyone think of a really good 
reason why storing commit log segments in 2 separate directories for 2 separate 
managers would be a Bad Thing?

> Change Data Capture (CDC)
> -
>
> Key: CASSANDRA-8844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8844
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Coordination, Local Write-Read Paths
>Reporter: Tupshin Harper
>Assignee: Joshua McKenzie
>Priority: Critical
> Fix For: 3.x
>
>
> "In databases, change data capture (CDC) is a set of software design patterns 
> used to determine (and track) the data that has changed so that action can be 
> taken using the changed data. Also, Change data capture (CDC) is an approach 
> to data integration that is based on the identification, capture and delivery 
> of the changes made to enterprise data sources."
> -Wikipedia
> As Cassandra is increasingly being used as the Source of Record (SoR) for 
> mission critical data in large enterprises, it is increasingly being called 
> upon to act as the central hub of traffic and data flow to other systems. In 
> order to try to address the general need, we (cc [~brianmhess]), propose 
> implementing a simple data logging mechanism to enable 

[jira] [Commented] (CASSANDRA-8844) Change Data Capture (CDC)

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie commented on CASSANDRA-8844:


Something that came up during impl that got me thinking: we currently rely on 
all segments for a {{CommitLogSegmentManager}} to be located in the same 
directory. Easy enough design, reliable, rely on OS for separation etc. Good 
enough for our use-case thus far.

Adding a 2nd CommitLogSegmentManager muddies that water as we'd have some 
segments allocated by 1 allocator, some by another. Rather than go the route of 
sharing a directory for both CommitLogSegmentManagers and flagging type / 
ownership / responsibility by file name regex / filter, I'm leaning towards 
having cdc commit log segments exist in a subdirectory under commitlog, so:

{noformat}
data/commitlog
data/commitlog/cdc
{noformat}

This leads to the next observation that there's little point in having a 
cdc_overflow folder with this design as we can simply fail allocation when our 
/cdc folder reaches our configured size threshold. It's a little dicier on the 
"consumer deletes segments" front as there's no longer the differentiator of 
"any segment in this folder, we're done with it", however it's trivial to write 
the names of completed segment files to a local metadata file to indicate to 
consumers when we're done with segments.

The only other thing I can think of that's a downside: this will be a change 
for any other external tools / code that's relying on all segments to be stored 
in a single directory, hence my update here. Can anyone think of a really good 
reason why storing commit log segments in 2 separate directories for 2 separate 
managers would be a Bad Thing?

> Change Data Capture (CDC)
> -
>
> Key: CASSANDRA-8844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8844
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Coordination, Local Write-Read Paths
>Reporter: Tupshin Harper
>Assignee: Joshua McKenzie
>Priority: Critical
> Fix For: 3.x
>
>
> "In databases, change data capture (CDC) is a set of software design patterns 
> used to determine (and track) the data that has changed so that action can be 
> taken using the changed data. Also, Change data capture (CDC) is an approach 
> to data integration that is based on the identification, capture and delivery 
> of the changes made to enterprise data sources."
> -Wikipedia
> As Cassandra is increasingly being used as the Source of Record (SoR) for 
> mission critical data in large enterprises, it is increasingly being called 
> upon to act as the central hub of traffic and data flow to other systems. In 
> order to try to address the general need, we (cc [~brianmhess]), propose 
> implementing a simple data logging mechanism to enable per-table CDC patterns.
> h2. The goals:
> # Use CQL as the primary ingestion mechanism, in order to leverage its 
> Consistency Level semantics, and in order to treat it as the single 
> reliable/durable SoR for the data.
> # To provide a mechanism for implementing good and reliable 
> (deliver-at-least-once with possible mechanisms for deliver-exactly-once ) 
> continuous semi-realtime feeds of mutations going into a Cassandra cluster.
> # To eliminate the developmental and operational burden of users so that they 
> don't have to do dual writes to other systems.
> # For users that are currently doing batch export from a Cassandra system, 
> give them the opportunity to make that realtime with a minimum of coding.
> h2. The mechanism:
> We propose a durable logging mechanism that functions similar to a commitlog, 
> with the following nuances:
> - Takes place on every node, not just the coordinator, so RF number of copies 
> are logged.
> - Separate log per table.
> - Per-table configuration. Only tables that are specified as CDC_LOG would do 
> any logging.
> - Per DC. We are trying to keep the complexity to a minimum to make this an 
> easy enhancement, but most likely use cases would prefer to only implement 
> CDC logging in one (or a subset) of the DCs that are being replicated to
> - In the critical path of ConsistencyLevel acknowledgment. Just as with the 
> commitlog, failure to write to the CDC log should fail that node's write. If 
> that means the requested consistency level was not met, then clients *should* 
> experience UnavailableExceptions.
> - Be written in a Row-centric manner such that it is easy for consumers to 
> reconstitute rows atomically.
> - Written in a simple format designed to be consumed *directly* by daemons 
> written in non JVM languages
> h2. Nice-to-haves
> I strongly suspect that the following features will be asked for, but I also 
> believe that they can be deferred for a subsequent release, and to 

[jira] [Created] (CASSANDRA-11403) Serializer/Version mismatch during upgrades to C* 3.0

[Anthony Cozzie (JIRA)]

Anthony Cozzie created CASSANDRA-11403:
--

 Summary: Serializer/Version mismatch during upgrades to C* 3.0
 Key: CASSANDRA-11403
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11403
 Project: Cassandra
  Issue Type: Bug
  Components: Streaming and Messaging
Reporter: Anthony Cozzie


The problem line seems to be:
{code}
MessageOut message = 
readCommand.createMessage(MessagingService.instance().getVersion(endpoint));
{code}

SinglePartitionReadCommand then picks the serializer based on the version:
{code}
return new MessageOut<>(MessagingService.Verb.READ, this, version < 
MessagingService.VERSION_30 ? legacyReadCommandSerializer : serializer);
{code}

However, OutboundTcpConnectionPool will test the payload size vs the version 
from its smallMessages connection:
{code}
return msg.payloadSize(smallMessages.getTargetVersion()) > 
LARGE_MESSAGE_THRESHOLD
{code}

Which is set when the connection/pool is created:
{code}
targetVersion = MessagingService.instance().getVersion(pool.endPoint());
{code}

During an upgrade, this state can change between these two calls leading the 
3.0 serializer being used on 2.x packets and the following stacktrace:
ERROR [OptionalTasks:1] 2016-03-07 19:53:06,445  CassandraDaemon.java:195 - 
Exception in thread Thread[OptionalTasks:1,5,main]
java.lang.AssertionError: null
at 
org.apache.cassandra.db.ReadCommand$Serializer.serializedSize(ReadCommand.java:632)
 ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.db.ReadCommand$Serializer.serializedSize(ReadCommand.java:536)
 ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:166) 
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:72)
 ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:609)
 ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:758) 
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.net.MessagingService.sendRR(MessagingService.java:701) 
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.net.MessagingService.sendRRWithFailure(MessagingService.java:684)
 ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.service.AbstractReadExecutor.makeRequests(AbstractReadExecutor.java:110)
 ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.service.AbstractReadExecutor.makeDataRequests(AbstractReadExecutor.java:85)
 ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.service.AbstractReadExecutor$NeverSpeculatingReadExecutor.executeAsync(AbstractReadExecutor.java:214)
 ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.service.StorageProxy$SinglePartitionReadLifecycle.doInitialQueries(StorageProxy.java:1699)
 ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.service.StorageProxy.fetchRows(StorageProxy.java:1654) 
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.service.StorageProxy.readRegular(StorageProxy.java:1601) 
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.service.StorageProxy.read(StorageProxy.java:1520) 
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.db.SinglePartitionReadCommand$Group.execute(SinglePartitionReadCommand.java:918)
 ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:251)
 ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:212)
 ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:77)
 ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:206)
 ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:237) 
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:252) 
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:247) 
~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.auth.CassandraRoleManager.hasExistingRoles(CassandraRoleManager.java:354)
 ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 
org.apache.cassandra.auth.CassandraRoleManager.setupDefaultRole(CassandraRoleManager.java:330)
 ~[cassandra-all-3.0.3.903.jar:3.0.3.903]
at 

[jira] [Updated] (CASSANDRA-11290) dtest failure in materialized_views_test.TestMaterializedViewsConsistency.single_partition_consistent_reads_after_write_test

[Philip Thompson (JIRA)]

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

Philip Thompson updated CASSANDRA-11290:

Assignee: (was: Philip Thompson)

> dtest failure in 
> materialized_views_test.TestMaterializedViewsConsistency.single_partition_consistent_reads_after_write_test
> 
>
> Key: CASSANDRA-11290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11290
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Russ Hatch
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/26/testReport/materialized_views_test/TestMaterializedViewsConsistency/single_partition_consistent_reads_after_write_test
> Failed on CassCI build trunk_offheap_dtest #26
> Failing infrequently but same error on at least two of those infrequent flaps:
> {noformat}
> Connection to 127.0.0.2 was closed
> {noformat}



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

[jira] [Commented] (CASSANDRA-11375) COPY FROM fails when importing blob

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11375:
-

+1, tested locally and fixes copy from error on py2.6 (and also works on 2.7). 
Marking as ready to commit. Thanks!

> COPY FROM fails when importing blob
> ---
>
> Key: CASSANDRA-11375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11375
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Philippe Thibaudeau
>Assignee: Stefania
> Fix For: 2.1.x
>
>
> When we try to COPY TO a table containing a blob, we get this error 
> COPY test.blobTable FROM '/tmp/test1.csv' WITH NULL='null' AND DELIMITER=',' 
> AND QUOTE='"';
> /opt/apache-cassandra-2.1.13.4/bin/../pylib/cqlshlib/copyutil.py:1602: 
> DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
> /opt/apache-cassandra-2.1.13.4/bin/../pylib/cqlshlib/copyutil.py:1850: 
> DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
> Failed to import 5 rows: ParseError - fromhex() argument 1 must be unicode, 
> not str -  given up without retries
> Failed to process 5 rows; failed rows written to import_test_blobTable.err
> Same COPY TO function worked fine with 2.1.9
> The csv is generated by doing a COPY FROM on the same table.
> Is there any work around this issue?



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

[jira] [Updated] (CASSANDRA-11375) COPY FROM fails when importing blob

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-11375:

Status: Ready to Commit  (was: Patch Available)

> COPY FROM fails when importing blob
> ---
>
> Key: CASSANDRA-11375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11375
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Philippe Thibaudeau
>Assignee: Stefania
> Fix For: 2.1.x
>
>
> When we try to COPY TO a table containing a blob, we get this error 
> COPY test.blobTable FROM '/tmp/test1.csv' WITH NULL='null' AND DELIMITER=',' 
> AND QUOTE='"';
> /opt/apache-cassandra-2.1.13.4/bin/../pylib/cqlshlib/copyutil.py:1602: 
> DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
> /opt/apache-cassandra-2.1.13.4/bin/../pylib/cqlshlib/copyutil.py:1850: 
> DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
> Failed to import 5 rows: ParseError - fromhex() argument 1 must be unicode, 
> not str -  given up without retries
> Failed to process 5 rows; failed rows written to import_test_blobTable.err
> Same COPY TO function worked fine with 2.1.9
> The csv is generated by doing a COPY FROM on the same table.
> Is there any work around this issue?



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

[jira] [Updated] (CASSANDRA-11290) dtest failure in materialized_views_test.TestMaterializedViewsConsistency.single_partition_consistent_reads_after_write_test

[Philip Thompson (JIRA)]

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

Philip Thompson updated CASSANDRA-11290:

Issue Type: Bug  (was: Test)

> dtest failure in 
> materialized_views_test.TestMaterializedViewsConsistency.single_partition_consistent_reads_after_write_test
> 
>
> Key: CASSANDRA-11290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11290
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Russ Hatch
>Assignee: Philip Thompson
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/26/testReport/materialized_views_test/TestMaterializedViewsConsistency/single_partition_consistent_reads_after_write_test
> Failed on CassCI build trunk_offheap_dtest #26
> Failing infrequently but same error on at least two of those infrequent flaps:
> {noformat}
> Connection to 127.0.0.2 was closed
> {noformat}



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

[jira] [Issue Comment Deleted] (CASSANDRA-11290) dtest failure in materialized_views_test.TestMaterializedViewsConsistency.single_partition_consistent_reads_after_write_test

[Philip Thompson (JIRA)]

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

Philip Thompson updated CASSANDRA-11290:

Comment: was deleted

(was: Based on {{DEBUG [GossipStage:1] 2016-02-11 19:15:10,989 
FailureDetector.java:456 - Ignoring interval time of 2000760096 for 
/127.0.0.2}} in node3's log, it seems like just a shakey network problem 
to/from node2. We could add retry code to this method in dtest?

)

> dtest failure in 
> materialized_views_test.TestMaterializedViewsConsistency.single_partition_consistent_reads_after_write_test
> 
>
> Key: CASSANDRA-11290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11290
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Russ Hatch
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node2.log, node2_debug.log, 
> node3.log, node3_debug.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/26/testReport/materialized_views_test/TestMaterializedViewsConsistency/single_partition_consistent_reads_after_write_test
> Failed on CassCI build trunk_offheap_dtest #26
> Failing infrequently but same error on at least two of those infrequent flaps:
> {noformat}
> Connection to 127.0.0.2 was closed
> {noformat}



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

[jira] [Commented] (CASSANDRA-11396) dtest failure in upgrade_tests.cql_tests.TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD.collection_flush_test

[Russ Hatch (JIRA)]

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

Russ Hatch commented on CASSANDRA-11396:


still repros on CI, going to test if this could be a schema agreement holding 
up cl.all, here: 
http://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/32/

> dtest failure in 
> upgrade_tests.cql_tests.TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD.collection_flush_test
> -
>
> Key: CASSANDRA-11396
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11396
> Project: Cassandra
>  Issue Type: Test
>  Components: Testing
>Reporter: Philip Thompson
>Assignee: Russ Hatch
>  Labels: dtest
>
> example failure:
> {code}
> 
> {code}
> http://cassci.datastax.com/job/upgrade_tests-all/25/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_2_UpTo_3_0_HEAD/collection_flush_test
> Failed on CassCI build upgrade_tests-all #25
> It's an inconsistent failure that happens across a number of tests. I'll 
> include all the ones I find here.
> http://cassci.datastax.com/job/upgrade_tests-all/26/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_1_UpTo_2_2_HEAD/static_with_limit_test/
> http://cassci.datastax.com/job/upgrade_tests-all/28/testReport/upgrade_tests.paging_test/TestPagingDatasetChangesNodes3RF3_2_2_HEAD_UpTo_Trunk/test_data_change_impacting_later_page/
> http://cassci.datastax.com/job/upgrade_tests-all/29/testReport/upgrade_tests.cql_tests/TestCQLNodes3RF3_2_1_UpTo_Trunk/range_key_ordered_test/



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

[jira] [Commented] (CASSANDRA-11401) [Regression] Incorrect results for clustering tuples query

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-11401:
-

This is related to CASSANDRA-7821.  The 3.4 behavior is actually the correct 
behavior, logically.  If you ignore the order that Cassandra stores the rows on 
disk, you can see that logically speaking, 3.3 returns incorrect results.  For 
example, {{(----, '2015-10-01 00:00:00+')}} 
is returned, despite being less than your minimum bound of 
{{(----, '2015-10-02 00:00:00+')}}.  The 
fix in CASSANDRA-7821 changed the behavior from always executing a single 
contiguous slice (even if it would return incorrect results) to performing 
multiple slices if necessary in order to return the correct logical results.

> [Regression] Incorrect results for clustering tuples query
> --
>
> Key: CASSANDRA-11401
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11401
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: *Cassandra 3.4*
>Reporter: DOAN DuyHai
>Priority: Critical
>
> There is a regression since *Cassandra 3.4* with query using clustering tuple 
> values:
> {noformat}
> cqlsh:test> CREATE TABLE IF NOT EXISTS entity_with_clusterings(
>   id bigint,
>   uuid uuid,
>   date timestamp,
>   value text,
>   PRIMARY KEY(id, uuid, date))
> WITH CLUSTERING ORDER BY(uuid ASC, date DESC);
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-01 
> 00:00:00+', 'val1');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-02 
> 00:00:00+', 'val2');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----, '2015-10-03 
> 00:00:00+', 'val3');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----0001, '2015-10-04 
> 00:00:00+', 'val4');
> cqlsh:test> INSERT INTO entity_with_clusterings(id, uuid, date, value) 
> VALUES(3233835834146573312, ----0001, '2015-10-05 
> 00:00:00+', 'val5');
> cqlsh:test> SELECT * FROM entity_with_clusterings;
>  id  | uuid | date
>  | value
> -+--+--+---
>  3233835834146573312 | ---- | 2015-10-03 
> 00:00:00+ |  val3
>  3233835834146573312 | ---- | 2015-10-02 
> 00:00:00+ |  val2
>  3233835834146573312 | ---- | 2015-10-01 
> 00:00:00+ |  val1
>  3233835834146573312 | ----0001 | 2015-10-05 
> 00:00:00+ |  val5
>  3233835834146573312 | ----0001 | 2015-10-04 
> 00:00:00+ |  val4
> (5 rows)
> cqlsh:test > SELECT uuid,date,value 
> FROM entity_with_clusterings 
> WHERE id=3233835834146573312 
> AND (uuid,date)>=(----,'2015-10-02 
> 00:00:00+') 
> AND (uuid,date)<(----0001, '2015-10-04 
> 00:00:00+');
>  uuid | date| 
> value
> --+-+---
>  ---- | 2015-10-03 00:00:00.00+ |  
> val3
>  ---- | 2015-10-02 00:00:00.00+ |  
> val2
> {noformat}
> The same query with *Cassandra 3.3* returns correct answer:
> {noformat}
> cqlsh:test> SELECT uuid,date,value
> FROM entity_with_clusterings
> WHERE id=3233835834146573312
> AND (uuid,date)>=(----,'2015-10-02 
> 00:00:00+')
> AND (uuid,date)<(----0001, '2015-10-04 
> 00:00:00+');
>  uuid | date | value
> --+--+---
>  ---- | 2015-10-02 00:00:00+ |  val2
>  ---- | 2015-10-01 00:00:00+ |  val1
>  ----0001 | 2015-10-05 00:00:00+ |  val5
> {noformat}



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

[jira] [Updated] (CASSANDRA-11096) Upgrade netty to >= 4.0.34

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-11096:
--
Reviewer: Aleksey Yeschenko

> Upgrade netty to >= 4.0.34
> --
>
> Key: CASSANDRA-11096
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11096
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Brandon Williams
>Assignee: Benjamin Lerer
> Fix For: 3.6
>
>
> Amongst other things, the native protocol will not bind ipv6 easily (see 
> CASSANDRA-11047) until we upgrade.



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

[jira] [Commented] (CASSANDRA-11096) Upgrade netty to >= 4.0.34

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-11096:
---

Sure.

> Upgrade netty to >= 4.0.34
> --
>
> Key: CASSANDRA-11096
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11096
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Brandon Williams
>Assignee: Benjamin Lerer
> Fix For: 3.6
>
>
> Amongst other things, the native protocol will not bind ipv6 easily (see 
> CASSANDRA-11047) until we upgrade.



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

[jira] [Commented] (CASSANDRA-11390) Too big MerkleTrees allocated during repair

[Marcus Olsson (JIRA)]

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

Marcus Olsson commented on CASSANDRA-11390:
---

bq. I imagine this is what was always intended - perhaps we should open a new 
ticket to investigate if we should increase it
It would probably be good to test if it's a reasonable limit, but it might not 
have that high priority unless we see lots of over-streaming from the current 
one.

bq. Note that we don't care about the ranges when we calculate this, so we have 
to assume that gain within a range is the same as the total gain. Biggest 
problem is how to test this, will try to figure something out.
If it gets too complex to the test it might not be worth to have the compaction 
gain as part of the calculation. It would most probably reduce the MerkleTrees 
sizes, which is good unless the compaction gain comes from data that is not 
part of the repair. Capping the MerkleTrees total size might be good enough 
alone since the only thing the duplicate partitions should bring is 
unnecessarily large resolution, not the memory problems. It could possibly be a 
separate ticket to investigate if there would be a gain from using the 
compaction gain in the calculation.

---

For:
{code}
logger.trace("Created {} merkle trees, {} partitions, {} bytes", tree.size(), 
allPartitions, MerkleTrees.serializer.serializedSize(tree, 0));
{code}
The {{MerkleTrees.size()}} method returns the combined value from calling 
{{MerkleTree.size()}} on all MerkleTrees, which returns {{2^d}}. To get the 
number of merkle trees we could either create a new method in {{MerkleTrees}} 
(treeCount()?) or use {{MerkleTrees.ranges().size()}}. It could probably be 
good to have both the number of trees as well as the output from 
{{MerkleTrees.size()}} in the log output.

Other than that LGTM. :)

> Too big MerkleTrees allocated during repair
> ---
>
> Key: CASSANDRA-11390
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11390
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
> Fix For: 3.0.x, 3.x
>
>
> Since CASSANDRA-5220 we create one merkle tree per range, but each of those 
> trees is allocated to hold all the keys on the node, taking up too much memory



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

[jira] [Commented] (CASSANDRA-9598) bad classapth for 'sstablerepairedset' in 'cassandra-tools' package

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan commented on CASSANDRA-9598:


+1 script changes look good to me.

> bad classapth for 'sstablerepairedset' in 'cassandra-tools' package
> ---
>
> Key: CASSANDRA-9598
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9598
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Debian 3.16.7, cassandra-tools 2.1.6, cassandra 2.1.6
>Reporter: Clément Lardeur
>Assignee: Yuki Morishita
>Priority: Minor
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> The script 'sstablerepairedset' is not ready out of the box for debian 
> distro, maybe due to the refactoring of CASSANDRA-7160 to pack out tools from 
> the bin directory.
> Actually in 'sstablerepairedset' the classapth is calculated with:
> {code}
> if [ "x$CLASSPATH" = "x" ]; then
> 
> # execute from the build dir.
> if [ -d `dirname $0`/../../build/classes ]; then
> for directory in `dirname $0`/../../build/classes/*; do
> CLASSPATH=$CLASSPATH:$directory
> done
> else
> if [ -f `dirname $0`/../lib/stress.jar ]; then
> CLASSPATH=`dirname $0`/../lib/stress.jar
> fi
> fi
> for jar in `dirname $0`/../../lib/*.jar; do
> CLASSPATH=$CLASSPATH:$jar
> done
> fi
> {code}
> Whereas in other scripts from the 'bin/tools', the classpath is calculated 
> with:
> {code}
> if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
> for include in "`dirname "$0"`/cassandra.in.sh" \
>"$HOME/.cassandra.in.sh" \
>/usr/share/cassandra/cassandra.in.sh \
>/usr/local/share/cassandra/cassandra.in.sh \
>/opt/cassandra/cassandra.in.sh; do
> if [ -r "$include" ]; then
> . "$include"
> break
> fi
> done
> elif [ -r "$CASSANDRA_INCLUDE" ]; then
> . "$CASSANDRA_INCLUDE"
> fi
> {code}
> I think that a little refactoring could be good to extract the common part of 
> these scripts like the computation of the CLASSPATH and the set of JAVA_HOME.



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

[jira] [Commented] (CASSANDRA-11096) Upgrade netty to >= 4.0.34

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-11096:
-

I'm also planning on using the latest netty 4.0.x jar for CASSANDRA-8457 (I'm 
currently using 4.0.34, as well). I haven't found any problems in internode 
testing, thus far, so I'm a +1. I would be good to get another opinion, 
however, wrt to the native protocol/client-facing side of things.

> Upgrade netty to >= 4.0.34
> --
>
> Key: CASSANDRA-11096
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11096
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Brandon Williams
>Assignee: Benjamin Lerer
> Fix For: 3.6
>
>
> Amongst other things, the native protocol will not bind ipv6 easily (see 
> CASSANDRA-11047) until we upgrade.



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

[jira] [Updated] (CASSANDRA-9598) bad classapth for 'sstablerepairedset' in 'cassandra-tools' package

[Yuki Morishita (JIRA)]

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

Yuki Morishita updated CASSANDRA-9598:
--
Reproduced In: 2.2.5, 2.1.6  (was: 2.1.6, 2.2.5)
 Reviewer: Jeremiah Jordan

[~jjordan] Can you review?

> bad classapth for 'sstablerepairedset' in 'cassandra-tools' package
> ---
>
> Key: CASSANDRA-9598
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9598
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Debian 3.16.7, cassandra-tools 2.1.6, cassandra 2.1.6
>Reporter: Clément Lardeur
>Assignee: Yuki Morishita
>Priority: Minor
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> The script 'sstablerepairedset' is not ready out of the box for debian 
> distro, maybe due to the refactoring of CASSANDRA-7160 to pack out tools from 
> the bin directory.
> Actually in 'sstablerepairedset' the classapth is calculated with:
> {code}
> if [ "x$CLASSPATH" = "x" ]; then
> 
> # execute from the build dir.
> if [ -d `dirname $0`/../../build/classes ]; then
> for directory in `dirname $0`/../../build/classes/*; do
> CLASSPATH=$CLASSPATH:$directory
> done
> else
> if [ -f `dirname $0`/../lib/stress.jar ]; then
> CLASSPATH=`dirname $0`/../lib/stress.jar
> fi
> fi
> for jar in `dirname $0`/../../lib/*.jar; do
> CLASSPATH=$CLASSPATH:$jar
> done
> fi
> {code}
> Whereas in other scripts from the 'bin/tools', the classpath is calculated 
> with:
> {code}
> if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
> for include in "`dirname "$0"`/cassandra.in.sh" \
>"$HOME/.cassandra.in.sh" \
>/usr/share/cassandra/cassandra.in.sh \
>/usr/local/share/cassandra/cassandra.in.sh \
>/opt/cassandra/cassandra.in.sh; do
> if [ -r "$include" ]; then
> . "$include"
> break
> fi
> done
> elif [ -r "$CASSANDRA_INCLUDE" ]; then
> . "$CASSANDRA_INCLUDE"
> fi
> {code}
> I think that a little refactoring could be good to extract the common part of 
> these scripts like the computation of the CLASSPATH and the set of JAVA_HOME.



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

[jira] [Updated] (CASSANDRA-9598) bad classapth for 'sstablerepairedset' in 'cassandra-tools' package

[Yuki Morishita (JIRA)]

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

Yuki Morishita updated CASSANDRA-9598:
--
Reproduced In: 2.2.5, 2.1.6  (was: 2.1.6, 2.2.5)
   Status: Patch Available  (was: Reopened)

||branch||testall||dtest||
|[9598-2.1|https://github.com/yukim/cassandra/tree/9598-2.1]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-9598-2.1-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-9598-2.1-dtest/lastCompletedBuild/testReport/]|
|[9598-2.2|https://github.com/yukim/cassandra/tree/9598-2.2]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-9598-2.2-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-9598-2.2-dtest/lastCompletedBuild/testReport/]|
|[9598-3.0|https://github.com/yukim/cassandra/tree/9598-3.0]|[testall|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-9598-3.0-testall/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/yukim/job/yukim-9598-3.0-dtest/lastCompletedBuild/testReport/]|

SSTableExport in cassandra-2.1 and cassandra-2.2 needs to be patched also 
because scripts now have '-ea'.

> bad classapth for 'sstablerepairedset' in 'cassandra-tools' package
> ---
>
> Key: CASSANDRA-9598
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9598
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Debian 3.16.7, cassandra-tools 2.1.6, cassandra 2.1.6
>Reporter: Clément Lardeur
>Assignee: Yuki Morishita
>Priority: Minor
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> The script 'sstablerepairedset' is not ready out of the box for debian 
> distro, maybe due to the refactoring of CASSANDRA-7160 to pack out tools from 
> the bin directory.
> Actually in 'sstablerepairedset' the classapth is calculated with:
> {code}
> if [ "x$CLASSPATH" = "x" ]; then
> 
> # execute from the build dir.
> if [ -d `dirname $0`/../../build/classes ]; then
> for directory in `dirname $0`/../../build/classes/*; do
> CLASSPATH=$CLASSPATH:$directory
> done
> else
> if [ -f `dirname $0`/../lib/stress.jar ]; then
> CLASSPATH=`dirname $0`/../lib/stress.jar
> fi
> fi
> for jar in `dirname $0`/../../lib/*.jar; do
> CLASSPATH=$CLASSPATH:$jar
> done
> fi
> {code}
> Whereas in other scripts from the 'bin/tools', the classpath is calculated 
> with:
> {code}
> if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
> for include in "`dirname "$0"`/cassandra.in.sh" \
>"$HOME/.cassandra.in.sh" \
>/usr/share/cassandra/cassandra.in.sh \
>/usr/local/share/cassandra/cassandra.in.sh \
>/opt/cassandra/cassandra.in.sh; do
> if [ -r "$include" ]; then
> . "$include"
> break
> fi
> done
> elif [ -r "$CASSANDRA_INCLUDE" ]; then
> . "$CASSANDRA_INCLUDE"
> fi
> {code}
> I think that a little refactoring could be good to extract the common part of 
> these scripts like the computation of the CLASSPATH and the set of JAVA_HOME.



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

[jira] [Commented] (CASSANDRA-11096) Upgrade netty to >= 4.0.34

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-11096:


[~iamaleksey] could you review?

> Upgrade netty to >= 4.0.34
> --
>
> Key: CASSANDRA-11096
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11096
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Brandon Williams
>Assignee: Benjamin Lerer
> Fix For: 3.6
>
>
> Amongst other things, the native protocol will not bind ipv6 easily (see 
> CASSANDRA-11047) until we upgrade.



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

[jira] [Assigned] (CASSANDRA-9598) bad classapth for 'sstablerepairedset' in 'cassandra-tools' package

[Yuki Morishita (JIRA)]

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

Yuki Morishita reassigned CASSANDRA-9598:
-

Assignee: Yuki Morishita

> bad classapth for 'sstablerepairedset' in 'cassandra-tools' package
> ---
>
> Key: CASSANDRA-9598
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9598
> Project: Cassandra
>  Issue Type: Bug
>  Components: Tools
> Environment: Debian 3.16.7, cassandra-tools 2.1.6, cassandra 2.1.6
>Reporter: Clément Lardeur
>Assignee: Yuki Morishita
>Priority: Minor
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> The script 'sstablerepairedset' is not ready out of the box for debian 
> distro, maybe due to the refactoring of CASSANDRA-7160 to pack out tools from 
> the bin directory.
> Actually in 'sstablerepairedset' the classapth is calculated with:
> {code}
> if [ "x$CLASSPATH" = "x" ]; then
> 
> # execute from the build dir.
> if [ -d `dirname $0`/../../build/classes ]; then
> for directory in `dirname $0`/../../build/classes/*; do
> CLASSPATH=$CLASSPATH:$directory
> done
> else
> if [ -f `dirname $0`/../lib/stress.jar ]; then
> CLASSPATH=`dirname $0`/../lib/stress.jar
> fi
> fi
> for jar in `dirname $0`/../../lib/*.jar; do
> CLASSPATH=$CLASSPATH:$jar
> done
> fi
> {code}
> Whereas in other scripts from the 'bin/tools', the classpath is calculated 
> with:
> {code}
> if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
> for include in "`dirname "$0"`/cassandra.in.sh" \
>"$HOME/.cassandra.in.sh" \
>/usr/share/cassandra/cassandra.in.sh \
>/usr/local/share/cassandra/cassandra.in.sh \
>/opt/cassandra/cassandra.in.sh; do
> if [ -r "$include" ]; then
> . "$include"
> break
> fi
> done
> elif [ -r "$CASSANDRA_INCLUDE" ]; then
> . "$CASSANDRA_INCLUDE"
> fi
> {code}
> I think that a little refactoring could be good to extract the common part of 
> these scripts like the computation of the CLASSPATH and the set of JAVA_HOME.



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