[jira] [Updated] (CASSANDRA-12054) Add CQL Data Modeler to tree

[Sebastian Estevez (JIRA)]

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

Sebastian Estevez updated CASSANDRA-12054:
--
Description: 
cassandra-stess, like many powerful tools, is not easy to use. It requires some 
statistical understanding and syntactic skill, in order to get up and running 
with even a simple data model, user profile driven test (for details see the 
cassandra-stress docs). Furthermore, designing a good cassandra data model 
requires basic understanding of how CQL works and how c* data is laid out on 
disk as a result of partitioning and clustering.

The CQL DataModeler aims to simplify this task, getting users up and running 
with user profile powered cassandra-stress tests in minutes.

Given the feedback the community has voiced about the usability of 
cassandra-stress at NGCC, it was suggested that I contribute the data modeler 
to the open source project so it can be maintained in tree and leveraged by 
users.

It is a simple static web application and users should be able to use it by 
just opening up index.html with their browser and populating the GUI.

Check it out here:
http://www.sestevez.com/sestevez/CassandraDataModeler/

The source code sits in github, once we clean it up and know where it will live 
in tree, I'll submit a c* patch:
https://github.com/phact/CassandraDataModeler

I have developed this as a side project and not as production ready code. I 
welcome feedback on how it can be cleaned up and improved.

cc: [~tjake][~carlyeks]

Future improvements include:
1) Add cluster distributions (currently only size and population are supported)
2) Add functionality so that the histograms display overall distributions 
(combining cluster and population distributions for fields)
3) Include batch configuration and insert distribution
4) Include -pop and other command line options that are crucial for describing 
workloads
5) Add sparse table capabilities (already in stress but currently undocumented)
6) Add a few example data models to ship with the tool
7) Eventually allow users to contribute back profiles to some sort of community

IMO this jira should be contingent on 1, 3, 4, and 6 being completed. 

  was:
cassandra-stess, like many powerful tools, is not easy to use. It requires some 
statistical understanding and syntactic skill, in order to get up and running 
with even a simple data model, user profile driven test (for details see the 
cassandra-stress docs). Furthermore, designing a good cassandra data model 
requires basic understanding of how CQL works and how c* data is laid out on 
disk as a result of partitioning and clustering.

The CQL DataModeler aims to simplify this task, getting users up and running 
with user profile powered cassandra-stress tests in minutes.

Given the feedback the community has voiced about the usability of 
cassandra-stress at NGCC, it was suggested that I contribute the data modeler 
to the open source project so it can be maintained in tree and leveraged by 
users.

It is a simple static web application and users should be able to use it by 
just opening up index.html with their browser and populating the GUI.

Check it out here:
http://www.sestevez.com/sestevez/CassandraDataModeler/

The source code sits in github, once clean it up and know where in tree it will 
live, I'll submit a c* patch:
https://github.com/phact/CassandraDataModeler

I have developed this as a side project and not as production ready code. I 
welcome feedback on how it can be cleaned up and improved.

cc: [~tjake][~carlyeks]

Future improvements include:
1) Add cluster distributions (currently only size and population are supported)
2) Add functionality so that the histograms display overall distributions 
(combining cluster and population distributions for fields)
3) Include batch configuration and insert distribution
4) Include -pop and other command line options that are crucial for describing 
workloads
5) Add sparse table capabilities (already in stress but currently undocumented)
6) Add a few example data models to ship with the tool
7) Eventually allow users to contribute back profiles to some sort of community

IMO this jira should be contingent on 1, 3, 4, and 6 being completed. 


> Add CQL Data Modeler to tree
> 
>
> Key: CASSANDRA-12054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12054
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Sebastian Estevez
>
> cassandra-stess, like many powerful tools, is not easy to use. It requires 
> some statistical understanding and syntactic skill, in order to get up and 
> running with even a simple data model, user profile driven test (for details 
> see the cassandra-stress docs). Furthermore, designing a good cassandra data 
> model requires basic understanding of how CQL works and how c* data is 

[jira] [Updated] (CASSANDRA-12054) Add CQL Data Modeler to tree

[Sebastian Estevez (JIRA)]

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

Sebastian Estevez updated CASSANDRA-12054:
--
Description: 
cassandra-stess, like many powerful tools, is not easy to use. It requires some 
statistical understanding and syntactic skill, in order to get up and running 
with even a simple data model, user profile driven test (for details see the 
cassandra-stress docs). Furthermore, designing a good cassandra data model 
requires basic understanding of how CQL works and how c* data is laid out on 
disk as a result of partitioning and clustering.

The CQL DataModeler aims to simplify this task, getting users up and running 
with user profile powered cassandra-stress tests in minutes.

Given the feedback the community has voiced about the usability of 
cassandra-stress at NGCC, it was suggested that I contribute the data modeler 
to the open source project so it can be maintained in tree and leveraged by 
users.

It is a simple static web application and users should be able to use it by 
just opening up index.html with their browser and populating the GUI.

Check it out here:
http://www.sestevez.com/sestevez/CassandraDataModeler/

The source code sits in github, once clean it up and know where in tree it will 
live, I'll submit a c* patch:
https://github.com/phact/CassandraDataModeler

I have developed this as a side project and not as production ready code. I 
welcome feedback on how it can be cleaned up and improved.

cc: [~tjake][~carlyeks]

Future improvements include:
1) Add cluster distributions (currently only size and population are supported)
2) Add functionality so that the histograms display overall distributions 
(combining cluster and population distributions for fields)
3) Include batch configuration and insert distribution
4) Include -pop and other command line options that are crucial for describing 
workloads
5) Add sparse table capabilities (already in stress but currently undocumented)
6) Add a few example data models to ship with the tool
7) Eventually allow users to contribute back profiles to some sort of community

IMO this jira should be contingent on 1, 3, 4, and 6 being completed. 

  was:
cassandra-stess, like many powerful tools, is not easy to use. It requires some 
statistical understanding and syntactic skill, in order to get up and running 
with even a simple data model, user profile driven test (for details see the 
cassandra-stress docs). Furthermore, designing a good cassandra data model 
requires basic understanding of how CQL works and how c* data is laid out on 
disk as a result of partitioning and clustering.

The CQL DataModeler aims to simplify this task, getting users up and running 
with user profile powered cassandra-stress tests in minutes.

Given the feedback the community has voiced about the usability of 
cassandra-stress at NGCC, it was suggested that I contribute the data modeler 
to the open source project so it can be maintained in tree and leveraged by 
users.

It is a simple static web application and users should be able to use it by 
just opening up index.html with their browser and populating the GUI.

Check it out here:
http://www.sestevez.com/sestevez/CassandraDataModeler/

I have developed this as a side project and not as production ready code. I 
welcome feedback on how it can be cleaned up and improved.

cc: [~tjake][~carlyeks]

Future improvements include:
1) Add cluster distributions (currently only size and population are supported)
2) Add functionality so that the histograms display overall distributions 
(combining cluster and population distributions for fields)
3) Include batch configuration and insert distribution
4) Include -pop and other command line options that are crucial for describing 
workloads
5) Add sparse table capabilities (already in stress but currently undocumented)
6) Add a few example data models to ship with the tool
7) Eventually allow users to contribute back profiles to some sort of community

IMO this jira should be contingent on 1, 3, 4, and 6 being completed. 


> Add CQL Data Modeler to tree
> 
>
> Key: CASSANDRA-12054
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12054
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Sebastian Estevez
>
> cassandra-stess, like many powerful tools, is not easy to use. It requires 
> some statistical understanding and syntactic skill, in order to get up and 
> running with even a simple data model, user profile driven test (for details 
> see the cassandra-stress docs). Furthermore, designing a good cassandra data 
> model requires basic understanding of how CQL works and how c* data is laid 
> out on disk as a result of partitioning and clustering.
> The CQL DataModeler aims to simplify this task, getting users up and running 
> with user profile 

[jira] [Created] (CASSANDRA-12054) Add CQL Data Modeler to tree

[Sebastian Estevez (JIRA)]

Sebastian Estevez created CASSANDRA-12054:
-

 Summary: Add CQL Data Modeler to tree
 Key: CASSANDRA-12054
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12054
 Project: Cassandra
  Issue Type: New Feature
Reporter: Sebastian Estevez


cassandra-stess, like many powerful tools, is not easy to use. It requires some 
statistical understanding and syntactic skill, in order to get up and running 
with even a simple data model, user profile driven test (for details see the 
cassandra-stress docs). Furthermore, designing a good cassandra data model 
requires basic understanding of how CQL works and how c* data is laid out on 
disk as a result of partitioning and clustering.

The CQL DataModeler aims to simplify this task, getting users up and running 
with user profile powered cassandra-stress tests in minutes.

Given the feedback the community has voiced about the usability of 
cassandra-stress at NGCC, it was suggested that I contribute the data modeler 
to the open source project so it can be maintained in tree and leveraged by 
users.

It is a simple static web application and users should be able to use it by 
just opening up index.html with their browser and populating the GUI.

Check it out here:
http://www.sestevez.com/sestevez/CassandraDataModeler/

I have developed this as a side project and not as production ready code. I 
welcome feedback on how it can be cleaned up and improved.

cc: [~tjake][~carlyeks]

Future improvements include:
1) Add cluster distributions (currently only size and population are supported)
2) Add functionality so that the histograms display overall distributions 
(combining cluster and population distributions for fields)
3) Include batch configuration and insert distribution
4) Include -pop and other command line options that are crucial for describing 
workloads
5) Add sparse table capabilities (already in stress but currently undocumented)
6) Add a few example data models to ship with the tool
7) Eventually allow users to contribute back profiles to some sort of community

IMO this jira should be contingent on 1, 3, 4, and 6 being completed. 



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

[jira] [Commented] (CASSANDRA-12045) Cassandra failure during write query at consistency LOCAL_QUORUM

[Raghavendra Pinninti (JIRA)]

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

Raghavendra Pinninti commented on CASSANDRA-12045:
--

Hi Hobbs, Thanks much for the response. I am loading a xmlfile of size 20 mb 
into text column of Cassandra table through Cassandra JDBC driver. I didn't 
find any logs in Cassandra installation log directory.

>  Cassandra failure during write query at consistency LOCAL_QUORUM 
> --
>
> Key: CASSANDRA-12045
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12045
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Local Write-Read Paths
> Environment: Eclipse java environment
>Reporter: Raghavendra Pinninti
> Fix For: 3.x
>
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
> While I am writing xml file into Cassandra table column I am facing following 
> exception.Its a 3 node cluster and All nodes are up.
> com.datastax.driver.core.exceptions.WriteFailureException: Cassandra failure 
> during write query at consistency LOCAL_QUORUM (2 responses were required but 
> only 0 replica responded, 1 failed) at 
> com.datastax.driver.core.exceptions.WriteFailureException.copy(WriteFailureException.java:80)
>  at 
> com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
>  at 
> com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:245)
>  at com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:55) 
> at com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:39) 
> at DBConnection.oracle2Cassandra(DBConnection.java:267) at 
> DBConnection.main(DBConnection.java:292) Caused by: 
> com.datastax.driver.core.exceptions.WriteFailureException: Cassandra failure 
> during write query at consistency LOCAL_QUORUM (2 responses were required but 
> only 0 replica responded, 1 failed) at 
> com.datastax.driver.core.exceptions.WriteFailureException.copy(WriteFailureException.java:91)
>  at com.datastax.driver.core.Responses$Error.asException(Responses.java:119) 
> at 
> com.datastax.driver.core.DefaultResultSetFuture.onSet(DefaultResultSetFuture.java:180)
>  at 
> com.datastax.driver.core.RequestHandler.setFinalResult(RequestHandler.java:186)
>  at 
> com.datastax.driver.core.RequestHandler.access$2300(RequestHandler.java:44) 
> at 
> com.datastax.driver.core.RequestHandler$SpeculativeExecution.setFinalResult(RequestHandler.java:754)
>  at 
> com.datastax.driver.core.RequestHandler$SpeculativeExecution.onSet(RequestHandler.java:576)
> It would be great if someone helps me out from this situation. Thanks
>  



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

[jira] [Updated] (CASSANDRA-12045) Cassandra failure during write query at consistency LOCAL_QUORUM

[Raghavendra Pinninti (JIRA)]

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

Raghavendra Pinninti updated CASSANDRA-12045:
-
Description: 
While I am writing xml file into Cassandra table column I am facing following 
exception.Its a 3 node cluster and All nodes are up.

com.datastax.driver.core.exceptions.WriteFailureException: Cassandra failure 
during write query at consistency LOCAL_QUORUM (2 responses were required but 
only 0 replica responded, 1 failed) at 
com.datastax.driver.core.exceptions.WriteFailureException.copy(WriteFailureException.java:80)
 at 
com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
 at 
com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:245)
 at com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:55) 
at com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:39) at 
DBConnection.oracle2Cassandra(DBConnection.java:267) at 
DBConnection.main(DBConnection.java:292) Caused by: 
com.datastax.driver.core.exceptions.WriteFailureException: Cassandra failure 
during write query at consistency LOCAL_QUORUM (2 responses were required but 
only 0 replica responded, 1 failed) at 
com.datastax.driver.core.exceptions.WriteFailureException.copy(WriteFailureException.java:91)
 at com.datastax.driver.core.Responses$Error.asException(Responses.java:119) at 
com.datastax.driver.core.DefaultResultSetFuture.onSet(DefaultResultSetFuture.java:180)
 at 
com.datastax.driver.core.RequestHandler.setFinalResult(RequestHandler.java:186) 
at com.datastax.driver.core.RequestHandler.access$2300(RequestHandler.java:44) 
at 
com.datastax.driver.core.RequestHandler$SpeculativeExecution.setFinalResult(RequestHandler.java:754)
 at 
com.datastax.driver.core.RequestHandler$SpeculativeExecution.onSet(RequestHandler.java:576)

It would be great if someone helps me out from this situation. Thanks
 


  was:
While I am writing large column into Cassandra table I am facing following 
exception.Even All nodes are up.

com.datastax.driver.core.exceptions.WriteFailureException: Cassandra failure 
during write query at consistency LOCAL_QUORUM (2 responses were required but 
only 0 replica responded, 1 failed)
at 
com.datastax.driver.core.exceptions.WriteFailureException.copy(WriteFailureException.java:80)
at 
com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
at 
com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:245)
at 
com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:55)
at 
com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:39)
at DBConnection.oracle2Cassandra(DBConnection.java:267)
at DBConnection.main(DBConnection.java:292)
Caused by: com.datastax.driver.core.exceptions.WriteFailureException: Cassandra 
failure during write query at consistency LOCAL_QUORUM (2 responses were 
required but only 0 replica responded, 1 failed)
at 
com.datastax.driver.core.exceptions.WriteFailureException.copy(WriteFailureException.java:91)
at 
com.datastax.driver.core.Responses$Error.asException(Responses.java:119)
at 
com.datastax.driver.core.DefaultResultSetFuture.onSet(DefaultResultSetFuture.java:180)
at 
com.datastax.driver.core.RequestHandler.setFinalResult(RequestHandler.java:186)
at 
com.datastax.driver.core.Connection$Dispatcher.channelRead0(Connection.java:1008)
at 
com.datastax.driver.core.Connection$Dispatcher.channelRead0(Connection.java:931)
at 
com.datastax.shaded.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
at 
com.datastax.shaded.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:254)
at 
com.datastax.shaded.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
at 
com.datastax.shaded.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
at 
com.datastax.shaded.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
at 
com.datastax.shaded.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
at 
com.datastax.shaded.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
at 
com.datastax.shaded.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
at 
com.datastax.shaded.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
at java.lang.Thread.run(Unknown Source)
Caused by: com.datastax.driver.core.exceptions.WriteFailureException: Cassandra 
failure during write 

[jira] [Commented] (CASSANDRA-11841) Add keep-alive to stream protocol

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11841:
-

* Updated patch to {{setRemoveOnCancelPolicy(true)}} on {{keepAliveExecutor}}. 
* Changed property to {{streaming_keep_alive_period_in_secs}} instead of 
milliseconds, since it doesn't make much sense to have subsecond keep-alive 
periods.
* Added {{NEWS.txt}} entries informing about the deprecation of 
{{streaming_socket_timeout_in_ms}} in favor of 
{{streaming_keep_alive_period_in_secs}}.
* Rebased patch and resubmitted tests

> Add keep-alive to stream protocol
> -
>
> Key: CASSANDRA-11841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11841
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>




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

[jira] [Updated] (CASSANDRA-12024) dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_copy_to_with_child_process_crashing

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-12024:

Assignee: Tyler Hobbs

> dtest failure in 
> cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_copy_to_with_child_process_crashing
> 
>
> Key: CASSANDRA-12024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12024
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Tyler Hobbs
>  Labels: dtest
> Attachments: node1.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/360/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_copy_to_with_child_process_crashing
> Failed on CassCI build cassandra-2.1_offheap_dtest #360
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/dtest.py", line 889, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2701, in test_copy_to_with_child_process_crashing
> self.assertIn('some records might be missing', err)
>   File "/usr/lib/python2.7/unittest/case.py", line 803, in assertIn
> self.fail(self._formatMessage(msg, standardMsg))
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> Error Message
> 'some records might be missing' not found in ''
> {code}
> Logs are attached.



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

[jira] [Updated] (CASSANDRA-12024) dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_copy_to_with_child_process_crashing

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-12024:

Assignee: Stefania  (was: Tyler Hobbs)

> dtest failure in 
> cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_copy_to_with_child_process_crashing
> 
>
> Key: CASSANDRA-12024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12024
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Stefania
>  Labels: dtest
> Attachments: node1.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/360/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_copy_to_with_child_process_crashing
> Failed on CassCI build cassandra-2.1_offheap_dtest #360
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/dtest.py", line 889, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2701, in test_copy_to_with_child_process_crashing
> self.assertIn('some records might be missing', err)
>   File "/usr/lib/python2.7/unittest/case.py", line 803, in assertIn
> self.fail(self._formatMessage(msg, standardMsg))
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> Error Message
> 'some records might be missing' not found in ''
> {code}
> Logs are attached.



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

[jira] [Updated] (CASSANDRA-12006) dtest failure in repair_tests.incremental_repair_test.TestIncRepair.sstable_repairedset_test

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-12006:

Assignee: Marcus Eriksson

> dtest failure in 
> repair_tests.incremental_repair_test.TestIncRepair.sstable_repairedset_test
> 
>
> Key: CASSANDRA-12006
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12006
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Marcus Eriksson
>  Labels: dtest
> Attachments: node1.log, node2.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/229/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_repairedset_test
> Failed on CassCI build cassandra-2.1_dtest_jdk8 #229
> Logs are attached.
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File 
> "/home/automaton/cassandra-dtest/repair_tests/incremental_repair_test.py", 
> line 226, in sstable_repairedset_test
> self.assertNotIn('Repaired at: 0', finaloutput)
>   File "/usr/lib/python2.7/unittest/case.py", line 810, in assertNotIn
> self.fail(self._formatMessage(msg, standardMsg))
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "'Repaired at: 0' unexpectedly found in 'No such file: 
> /mnt/tmp/dtest-DoN5MO/test/node1/data0/keyspace1/standard1-0d92e6402f7c11e6bac8356bf83fc3ce/keyspace1-standard1-ka-81-Data.db
> {code}



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

[jira] [Commented] (CASSANDRA-11991) On clock skew, paxos may "corrupt" the node clock

[Jason Brown (JIRA)]

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

Jason Brown commented on CASSANDRA-11991:
-

lgtm. The only minor nit I have is CASSANDRA-9649 made 
{{ClientState#lastTimestampMicros}} a static field. I believe this change 
helped accelerate the cluster get into a bad state wrt the propagation of bad 
timestamps. wdyt about switching it back to being an instance field (not 
static)?

> On clock skew, paxos may "corrupt" the node clock
> -
>
> Key: CASSANDRA-11991
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11991
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> W made a mistake in CASSANDRA-9649 so that a temporal clock skew on one node 
> can "corrupt" other node clocks through Paxos. That wasn't intended and we 
> should fix that. I'll attach a patch later.



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

[jira] [Updated] (CASSANDRA-11991) On clock skew, paxos may "corrupt" the node clock

[sankalp kohli (JIRA)]

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

sankalp kohli updated CASSANDRA-11991:
--
Reviewer: Jason Brown  (was: sankalp kohli)

> On clock skew, paxos may "corrupt" the node clock
> -
>
> Key: CASSANDRA-11991
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11991
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> W made a mistake in CASSANDRA-9649 so that a temporal clock skew on one node 
> can "corrupt" other node clocks through Paxos. That wasn't intended and we 
> should fix that. I'll attach a patch later.



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

[jira] [Commented] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan commented on CASSANDRA-10786:
-

In a tick tick world I don't see the reason for putting stuff in that people 
can't use.

> Include hash of result set metadata in prepared statement id
> 
>
> Key: CASSANDRA-10786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10786
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Olivier Michallat
>Assignee: Alex Petrov
>Priority: Minor
>  Labels: client-impacting, doc-impacting, protocolv5
> Fix For: 3.x
>
>
> This is a follow-up to CASSANDRA-7910, which was about invalidating a 
> prepared statement when the table is altered, to force clients to update 
> their local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host. 
> The first client to execute the query after the cache was invalidated will 
> receive an UNPREPARED response, re-prepare, and update its local metadata. 
> But other clients might miss it entirely (the MD5 hasn't changed), and they 
> will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, 
> clientA and clientB both have a cache of the metadata (columns b and c) 
> locally
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, 
> re-prepares on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*’s cache again, with the same md5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has been 
> populated again, the query succeeds. But clientB still has not updated its 
> metadata, it’s still (b,c)
> One solution that was suggested is to include a hash of the result set 
> metadata in the md5. This way the md5 would change at step 3, and any client 
> using the old md5 would get an UNPREPARED, regardless of whether another 
> client already reprepared.



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

[jira] [Commented] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan commented on CASSANDRA-10786:
-

Who says drivers will skip it?  I think this is a pain point for most drivers 
and they would probably implement it, but they don't have to.

> Include hash of result set metadata in prepared statement id
> 
>
> Key: CASSANDRA-10786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10786
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Olivier Michallat
>Assignee: Alex Petrov
>Priority: Minor
>  Labels: client-impacting, doc-impacting, protocolv5
> Fix For: 3.x
>
>
> This is a follow-up to CASSANDRA-7910, which was about invalidating a 
> prepared statement when the table is altered, to force clients to update 
> their local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host. 
> The first client to execute the query after the cache was invalidated will 
> receive an UNPREPARED response, re-prepare, and update its local metadata. 
> But other clients might miss it entirely (the MD5 hasn't changed), and they 
> will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, 
> clientA and clientB both have a cache of the metadata (columns b and c) 
> locally
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, 
> re-prepares on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*’s cache again, with the same md5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has been 
> populated again, the query succeeds. But clientB still has not updated its 
> metadata, it’s still (b,c)
> One solution that was suggested is to include a hash of the result set 
> metadata in the md5. This way the md5 would change at step 3, and any client 
> using the old md5 would get an UNPREPARED, regardless of whether another 
> client already reprepared.



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

[jira] [Commented] (CASSANDRA-12045) Cassandra failure during write query at consistency LOCAL_QUORUM

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-12045:
-

There should be a corresponding exception in the logs of the replica nodes.  
Can you check for that and paste it here?

>  Cassandra failure during write query at consistency LOCAL_QUORUM 
> --
>
> Key: CASSANDRA-12045
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12045
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL, Local Write-Read Paths
> Environment: Eclipse java environment
>Reporter: Raghavendra Pinninti
> Fix For: 3.x
>
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
> While I am writing large column into Cassandra table I am facing following 
> exception.Even All nodes are up.
> com.datastax.driver.core.exceptions.WriteFailureException: Cassandra failure 
> during write query at consistency LOCAL_QUORUM (2 responses were required but 
> only 0 replica responded, 1 failed)
>   at 
> com.datastax.driver.core.exceptions.WriteFailureException.copy(WriteFailureException.java:80)
>   at 
> com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
>   at 
> com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:245)
>   at 
> com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:55)
>   at 
> com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:39)
>   at DBConnection.oracle2Cassandra(DBConnection.java:267)
>   at DBConnection.main(DBConnection.java:292)
> Caused by: com.datastax.driver.core.exceptions.WriteFailureException: 
> Cassandra failure during write query at consistency LOCAL_QUORUM (2 responses 
> were required but only 0 replica responded, 1 failed)
>   at 
> com.datastax.driver.core.exceptions.WriteFailureException.copy(WriteFailureException.java:91)
>   at 
> com.datastax.driver.core.Responses$Error.asException(Responses.java:119)
>   at 
> com.datastax.driver.core.DefaultResultSetFuture.onSet(DefaultResultSetFuture.java:180)
>   at 
> com.datastax.driver.core.RequestHandler.setFinalResult(RequestHandler.java:186)
>   at 
> com.datastax.driver.core.Connection$Dispatcher.channelRead0(Connection.java:1008)
>   at 
> com.datastax.driver.core.Connection$Dispatcher.channelRead0(Connection.java:931)
>   at 
> com.datastax.shaded.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
>   at 
> com.datastax.shaded.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:254)
>   at 
> com.datastax.shaded.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
>   at 
> com.datastax.shaded.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
>   at 
> com.datastax.shaded.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
>   at 
> com.datastax.shaded.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:339)
>   at 
> com.datastax.shaded.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:324)
>   at 
> com.datastax.shaded.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:847)
>   at 
> com.datastax.shaded.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
> at java.lang.Thread.run(Unknown Source)
> Caused by: com.datastax.driver.core.exceptions.WriteFailureException: 
> Cassandra failure during write query at consistency LOCAL_QUORUM (2 responses 
> were required but only 0 replica responded, 1 failed)
>   at com.datastax.driver.core.Responses$Error$1.decode(Responses.java:76)
>   at com.datastax.driver.core.Responses$Error$1.decode(Responses.java:40)c
>   at 
> com.datastax.driver.core.Message$ProtocolDecoder.decode(Message.java:243)
>   at 
> com.datastax.driver.core.Message$ProtocolDecoder.decode(Message.java:225)
>   at 
> com.datastax.shaded.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
>   ... 13 more
> Would someone please help me out from this situation



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

[jira] [Updated] (CASSANDRA-12035) Structure for tpstats output (JSON, YAML)

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-12035:

Assignee: Hiroyuki Nishi

> Structure for tpstats output (JSON, YAML)
> -
>
> Key: CASSANDRA-12035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12035
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tools
>Reporter: Hiroyuki Nishi
>Assignee: Hiroyuki Nishi
>Priority: Minor
> Attachments: CASSANDRA-12035-trunk.patch, 
> tablestats_sample_result.json, tablestats_sample_result.txt, 
> tablestats_sample_result.yaml, tpstats_sample_result.json, 
> tpstats_sample_result.txt, tpstats_sample_result.yaml
>
>
> In CASSANDRA-5977, some extra output formats such as JSON and YAML were added 
> for nodetool tablestats. 
> Similarly, I would like to add the output formats in nodetool tpstats.
> Also, I tried to refactor the tablestats's code about the output formats to 
> integrate the existing code with my code.
> Please review the attached patch.



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

[jira] [Commented] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-10786:
-

What's the advantage of releasing a v5 that we expect most drivers to skip?

To clarify, I'm saying that we can have v5 in progress across multiple 
releases, and those v5 features simply won't be accessible to users/drivers 
until it's complete.

> Include hash of result set metadata in prepared statement id
> 
>
> Key: CASSANDRA-10786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10786
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Olivier Michallat
>Assignee: Alex Petrov
>Priority: Minor
>  Labels: client-impacting, doc-impacting, protocolv5
> Fix For: 3.x
>
>
> This is a follow-up to CASSANDRA-7910, which was about invalidating a 
> prepared statement when the table is altered, to force clients to update 
> their local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host. 
> The first client to execute the query after the cache was invalidated will 
> receive an UNPREPARED response, re-prepare, and update its local metadata. 
> But other clients might miss it entirely (the MD5 hasn't changed), and they 
> will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, 
> clientA and clientB both have a cache of the metadata (columns b and c) 
> locally
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, 
> re-prepares on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*’s cache again, with the same md5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has been 
> populated again, the query succeeds. But clientB still has not updated its 
> metadata, it’s still (b,c)
> One solution that was suggested is to include a hash of the result set 
> metadata in the md5. This way the md5 would change at step 3, and any client 
> using the old md5 would get an UNPREPARED, regardless of whether another 
> client already reprepared.



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

[jira] [Updated] (CASSANDRA-12053) ONE != LOCAL_ONE for SimpleStrategy

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan updated CASSANDRA-12053:

Reproduced In: 3.0.7

> ONE != LOCAL_ONE for SimpleStrategy
> ---
>
> Key: CASSANDRA-12053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12053
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Nick Bailey
> Fix For: 3.0.x, 3.x
>
>
> Currently our consistency level code doesn't account for SimpleStrategy if 
> you are using a topology enabled snitch. In a 2 dc cluster using GPFS and a 
> keyspace using SimpleStrategy, you can get UnavailableException when all 
> nodes are up simply based on which datacenter you query while using LOCAL_ONE 
> or LOCAL_QUORUM consistency levels.



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

[jira] [Updated] (CASSANDRA-12053) ONE != LOCAL_ONE for SimpleStrategy

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan updated CASSANDRA-12053:

Fix Version/s: 3.x
   3.0.x

> ONE != LOCAL_ONE for SimpleStrategy
> ---
>
> Key: CASSANDRA-12053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12053
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Nick Bailey
> Fix For: 3.0.x, 3.x
>
>
> Currently our consistency level code doesn't account for SimpleStrategy if 
> you are using a topology enabled snitch. In a 2 dc cluster using GPFS and a 
> keyspace using SimpleStrategy, you can get UnavailableException when all 
> nodes are up simply based on which datacenter you query while using LOCAL_ONE 
> or LOCAL_QUORUM consistency levels.



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

[jira] [Created] (CASSANDRA-12053) ONE != LOCAL_ONE for SimpleStrategy

[Nick Bailey (JIRA)]

Nick Bailey created CASSANDRA-12053:
---

 Summary: ONE != LOCAL_ONE for SimpleStrategy
 Key: CASSANDRA-12053
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12053
 Project: Cassandra
  Issue Type: Bug
Reporter: Nick Bailey


Currently our consistency level code doesn't account for SimpleStrategy if you 
are using a topology enabled snitch. In a 2 dc cluster using GPFS and a 
keyspace using SimpleStrategy, you can get UnavailableException when all nodes 
are up simply based on which datacenter you query while using LOCAL_ONE or 
LOCAL_QUORUM consistency levels.



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

[jira] [Commented] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id

[Jeremiah Jordan (JIRA)]

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

Jeremiah Jordan commented on CASSANDRA-10786:
-

bq. We probably want to wait for some of those other features before finalizing 
the v5 protocol.

If we are going to put this in, I think it makes more sense to call this v5, 
and what ever the next changes we make are v6.  Drivers can still talk v4 and 
they could skip v5 to v6 if they wanted to wait for more feature before 
implementing.

> Include hash of result set metadata in prepared statement id
> 
>
> Key: CASSANDRA-10786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10786
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Olivier Michallat
>Assignee: Alex Petrov
>Priority: Minor
>  Labels: client-impacting, doc-impacting, protocolv5
> Fix For: 3.x
>
>
> This is a follow-up to CASSANDRA-7910, which was about invalidating a 
> prepared statement when the table is altered, to force clients to update 
> their local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host. 
> The first client to execute the query after the cache was invalidated will 
> receive an UNPREPARED response, re-prepare, and update its local metadata. 
> But other clients might miss it entirely (the MD5 hasn't changed), and they 
> will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, 
> clientA and clientB both have a cache of the metadata (columns b and c) 
> locally
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, 
> re-prepares on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*’s cache again, with the same md5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has been 
> populated again, the query succeeds. But clientB still has not updated its 
> metadata, it’s still (b,c)
> One solution that was suggested is to include a hash of the result set 
> metadata in the md5. This way the md5 would change at step 3, and any client 
> using the old md5 would get an UNPREPARED, regardless of whether another 
> client already reprepared.



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

[jira] [Commented] (CASSANDRA-12016) Create MessagingService mocking classes

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-12016:
-

This seems like a good start to making this part of the codebase more testable, 
thanks.

To warrant committing this type of mini-testing-framework, we should have at 
least a few good use cases for tests implemented.  The hints test you linked is 
a nice example.  Did you have anything else in mind that might be a good fit 
for this?

> Create MessagingService mocking classes
> ---
>
> Key: CASSANDRA-12016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12016
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Testing
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>
> Interactions between clients and nodes in the cluster are taking place by 
> exchanging messages through the {{MessagingService}}. Black box testing for 
> message based systems is usually pretty easy, as we're just dealing with 
> messages in/out. My suggestion would be to add tests that make use of this 
> fact by mocking message exchanges via MessagingService. Given the right use 
> case, this would turn out to be a much simpler and more efficient alternative 
> for dtests.



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

[jira] [Updated] (CASSANDRA-12006) dtest failure in repair_tests.incremental_repair_test.TestIncRepair.sstable_repairedset_test

[Sean McCarthy (JIRA)]

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

Sean McCarthy updated CASSANDRA-12006:
--
Assignee: (was: Sean McCarthy)

> dtest failure in 
> repair_tests.incremental_repair_test.TestIncRepair.sstable_repairedset_test
> 
>
> Key: CASSANDRA-12006
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12006
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>  Labels: dtest
> Attachments: node1.log, node2.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/229/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_repairedset_test
> Failed on CassCI build cassandra-2.1_dtest_jdk8 #229
> Logs are attached.
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File 
> "/home/automaton/cassandra-dtest/repair_tests/incremental_repair_test.py", 
> line 226, in sstable_repairedset_test
> self.assertNotIn('Repaired at: 0', finaloutput)
>   File "/usr/lib/python2.7/unittest/case.py", line 810, in assertNotIn
> self.fail(self._formatMessage(msg, standardMsg))
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "'Repaired at: 0' unexpectedly found in 'No such file: 
> /mnt/tmp/dtest-DoN5MO/test/node1/data0/keyspace1/standard1-0d92e6402f7c11e6bac8356bf83fc3ce/keyspace1-standard1-ka-81-Data.db
> {code}



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

[jira] [Updated] (CASSANDRA-12006) dtest failure in repair_tests.incremental_repair_test.TestIncRepair.sstable_repairedset_test

[Sean McCarthy (JIRA)]

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

Sean McCarthy updated CASSANDRA-12006:
--
Issue Type: Bug  (was: Test)

> dtest failure in 
> repair_tests.incremental_repair_test.TestIncRepair.sstable_repairedset_test
> 
>
> Key: CASSANDRA-12006
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12006
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>  Labels: dtest
> Attachments: node1.log, node2.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/229/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_repairedset_test
> Failed on CassCI build cassandra-2.1_dtest_jdk8 #229
> Logs are attached.
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File 
> "/home/automaton/cassandra-dtest/repair_tests/incremental_repair_test.py", 
> line 226, in sstable_repairedset_test
> self.assertNotIn('Repaired at: 0', finaloutput)
>   File "/usr/lib/python2.7/unittest/case.py", line 810, in assertNotIn
> self.fail(self._formatMessage(msg, standardMsg))
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "'Repaired at: 0' unexpectedly found in 'No such file: 
> /mnt/tmp/dtest-DoN5MO/test/node1/data0/keyspace1/standard1-0d92e6402f7c11e6bac8356bf83fc3ce/keyspace1-standard1-ka-81-Data.db
> {code}



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

[jira] [Commented] (CASSANDRA-12006) dtest failure in repair_tests.incremental_repair_test.TestIncRepair.sstable_repairedset_test

[Sean McCarthy (JIRA)]

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

Sean McCarthy commented on CASSANDRA-12006:
---

In the logs the repair seems to succeed, yet the sstable is still unrepaired.

> dtest failure in 
> repair_tests.incremental_repair_test.TestIncRepair.sstable_repairedset_test
> 
>
> Key: CASSANDRA-12006
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12006
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Sean McCarthy
>  Labels: dtest
> Attachments: node1.log, node2.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/229/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_repairedset_test
> Failed on CassCI build cassandra-2.1_dtest_jdk8 #229
> Logs are attached.
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File 
> "/home/automaton/cassandra-dtest/repair_tests/incremental_repair_test.py", 
> line 226, in sstable_repairedset_test
> self.assertNotIn('Repaired at: 0', finaloutput)
>   File "/usr/lib/python2.7/unittest/case.py", line 810, in assertNotIn
> self.fail(self._formatMessage(msg, standardMsg))
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "'Repaired at: 0' unexpectedly found in 'No such file: 
> /mnt/tmp/dtest-DoN5MO/test/node1/data0/keyspace1/standard1-0d92e6402f7c11e6bac8356bf83fc3ce/keyspace1-standard1-ka-81-Data.db
> {code}



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

[jira] [Updated] (CASSANDRA-12016) Create MessagingService mocking classes

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-12016:

Reviewer: Tyler Hobbs

> Create MessagingService mocking classes
> ---
>
> Key: CASSANDRA-12016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12016
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Testing
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
>
> Interactions between clients and nodes in the cluster are taking place by 
> exchanging messages through the {{MessagingService}}. Black box testing for 
> message based systems is usually pretty easy, as we're just dealing with 
> messages in/out. My suggestion would be to add tests that make use of this 
> fact by mocking message exchanges via MessagingService. Given the right use 
> case, this would turn out to be a much simpler and more efficient alternative 
> for dtests.



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

[jira] [Assigned] (CASSANDRA-11516) Make max number of streams configurable

[Giampaolo (JIRA)]

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

Giampaolo reassigned CASSANDRA-11516:
-

Assignee: Giampaolo

> Make max number of streams configurable
> ---
>
> Key: CASSANDRA-11516
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11516
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Sebastian Estevez
>Assignee: Giampaolo
>  Labels: lhf
>
> Today we default to num cores. In large boxes (many cores), this is 
> suboptimal as it can generate huge amounts of garbage that GC can't keep up 
> with.
> Usually we tackle issues like this with the streaming throughput levers but 
> in this case the problem is CPU consumption by StreamReceiverTasks 
> specifically in the IntervalTree build -- 
> https://github.com/apache/cassandra/blob/cassandra-2.1.12/src/java/org/apache/cassandra/utils/IntervalTree.java#L257
> We need a max number of parallel streams lever to hanlde this.



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

[jira] [Commented] (CASSANDRA-10786) Include hash of result set metadata in prepared statement id

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-10786:
-

bq. We (java driver team) discussed this and we agree with taking the approach 
we've previously taken, we can do a separate branch with this change, build a 
jar and include it with C* (in the lib/ directory as currently done). We'll do 
some extra validation to make sure everything is good from the driver side. 
After a driver has been formally released with those changes, we would want to 
update C* to use that.

That sounds good to me.

bq. What is the timeline of this change? Will it be in 3.8 or 3.10?

This might be included in 3.8, but...

bq. Will this be the only change in for protocol v5 or will some of the tickets 
in CASSANDRA-9362 be included as well?

We probably want to wait for some of those other features before finalizing the 
v5 protocol.  However, we can release with some of the v5 features implemented 
without actually allowing v5 connections to be made.  For testing, we can use a 
special flag to allow v5 connections.  With that in mind, I don't necessarily 
think we should make v5 whatever ends up in 3.8 -- we should get in the 
features we really care about and finalize v5 in whatever C* release that 
happens to be.

[~slebresne] what do you think of the above? Is there anything in 
CASSANDRA-9362 that you would particularly like to get into the v5 protocol?

> Include hash of result set metadata in prepared statement id
> 
>
> Key: CASSANDRA-10786
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10786
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
>Reporter: Olivier Michallat
>Assignee: Alex Petrov
>Priority: Minor
>  Labels: client-impacting, doc-impacting, protocolv5
> Fix For: 3.x
>
>
> This is a follow-up to CASSANDRA-7910, which was about invalidating a 
> prepared statement when the table is altered, to force clients to update 
> their local copy of the metadata.
> There's still an issue if multiple clients are connected to the same host. 
> The first client to execute the query after the cache was invalidated will 
> receive an UNPREPARED response, re-prepare, and update its local metadata. 
> But other clients might miss it entirely (the MD5 hasn't changed), and they 
> will keep using their old metadata. For example:
> # {{SELECT * ...}} statement is prepared in Cassandra with md5 abc123, 
> clientA and clientB both have a cache of the metadata (columns b and c) 
> locally
> # column a gets added to the table, C* invalidates its cache entry
> # clientA sends an EXECUTE request for md5 abc123, gets UNPREPARED response, 
> re-prepares on the fly and updates its local metadata to (a, b, c)
> # prepared statement is now in C*’s cache again, with the same md5 abc123
> # clientB sends an EXECUTE request for id abc123. Because the cache has been 
> populated again, the query succeeds. But clientB still has not updated its 
> metadata, it’s still (b,c)
> One solution that was suggested is to include a hash of the result set 
> metadata in the md5. This way the md5 would change at step 3, and any client 
> using the old md5 would get an UNPREPARED, regardless of whether another 
> client already reprepared.



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

[jira] [Updated] (CASSANDRA-12024) dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_copy_to_with_child_process_crashing

[Sean McCarthy (JIRA)]

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

Sean McCarthy updated CASSANDRA-12024:
--
Issue Type: Bug  (was: Test)

> dtest failure in 
> cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_copy_to_with_child_process_crashing
> 
>
> Key: CASSANDRA-12024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12024
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>  Labels: dtest
> Attachments: node1.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/360/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_copy_to_with_child_process_crashing
> Failed on CassCI build cassandra-2.1_offheap_dtest #360
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/dtest.py", line 889, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2701, in test_copy_to_with_child_process_crashing
> self.assertIn('some records might be missing', err)
>   File "/usr/lib/python2.7/unittest/case.py", line 803, in assertIn
> self.fail(self._formatMessage(msg, standardMsg))
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> Error Message
> 'some records might be missing' not found in ''
> {code}
> Logs are attached.



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

[jira] [Updated] (CASSANDRA-12024) dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_copy_to_with_child_process_crashing

[Sean McCarthy (JIRA)]

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

Sean McCarthy updated CASSANDRA-12024:
--
Assignee: (was: Sean McCarthy)

> dtest failure in 
> cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_copy_to_with_child_process_crashing
> 
>
> Key: CASSANDRA-12024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12024
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>  Labels: dtest
> Attachments: node1.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/360/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_copy_to_with_child_process_crashing
> Failed on CassCI build cassandra-2.1_offheap_dtest #360
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/dtest.py", line 889, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2701, in test_copy_to_with_child_process_crashing
> self.assertIn('some records might be missing', err)
>   File "/usr/lib/python2.7/unittest/case.py", line 803, in assertIn
> self.fail(self._formatMessage(msg, standardMsg))
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> Error Message
> 'some records might be missing' not found in ''
> {code}
> Logs are attached.



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

[jira] [Commented] (CASSANDRA-11928) dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs commented on CASSANDRA-11928:
-

Hmm, I tried this out and blocking on tracing in the write path seems to result 
in some sort of deadlock.  Since this test has only flapped once in a hundred 
runs, I'm not sure how much effort we want to invest in this right now.

> dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test
> 
>
> Key: CASSANDRA-11928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11928
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Craig Kodman
>Assignee: Tyler Hobbs
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_dtest/727/testReport/cql_tracing_test/TestCqlTracing/tracing_simple_test
> Failed on CassCI build cassandra-3.0_dtest #727
> Is it a problem that the tracing message with the query is missing?



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

[jira] [Commented] (CASSANDRA-11744) Trying to restart a 2.2.5 node, nodetool disablethrift fails

[Peter Norton (JIRA)]

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

Peter Norton commented on CASSANDRA-11744:
--

This happened again on 2.2.6 today.

> Trying to restart a 2.2.5 node, nodetool disablethrift fails
> 
>
> Key: CASSANDRA-11744
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11744
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Peter Norton
> Attachments: failure.jstack.out
>
>
> We have a 2.2.5 cluster running in AWS VPC with EBS volumes.  Earlier today 3 
> nodes seem to have gone into a bad state - clients were seeing high latencies 
> when writing to these nodes, and the write to the commitlog on each of these 
> nodes seemed high - more than the relatively low number of iops that AWS 
> allocated to these volumes.  While trying to understand the situation we 
> attempted to restart the 3 nodes.  We attempted to do a nodetool 
> disablebinary; nodetool disablethrift; nodetool flush. and then stop the 
> process.
> When trying to disablethrift, the following stack trace appeared in the 
> system.log:
> ```
> INFO  [RMI TCP Connection(8)-172.26.32.248] 2016-05-10 15:26:58,599 
> Server.java:218 - Stop listening for CQL clients
> INFO  [RMI TCP Connection(10)-172.26.32.248] 2016-05-10 15:27:01,975 
> ThriftServer.java:142 - Stop listening to thrift clients
> ERROR [RPC-Thread:34] 2016-05-10 15:27:03,794 Message.java:324 - Unexpected 
> throwable while invoking!
> java.lang.NullPointerException: null
> at com.thinkaurelius.thrift.util.mem.Buffer.size(Buffer.java:83) 
> ~[thrift-server-0.3.7.jar:na]
> at 
> com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.expand(FastMemoryOutputTransport.java:84)
>  ~[thrift-server-0.3.7.jar:na]
> at 
> com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.write(FastMemoryOutputTransport.java:167)
>  ~[thrift-server-0.3.7.jar:na]
> at 
> org.apache.thrift.transport.TFramedTransport.flush(TFramedTransport.java:156) 
> ~[libthrift-0.9.2.jar:0.9.2]
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:55) 
> ~[libthrift-0.9.2.jar:0.9.2]
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39) 
> ~[libthrift-0.9.2.jar:0.9.2]
> at com.thinkaurelius.thrift.Message.invoke(Message.java:314) 
> ~[thrift-server-0.3.7.jar:na]
> at 
> com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90) 
> [thrift-server-0.3.7.jar:na]
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:695)
>  [thrift-server-0.3.7.jar:na]
> at 
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:689)
>  [thrift-server-0.3.7.jar:na]
> at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112) 
> [disruptor-3.0.1.jar:na]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_60]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> ```
> The attached jstack was taken from a node after the above was noticed.



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

[jira] [Updated] (CASSANDRA-12030) Range tombstones that are masked by row tombstones should not be written out

[Nachiket Patil (JIRA)]

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

Nachiket Patil updated CASSANDRA-12030:
---
Attachment: cassandra-12030-2.2.diff
cassandra-12030-2.1.diff

> Range tombstones that are masked by row tombstones should not be written out
> 
>
> Key: CASSANDRA-12030
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12030
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Nachiket Patil
>Assignee: Nachiket Patil
>Priority: Minor
> Attachments: cassandra-12030-2.1.diff, cassandra-12030-2.2.diff
>
>
> During compaction, if a table has range tombstone and a row delete with 
> higher timestamp than range tombstone, both are written out to disk. Some 
> problems seen because of this behavior:
> 1. The Range tombstone is expensive to maintain.
> 2. Range queries see timeouts when there are too many range tombstones 
> present which may be masked by row tombstones.
> This can be avoided with simple optimization to not write out range tombstone 
> if it is masked by row delete.



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

[jira] [Commented] (CASSANDRA-9507) range metrics are not updated for timeout and unavailable in StorageProxy

[Nachiket Patil (JIRA)]

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

Nachiket Patil commented on CASSANDRA-9507:
---

Thanks Benjamin for the feedback. I have attached new diffs one for v2.x and 
another for v 3.0 and trunk.

> range metrics are not updated for timeout and unavailable in StorageProxy
> -
>
> Key: CASSANDRA-9507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9507
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability
>Reporter: sankalp kohli
>Assignee: Nachiket Patil
>Priority: Minor
> Attachments: CASSANDRA-9507 v2.X.diff, CASSANDRA-9507 v3.0-trunk.diff
>
>
> Looking at the code, it looks like range metrics are not updated for timeouts 
> and unavailable. 



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

[jira] [Updated] (CASSANDRA-9507) range metrics are not updated for timeout and unavailable in StorageProxy

[Nachiket Patil (JIRA)]

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

Nachiket Patil updated CASSANDRA-9507:
--
Attachment: (was: Cassandra-9507.diff)

> range metrics are not updated for timeout and unavailable in StorageProxy
> -
>
> Key: CASSANDRA-9507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9507
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability
>Reporter: sankalp kohli
>Assignee: Nachiket Patil
>Priority: Minor
> Attachments: CASSANDRA-9507 v2.X.diff, CASSANDRA-9507 v3.0-trunk.diff
>
>
> Looking at the code, it looks like range metrics are not updated for timeouts 
> and unavailable. 



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

[jira] [Updated] (CASSANDRA-9507) range metrics are not updated for timeout and unavailable in StorageProxy

[Nachiket Patil (JIRA)]

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

Nachiket Patil updated CASSANDRA-9507:
--
Attachment: CASSANDRA-9507 v3.0-trunk.diff
CASSANDRA-9507 v2.X.diff

> range metrics are not updated for timeout and unavailable in StorageProxy
> -
>
> Key: CASSANDRA-9507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9507
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability
>Reporter: sankalp kohli
>Assignee: Nachiket Patil
>Priority: Minor
> Attachments: CASSANDRA-9507 v2.X.diff, CASSANDRA-9507 v3.0-trunk.diff
>
>
> Looking at the code, it looks like range metrics are not updated for timeouts 
> and unavailable. 



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

[jira] [Commented] (CASSANDRA-12024) dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_copy_to_with_child_process_crashing

[Philip Thompson (JIRA)]

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

Philip Thompson commented on CASSANDRA-12024:
-

Yes, looks suspicious

> dtest failure in 
> cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_copy_to_with_child_process_crashing
> 
>
> Key: CASSANDRA-12024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12024
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Sean McCarthy
>  Labels: dtest
> Attachments: node1.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/360/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_copy_to_with_child_process_crashing
> Failed on CassCI build cassandra-2.1_offheap_dtest #360
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/dtest.py", line 889, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2701, in test_copy_to_with_child_process_crashing
> self.assertIn('some records might be missing', err)
>   File "/usr/lib/python2.7/unittest/case.py", line 803, in assertIn
> self.fail(self._formatMessage(msg, standardMsg))
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> Error Message
> 'some records might be missing' not found in ''
> {code}
> Logs are attached.



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

[jira] [Updated] (CASSANDRA-11957) Implement seek() of org.apache.cassandra.db.commitlog.EncryptedFileSegmentInputStream

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11957:

   Resolution: Fixed
Fix Version/s: (was: 3.x)
   3.8
   Status: Resolved  (was: Ready to Commit)

Tidied up some formatting and comments on 
[commit|https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=9343bd4070d69f9c1558656deccfd8e3692c2c80].

Thanks for the patch!

> Implement seek() of 
> org.apache.cassandra.db.commitlog.EncryptedFileSegmentInputStream 
> --
>
> Key: CASSANDRA-11957
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11957
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Coordination, Local Write-Read Paths
>Reporter: Imran Chaudhry
>Assignee: Imran Chaudhry
>Priority: Critical
> Fix For: 3.8
>
> Attachments: 11957-trunk.txt
>
>
> CDC needs the seek() method of 
> org.apache.cassandra.db.commitlog.EncryptedFileSegmentInputStream implemented 
> (currently throws an exception.)
> CommitLogs are read using this stream and the seek() method needs to be 
> implemented so that mutations which are appended to the currently active 
> commitlog can be read out in realtime.
>  
> Current implementation is:
>   
> public void seek(long position)
> {
> // implement this when we actually need it
> throw new UnsupportedOperationException();
> }



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

[jira] [Updated] (CASSANDRA-11957) Implement seek() of org.apache.cassandra.db.commitlog.EncryptedFileSegmentInputStream

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11957:

Status: Ready to Commit  (was: Patch Available)

> Implement seek() of 
> org.apache.cassandra.db.commitlog.EncryptedFileSegmentInputStream 
> --
>
> Key: CASSANDRA-11957
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11957
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Coordination, Local Write-Read Paths
>Reporter: Imran Chaudhry
>Assignee: Imran Chaudhry
>Priority: Critical
> Fix For: 3.x
>
> Attachments: 11957-trunk.txt
>
>
> CDC needs the seek() method of 
> org.apache.cassandra.db.commitlog.EncryptedFileSegmentInputStream implemented 
> (currently throws an exception.)
> CommitLogs are read using this stream and the seek() method needs to be 
> implemented so that mutations which are appended to the currently active 
> commitlog can be read out in realtime.
>  
> Current implementation is:
>   
> public void seek(long position)
> {
> // implement this when we actually need it
> throw new UnsupportedOperationException();
> }



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

cassandra git commit: Implement / integrate FileSegmentInputStream.seek() into CommitLogReader

[jmckenzie]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 6a7985d87 -> 9343bd407


Implement / integrate FileSegmentInputStream.seek() into CommitLogReader

Patch by ichaudhry; reviewed by jmckenzie for CASSANDRA-11957


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

Branch: refs/heads/trunk
Commit: 9343bd4070d69f9c1558656deccfd8e3692c2c80
Parents: 6a7985d
Author: Imran Chaudhry 
Authored: Tue Jun 21 13:20:32 2016 -0400
Committer: Josh McKenzie 
Committed: Tue Jun 21 15:48:00 2016 -0400

--
 CHANGES.txt |  1 +
 .../cassandra/db/commitlog/CommitLogReader.java |  6 ++-
 .../EncryptedFileSegmentInputStream.java| 21 ++--
 .../db/commitlog/SegmentReaderTest.java | 56 ++--
 4 files changed, 75 insertions(+), 9 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9343bd40/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index f3fc2ca..0695654 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 3.8
+ * Support seek() in EncryptedFileSegmentInputStream (CASSANDRA-11957)
  * SSTable tools mishandling LocalPartitioner (CASSANDRA-12002)
  * When SEPWorker assigned work, set thread name to match pool 
(CASSANDRA-11966)
  * Add cross-DC latency metrics (CASSANDRA-11596)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9343bd40/src/java/org/apache/cassandra/db/commitlog/CommitLogReader.java
--
diff --git a/src/java/org/apache/cassandra/db/commitlog/CommitLogReader.java 
b/src/java/org/apache/cassandra/db/commitlog/CommitLogReader.java
index 6c4bb60..a914cc9 100644
--- a/src/java/org/apache/cassandra/db/commitlog/CommitLogReader.java
+++ b/src/java/org/apache/cassandra/db/commitlog/CommitLogReader.java
@@ -199,8 +199,6 @@ public class CommitLogReader
 
 statusTracker.errorContext = String.format("Next section 
at %d in %s", syncSegment.fileStartPosition, desc.fileName());
 
-// TODO: Since EncryptedFileSegmentInputStream doesn't 
implement seek(), we cannot pre-emptively seek
-// to the desired offset in the syncSegment before reading 
the section and deserializing the mutations.
 readSection(handler, syncSegment.input, minPosition, 
syncSegment.endPosition, statusTracker, desc);
 if (!statusTracker.shouldContinue())
 break;
@@ -254,6 +252,10 @@ public class CommitLogReader
  ReadStatusTracker statusTracker,
  CommitLogDescriptor desc) throws IOException
 {
+// seek rather than deserializing mutation-by-mutation to reach the 
desired minPosition in this SyncSegment
+if (desc.id == minPosition.segmentId && reader.getFilePointer() < 
minPosition.position)
+reader.seek(minPosition.position);
+
 while (statusTracker.shouldContinue() && reader.getFilePointer() < end 
&& !reader.isEOF())
 {
 long mutationStart = reader.getFilePointer();

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9343bd40/src/java/org/apache/cassandra/db/commitlog/EncryptedFileSegmentInputStream.java
--
diff --git 
a/src/java/org/apache/cassandra/db/commitlog/EncryptedFileSegmentInputStream.java
 
b/src/java/org/apache/cassandra/db/commitlog/EncryptedFileSegmentInputStream.java
index cd7f7cb..9da3d50 100644
--- 
a/src/java/org/apache/cassandra/db/commitlog/EncryptedFileSegmentInputStream.java
+++ 
b/src/java/org/apache/cassandra/db/commitlog/EncryptedFileSegmentInputStream.java
@@ -38,7 +38,7 @@ public class EncryptedFileSegmentInputStream extends 
FileSegmentInputStream impl
 private final ChunkProvider chunkProvider;
 
 /**
- * offset the decrypted chunks already processed in this segment.
+ * Offset representing the decrypted chunks already processed in this 
segment.
  */
 private int totalChunkOffset;
 
@@ -76,8 +76,23 @@ public class EncryptedFileSegmentInputStream extends 
FileSegmentInputStream impl
 
 public void seek(long position)
 {
-// implement this when we actually need it
-throw new UnsupportedOperationException();
+long bufferPos = position - totalChunkOffset - segmentOffset;
+while (buffer != null && bufferPos > buffer.capacity())
+{
+// rebuffer repeatedly until we have reached desired position
+  

[jira] [Updated] (CASSANDRA-11755) nodetool info should run with "readonly" jmx access

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-11755:

Assignee: Jérôme Mainaud

> nodetool info should run with "readonly" jmx access
> ---
>
> Key: CASSANDRA-11755
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11755
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Jérôme Mainaud
>Assignee: Jérôme Mainaud
>Priority: Minor
>  Labels: security
> Fix For: 2.1.14
>
> Attachments: 11755-2.1.patch, 
> nodetool-info-exception-when-readonly.txt
>
>
> nodetool info crash when granted with readonly jmx access
> In the example given in attachment, the jmxremote.access file gives readonly 
> access to the cassandra jmx role.
> When the role is granted to readwrite access, everything works.
> The main reason is that node datacenter and rack info are fetched by an 
> operation invocation instead of by an attribute read. The former one is not 
> allowed to the role with readonly access.
> This is a security concern because nodetool info could be called by a 
> monitoring agent (Nagios for instance) and enterprise policy often don't 
> allow these agents to connect to JMX with higher privileges than "readonly".



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

[jira] [Created] (CASSANDRA-12052) SSTableRewriterTest is failing

[Tyler Hobbs (JIRA)]

Tyler Hobbs created CASSANDRA-12052:
---

 Summary: SSTableRewriterTest is failing
 Key: CASSANDRA-12052
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12052
 Project: Cassandra
  Issue Type: Bug
  Components: Compaction, Testing
Reporter: Tyler Hobbs


{{SSTableRewriterTest.testSSTableSectionsForRanges-compression}} has been 
failing for 16 test runs, starting with 
http://cassci.datastax.com/job/trunk_testall/956/.  There are also intermittent 
failures of other tests in the same class.

It looks like this may have been caused by CASSANDRA-11886 (based on the first 
failing test run).  [~krummas] can you take a look at this?



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

[jira] [Updated] (CASSANDRA-11755) nodetool info should run with "readonly" jmx access

[Paulo Motta (JIRA)]

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

Paulo Motta updated CASSANDRA-11755:

Status: Ready to Commit  (was: Patch Available)

> nodetool info should run with "readonly" jmx access
> ---
>
> Key: CASSANDRA-11755
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11755
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Observability
>Reporter: Jérôme Mainaud
>Priority: Minor
>  Labels: security
> Fix For: 2.1.14
>
> Attachments: 11755-2.1.patch, 
> nodetool-info-exception-when-readonly.txt
>
>
> nodetool info crash when granted with readonly jmx access
> In the example given in attachment, the jmxremote.access file gives readonly 
> access to the cassandra jmx role.
> When the role is granted to readwrite access, everything works.
> The main reason is that node datacenter and rack info are fetched by an 
> operation invocation instead of by an attribute read. The former one is not 
> allowed to the role with readonly access.
> This is a security concern because nodetool info could be called by a 
> monitoring agent (Nagios for instance) and enterprise policy often don't 
> allow these agents to connect to JMX with higher privileges than "readonly".



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

[jira] [Created] (CASSANDRA-12051) JSON does not take functions

[Tianshi Wang (JIRA)]

Tianshi Wang created CASSANDRA-12051:


 Summary: JSON does not take functions
 Key: CASSANDRA-12051
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12051
 Project: Cassandra
  Issue Type: Improvement
Reporter: Tianshi Wang


toTimestamp(now()) does not work in JSON format.

{code}
cqlsh:ops> create table test (
   ... id int,
   ... ts timestamp,
   ... primary key(id)
   ... );
cqlsh:ops> insert into test (id, ts) values (1, toTimestamp(now()));
cqlsh:ops> select * from test;

 id | ts
+-
  1 | 2016-06-21 18:46:28.753000+

(1 rows)
cqlsh:ops> insert into test JSON '{"id":2,"ts":toTimestamp(now())}';
InvalidRequest: code=2200 [Invalid query] message="Could not decode JSON string 
as a map: org.codehaus.jackson.JsonParseException: Unrecognized token 
'toTimestamp': was expecting
 at [Source: java.io.StringReader@2da0329d; line: 1, column: 25]. (String was: 
{"id":2,"ts":toTimestamp(now())})"
cqlsh:ops> insert into test JSON '{"id":2,"ts":"toTimestamp(now())"}';
InvalidRequest: code=2200 [Invalid query] message="Error decoding JSON value 
for ts: Unable to coerce 'toTimestamp(now())' to a formatted date (long)"
{code}



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

[jira] [Commented] (CASSANDRA-11696) Incremental repairs can mark too many ranges as repaired

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-11696:
---

I've rebased the branches and run dtests for 
[2.1|http://cassci.datastax.com/view/Dev/view/jkni/job/jkni-11696-2.1-dtest/], 
[2.2|http://cassci.datastax.com/view/Dev/view/jkni/job/jkni-11696-2.2-dtest/], 
[3.0|http://cassci.datastax.com/view/Dev/view/jkni/job/jkni-11696-3.0-dtest/], 
and 
[trunk|http://cassci.datastax.com/view/Dev/view/jkni/job/jkni-11696-trunk-dtest/].

They all look clean relative to upstream, so all that remains is the few nits 
above.

> Incremental repairs can mark too many ranges as repaired
> 
>
> Key: CASSANDRA-11696
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11696
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Marcus Eriksson
>Priority: Critical
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> Incremental repairs are tracked using a parent session - a subordinate repair 
> session is created for each range in the repair. When a node participating in 
> the repair receives a validation request, it will reference the sstables in 
> the parent repair session. When all subordinate sessions conclude, each node 
> anticompacts SSTables based on the parent repair session for the whole range 
> of the repair, but these referenced SSTables may have only been present for 
> the validation of some subset of the ranges because the SSTables were created 
> concurrent with the parent repair session.



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

[jira] [Assigned] (CASSANDRA-12006) dtest failure in repair_tests.incremental_repair_test.TestIncRepair.sstable_repairedset_test

[Sean McCarthy (JIRA)]

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

Sean McCarthy reassigned CASSANDRA-12006:
-

Assignee: Sean McCarthy  (was: DS Test Eng)

> dtest failure in 
> repair_tests.incremental_repair_test.TestIncRepair.sstable_repairedset_test
> 
>
> Key: CASSANDRA-12006
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12006
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Sean McCarthy
>  Labels: dtest
> Attachments: node1.log, node2.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/229/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_repairedset_test
> Failed on CassCI build cassandra-2.1_dtest_jdk8 #229
> Logs are attached.
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File 
> "/home/automaton/cassandra-dtest/repair_tests/incremental_repair_test.py", 
> line 226, in sstable_repairedset_test
> self.assertNotIn('Repaired at: 0', finaloutput)
>   File "/usr/lib/python2.7/unittest/case.py", line 810, in assertNotIn
> self.fail(self._formatMessage(msg, standardMsg))
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "'Repaired at: 0' unexpectedly found in 'No such file: 
> /mnt/tmp/dtest-DoN5MO/test/node1/data0/keyspace1/standard1-0d92e6402f7c11e6bac8356bf83fc3ce/keyspace1-standard1-ka-81-Data.db
> {code}



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

[jira] [Commented] (CASSANDRA-12044) Materialized view definition regression in clustering key

[Michael Mior (JIRA)]

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

Michael Mior commented on CASSANDRA-12044:
--

As an aside, the error message should probably change since it says "partition 
key" instead of "primary key."

> Materialized view definition regression in clustering key
> -
>
> Key: CASSANDRA-12044
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12044
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Michael Mior
>Assignee: Carl Yeksigian
>
> This bug was reported on the 
> [users|https://mail-archives.apache.org/mod_mbox/cassandra-user/201606.mbox/%3CCAG0vsSJRtRjLJqKsd3M8X-8nXpPwRj7Q80mNkuy8sy%2B%2B%3D%2BocHA%40mail.gmail.com%3E]
>  mailing list. The following definitions work in 3.0.3 but fail in 3.0.7.
> {code}
> CREATE TABLE ks.pa (
> id bigint,
> sub_id text,
> name text,
> class text,
> r_id bigint,
> k_id bigint,
> created timestamp,
> priority int,
> updated timestamp,
> value text,
> PRIMARY KEY (id, sub_id, name)
> );
> CREATE ks.mv_pa AS
> SELECT k_id, name, value, sub_id, id, class, r_id
> FROM ks.pa
> WHERE k_id IS NOT NULL AND name IS NOT NULL AND value IS NOT NULL AND 
> sub_id IS NOT NULL AND id IS NOT NULL
> PRIMARY KEY ((k_id, name), value, sub_id, id);
> {code}
> After running bisect, I've narrowed it down to commit 
> [86ba227|https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=86ba227477b9f8595eb610ecaf950cfbc29dd36b]
>  from [CASSANDRA-11475|https://issues.apache.org/jira/browse/CASSANDRA-11475].



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

[jira] [Commented] (CASSANDRA-12044) Materialized view definition regression in clustering key

[Michael Mior (JIRA)]

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

Michael Mior commented on CASSANDRA-12044:
--

Thanks for clarifying. This makes a lot of sense.

> Materialized view definition regression in clustering key
> -
>
> Key: CASSANDRA-12044
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12044
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Michael Mior
>Assignee: Carl Yeksigian
>
> This bug was reported on the 
> [users|https://mail-archives.apache.org/mod_mbox/cassandra-user/201606.mbox/%3CCAG0vsSJRtRjLJqKsd3M8X-8nXpPwRj7Q80mNkuy8sy%2B%2B%3D%2BocHA%40mail.gmail.com%3E]
>  mailing list. The following definitions work in 3.0.3 but fail in 3.0.7.
> {code}
> CREATE TABLE ks.pa (
> id bigint,
> sub_id text,
> name text,
> class text,
> r_id bigint,
> k_id bigint,
> created timestamp,
> priority int,
> updated timestamp,
> value text,
> PRIMARY KEY (id, sub_id, name)
> );
> CREATE ks.mv_pa AS
> SELECT k_id, name, value, sub_id, id, class, r_id
> FROM ks.pa
> WHERE k_id IS NOT NULL AND name IS NOT NULL AND value IS NOT NULL AND 
> sub_id IS NOT NULL AND id IS NOT NULL
> PRIMARY KEY ((k_id, name), value, sub_id, id);
> {code}
> After running bisect, I've narrowed it down to commit 
> [86ba227|https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=86ba227477b9f8595eb610ecaf950cfbc29dd36b]
>  from [CASSANDRA-11475|https://issues.apache.org/jira/browse/CASSANDRA-11475].



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

[jira] [Updated] (CASSANDRA-12050) per-patch smoke suites as an early/fast testing tier

[Russ Hatch (JIRA)]

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

Russ Hatch updated CASSANDRA-12050:
---
Description: 
Coverage data offers a unique opportunity to build metadata about tests and 
related Cassandra code.

Using the jacoco coverage api we should be able to build a simple index of 
tests (dtest, unit) to the Cassandra code they touch (and the reverse).

When a new patch is introduced, we do a lookup in that index, based on java 
source files touched (and possibly lines within those files), and use that to 
infer most relevant dtests or unit tests. Patch authors can then run that small 
test subset as a first testing pass.

In this way we can build small, focused, test suites that are custom to each 
patch. Once this small custom smoke test appears successful things would of 
course need to be vetted across a more complete test run on CI.

I think the best interface would simply be ant targets. One target would be 
used to build/refresh the test:source code index (run occasionally and saved 
somewhere; index building would be time consuming since it will require full 
job runs). A second target looks at files touched and does the index lookups, 
then outputs a list of tests to run.

The dev user experience might looking something like this:
{noformat}
ant get-custom-smoke -Dcoverage_index=./trunk_coverage_index_SHA_foo.idx

Generating test lists

Please run the following two scripts to vet your changes:
./custom_smoke_junit.sh
./custom_smoke_dtest.sh
{noformat}

  was:
Coverage data offers a unique opportunity to build metadata about tests and 
related Cassandra code.

Using the jacoco coverage api we should be able to build a simple index of 
tests (dtest, unit) to the Cassandra code they touch (and the reverse).

When a new patch is introduced, we do a lookup in that index, based on java 
source files touched (and possibly lines within those files), and use that to 
infer most relevant dtests or unit tests. Patch authors can then run that small 
test subset as a first testing pass.

In this way we can build small, focused, test suites that are custom to each 
patch. Once this small custom smoke test appears successful things would of 
course need to be vetted across a more complete test run on CI.

I think the best interface would simply be ant targets. One target would be 
used to build/refresh the test:source code index (run occasionally and saved 
somewhere (index building would be time consuming since it will require full 
job runs). A second target looks at files touched and does the index lookups, 
then outputs a list of tests to run.

The dev user experience might looking something like this:
{noformat}
ant get-custom-smoke -Dcoverage_index=./trunk_coverage_index_SHA_foo.idx

Generating test lists

Please run the following two scripts to vet your changes:
./custom_smoke_junit.sh
./custom_smoke_dtest.sh
{noformat}


> per-patch smoke suites as an early/fast testing tier
> 
>
> Key: CASSANDRA-12050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12050
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Russ Hatch
>Assignee: Russ Hatch
>
> Coverage data offers a unique opportunity to build metadata about tests and 
> related Cassandra code.
> Using the jacoco coverage api we should be able to build a simple index of 
> tests (dtest, unit) to the Cassandra code they touch (and the reverse).
> When a new patch is introduced, we do a lookup in that index, based on java 
> source files touched (and possibly lines within those files), and use that to 
> infer most relevant dtests or unit tests. Patch authors can then run that 
> small test subset as a first testing pass.
> In this way we can build small, focused, test suites that are custom to each 
> patch. Once this small custom smoke test appears successful things would of 
> course need to be vetted across a more complete test run on CI.
> I think the best interface would simply be ant targets. One target would be 
> used to build/refresh the test:source code index (run occasionally and saved 
> somewhere; index building would be time consuming since it will require full 
> job runs). A second target looks at files touched and does the index lookups, 
> then outputs a list of tests to run.
> The dev user experience might looking something like this:
> {noformat}
> ant get-custom-smoke -Dcoverage_index=./trunk_coverage_index_SHA_foo.idx
> Generating test lists
> Please run the following two scripts to vet your changes:
> ./custom_smoke_junit.sh
> ./custom_smoke_dtest.sh
> {noformat}



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

[jira] [Created] (CASSANDRA-12050) per-patch smoke suites as an early/fast testing tier

[Russ Hatch (JIRA)]

Russ Hatch created CASSANDRA-12050:
--

 Summary: per-patch smoke suites as an early/fast testing tier
 Key: CASSANDRA-12050
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12050
 Project: Cassandra
  Issue Type: Improvement
Reporter: Russ Hatch
Assignee: Russ Hatch


Coverage data offers a unique opportunity to build metadata about tests and 
related Cassandra code.

Using the jacoco coverage api we should be able to build a simple index of 
tests (dtest, unit) to the Cassandra code they touch (and the reverse).

When a new patch is introduced, we do a lookup in that index, based on java 
source files touched (and possibly lines within those files), and use that to 
infer most relevant dtests or unit tests. Patch authors can then run that small 
test subset as a first testing pass.

In this way we can build small, focused, test suites that are custom to each 
patch. Once this small custom smoke test appears successful things would of 
course need to be vetted across a more complete test run on CI.

I think the best interface would simply be ant targets. One target would be 
used to build/refresh the test:source code index (run occasionally and saved 
somewhere (index building would be time consuming since it will require full 
job runs). A second target looks at files touched and does the index lookups, 
then outputs a list of tests to run.

The dev user experience might looking something like this:
{noformat}
ant get-custom-smoke -Dcoverage_index=./trunk_coverage_index_SHA_foo.idx

Generating test lists

Please run the following two scripts to vet your changes:
./custom_smoke_junit.sh
./custom_smoke_dtest.sh
{noformat}



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

[jira] [Resolved] (CASSANDRA-12047) dtest failure in batch_test.TestBatch.logged_batch_compatibility_3_test

[Philip Thompson (JIRA)]

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

Philip Thompson resolved CASSANDRA-12047.
-
Resolution: Duplicate

> dtest failure in batch_test.TestBatch.logged_batch_compatibility_3_test
> ---
>
> Key: CASSANDRA-12047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12047
> Project: Cassandra
>  Issue Type: Test
>Reporter: Craig Kodman
>Assignee: DS Test Eng
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/252/testReport/batch_test/TestBatch/logged_batch_compatibility_3_test
> Failed on CassCI build cassandra-3.0_novnode_dtest #252



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

[jira] [Updated] (CASSANDRA-12044) Materialized view definition regression in clustering key

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian updated CASSANDRA-12044:
---
Assignee: Carl Yeksigian
Reviewer: Sylvain Lebresne
  Status: Patch Available  (was: Open)

> Materialized view definition regression in clustering key
> -
>
> Key: CASSANDRA-12044
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12044
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Michael Mior
>Assignee: Carl Yeksigian
>
> This bug was reported on the 
> [users|https://mail-archives.apache.org/mod_mbox/cassandra-user/201606.mbox/%3CCAG0vsSJRtRjLJqKsd3M8X-8nXpPwRj7Q80mNkuy8sy%2B%2B%3D%2BocHA%40mail.gmail.com%3E]
>  mailing list. The following definitions work in 3.0.3 but fail in 3.0.7.
> {code}
> CREATE TABLE ks.pa (
> id bigint,
> sub_id text,
> name text,
> class text,
> r_id bigint,
> k_id bigint,
> created timestamp,
> priority int,
> updated timestamp,
> value text,
> PRIMARY KEY (id, sub_id, name)
> );
> CREATE ks.mv_pa AS
> SELECT k_id, name, value, sub_id, id, class, r_id
> FROM ks.pa
> WHERE k_id IS NOT NULL AND name IS NOT NULL AND value IS NOT NULL AND 
> sub_id IS NOT NULL AND id IS NOT NULL
> PRIMARY KEY ((k_id, name), value, sub_id, id);
> {code}
> After running bisect, I've narrowed it down to commit 
> [86ba227|https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=86ba227477b9f8595eb610ecaf950cfbc29dd36b]
>  from [CASSANDRA-11475|https://issues.apache.org/jira/browse/CASSANDRA-11475].



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

[jira] [Commented] (CASSANDRA-12044) Materialized view definition regression in clustering key

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-12044:


The behavior in 3.0.7 is the correct one; we do not properly handle multiple 
non-primary key from the base table in the view. This will result in not 
properly cleaned up columns, which currently cannot be cleaned. The behavior is 
to be changed in CASSANDRA-9928, where we would properly support this scenario.

Unfortunately, you will have to drop the view before upgrading, as 3.0.3 was 
improperly allowing that view to be created.

It doesn't look like we had any tests for this; I've pushed a branch with an 
additional test to make sure that multiple non-primary keys can't be included 
in the view's primary key.

||branch||utest||dtest||
|[3.0|https://github.com/carlyeks/cassandra/tree/ticket/12044/3.0]|[3.0|http://cassci.datastax.com/job/carlyeks-ticket-12044-3.0-testall/]|[3.0|http://cassci.datastax.com/job/carlyeks-ticket-12044-3.0-dtest/]|
|[3.x|https://github.com/carlyeks/cassandra/tree/ticket/12044/3.x]|[3.x|http://cassci.datastax.com/job/carlyeks-ticket-12044-3.x-testall/]|[3.x|http://cassci.datastax.com/job/carlyeks-ticket-12044-3.x-dtest/]|

> Materialized view definition regression in clustering key
> -
>
> Key: CASSANDRA-12044
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12044
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Michael Mior
>
> This bug was reported on the 
> [users|https://mail-archives.apache.org/mod_mbox/cassandra-user/201606.mbox/%3CCAG0vsSJRtRjLJqKsd3M8X-8nXpPwRj7Q80mNkuy8sy%2B%2B%3D%2BocHA%40mail.gmail.com%3E]
>  mailing list. The following definitions work in 3.0.3 but fail in 3.0.7.
> {code}
> CREATE TABLE ks.pa (
> id bigint,
> sub_id text,
> name text,
> class text,
> r_id bigint,
> k_id bigint,
> created timestamp,
> priority int,
> updated timestamp,
> value text,
> PRIMARY KEY (id, sub_id, name)
> );
> CREATE ks.mv_pa AS
> SELECT k_id, name, value, sub_id, id, class, r_id
> FROM ks.pa
> WHERE k_id IS NOT NULL AND name IS NOT NULL AND value IS NOT NULL AND 
> sub_id IS NOT NULL AND id IS NOT NULL
> PRIMARY KEY ((k_id, name), value, sub_id, id);
> {code}
> After running bisect, I've narrowed it down to commit 
> [86ba227|https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=86ba227477b9f8595eb610ecaf950cfbc29dd36b]
>  from [CASSANDRA-11475|https://issues.apache.org/jira/browse/CASSANDRA-11475].



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

[jira] [Updated] (CASSANDRA-12048) Bucket_low property has no effect in STCS Algo

[Anuj Wadehra (JIRA)]

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

Anuj Wadehra updated CASSANDRA-12048:
-
Environment: Cassandra 2.0.x, 2.1.x, 2.2.x  (was: Cassandra 2.2.x)

> Bucket_low property has no effect in STCS Algo
> --
>
> Key: CASSANDRA-12048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12048
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: Cassandra 2.0.x, 2.1.x, 2.2.x
>Reporter: Anuj Wadehra
>
> It seems that the STCS algorithm is not impacted by setting the Bucket_low 
> Compaction property. Also,I see some optimization in STCS algo.
> Problems:
> 1. getBuckets() method of SizeTieredCompactionStrategy sorts sstables by size 
> in ascending order and then iterates over them one by one to associate them 
> to an existing/new bucket. When, iterating sstables in ascending order of 
> size, I can't find ANY single scenario where the current sstable in the outer 
> loop iteration is below the oldAverageSize of any existing bucket. Current 
> sstable being iterated will ALWAYS be greater than/equal to the 
> oldAverageSize of ALL existing buckets as ALL previous sstables in existing 
> buckets were smaller/equal in size to the sstable being iterated.
> So, there is NO scenario when size > (oldAverageSize * bucketLow) and size < 
> oldAverageSize, so bucket_low property never comes into play no matter what 
> value you set for it.
> 2. While iteraitng over sstables (sortedfiles) by size in ascending order, 
> there is no point iterating over all existing buckets. We could just start 
> from the LAST bucket where previous sstable was associated.  oldAverageSize 
> of ALL other buckets will NEVER allow the sstable being iterated.
>  for (Entry entry : buckets.entrySet())
> {...}
>  



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

[jira] [Updated] (CASSANDRA-12048) Bucket_low property has no effect in STCS Algo

[Anuj Wadehra (JIRA)]

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

Anuj Wadehra updated CASSANDRA-12048:
-
  Environment: Cassandra 2.2.x
Fix Version/s: (was: 2.2.x)

> Bucket_low property has no effect in STCS Algo
> --
>
> Key: CASSANDRA-12048
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12048
> Project: Cassandra
>  Issue Type: Bug
>  Components: Compaction
> Environment: Cassandra 2.2.x
>Reporter: Anuj Wadehra
>
> It seems that the STCS algorithm is not impacted by setting the Bucket_low 
> Compaction property. Also,I see some optimization in STCS algo.
> Problems:
> 1. getBuckets() method of SizeTieredCompactionStrategy sorts sstables by size 
> in ascending order and then iterates over them one by one to associate them 
> to an existing/new bucket. When, iterating sstables in ascending order of 
> size, I can't find ANY single scenario where the current sstable in the outer 
> loop iteration is below the oldAverageSize of any existing bucket. Current 
> sstable being iterated will ALWAYS be greater than/equal to the 
> oldAverageSize of ALL existing buckets as ALL previous sstables in existing 
> buckets were smaller/equal in size to the sstable being iterated.
> So, there is NO scenario when size > (oldAverageSize * bucketLow) and size < 
> oldAverageSize, so bucket_low property never comes into play no matter what 
> value you set for it.
> 2. While iteraitng over sstables (sortedfiles) by size in ascending order, 
> there is no point iterating over all existing buckets. We could just start 
> from the LAST bucket where previous sstable was associated.  oldAverageSize 
> of ALL other buckets will NEVER allow the sstable being iterated.
>  for (Entry entry : buckets.entrySet())
> {...}
>  



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

[jira] [Commented] (CASSANDRA-11998) dtest failure in offline_tools_test.TestOfflineTools.sstableofflinerelevel_test

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian commented on CASSANDRA-11998:


Looks like this is probably caused by the changes [~thobbs] and I made to make 
this run faster. It passes locally,

I'll take a look to see what we can do to make sure this is faster than before 
but still tests the releveler.

> dtest failure in 
> offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
> ---
>
> Key: CASSANDRA-11998
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11998
> Project: Cassandra
>  Issue Type: Test
>Reporter: Craig Kodman
>Assignee: Carl Yeksigian
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.2_dtest/635/testReport/offline_tools_test/TestOfflineTools/sstableofflinerelevel_test
> Failed on CassCI build cassandra-2.2_dtest #635



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

[jira] [Created] (CASSANDRA-12049) Compaction does not take into account disk space used by other concurrent compactions

[sankalp kohli (JIRA)]

sankalp kohli created CASSANDRA-12049:
-

 Summary: Compaction does not take into account disk space used by 
other concurrent compactions
 Key: CASSANDRA-12049
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12049
 Project: Cassandra
  Issue Type: Improvement
Reporter: sankalp kohli
Priority: Minor


When we have multiple compactions happening in parallel, we should block the 
free space used by running compactions. If we increase the number of parrallel 
compactions, it is more likely to fail with free space issues without this 
check.



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

[jira] [Created] (CASSANDRA-12048) Bucket_low property has no effect in STCS Algo

[Anuj Wadehra (JIRA)]

Anuj Wadehra created CASSANDRA-12048:


 Summary: Bucket_low property has no effect in STCS Algo
 Key: CASSANDRA-12048
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12048
 Project: Cassandra
  Issue Type: Bug
  Components: Compaction
Reporter: Anuj Wadehra
 Fix For: 2.2.x


It seems that the STCS algorithm is not impacted by setting the Bucket_low 
Compaction property. Also,I see some optimization in STCS algo.

Problems:
1. getBuckets() method of SizeTieredCompactionStrategy sorts sstables by size 
in ascending order and then iterates over them one by one to associate them to 
an existing/new bucket. When, iterating sstables in ascending order of size, I 
can't find ANY single scenario where the current sstable in the outer loop 
iteration is below the oldAverageSize of any existing bucket. Current sstable 
being iterated will ALWAYS be greater than/equal to the oldAverageSize of ALL 
existing buckets as ALL previous sstables in existing buckets were 
smaller/equal in size to the sstable being iterated.

So, there is NO scenario when size > (oldAverageSize * bucketLow) and size < 
oldAverageSize, so bucket_low property never comes into play no matter what 
value you set for it.

2. While iteraitng over sstables (sortedfiles) by size in ascending order, 
there is no point iterating over all existing buckets. We could just start from 
the LAST bucket where previous sstable was associated.  oldAverageSize of ALL 
other buckets will NEVER allow the sstable being iterated.

 for (Entry entry : buckets.entrySet())
{...}

 



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

[jira] [Created] (CASSANDRA-12047) dtest failure in batch_test.TestBatch.logged_batch_compatibility_3_test

[Craig Kodman (JIRA)]

Craig Kodman created CASSANDRA-12047:


 Summary: dtest failure in 
batch_test.TestBatch.logged_batch_compatibility_3_test
 Key: CASSANDRA-12047
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12047
 Project: Cassandra
  Issue Type: Test
Reporter: Craig Kodman
Assignee: DS Test Eng


example failure:

http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/252/testReport/batch_test/TestBatch/logged_batch_compatibility_3_test

Failed on CassCI build cassandra-3.0_novnode_dtest #252



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

[jira] [Commented] (CASSANDRA-4663) Streaming sends one file at a time serially.

[Anubhav Kale (JIRA)]

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

Anubhav Kale commented on CASSANDRA-4663:
-

I ran some more tests on the original code and change with multiple sockets, 
and confirmed that the end-to-end time we see during streaming is a direct 
function of how long it takes for the sender to send bytes through (meaning 
sender is the only "slow" entity which makes the problem somewhat tangible).

Then, I tested sending multiple files in parallel through some hacks, but as I 
was expecting it does not yield much improvements mainly because 
{{WritableByteChannel}} is a blocking channel across threads. 

>From docs, "Only one write operation upon a writable channel may be in 
>progress at any given time. If one thread initiates a write operation upon a 
>channel then any other thread that attempts to initiate another write 
>operation will block until the first operation is complete."

We would need to move to {{AsynchronousSocketChannel}} to get true parallelism 
(which obviously is a deeper change - not impossible though).


> Streaming sends one file at a time serially. 
> -
>
> Key: CASSANDRA-4663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4663
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: sankalp kohli
>Priority: Minor
>
> This is not fast enough when someone is using SSD and may be 10G link. We 
> should try to create multiple connections and send multiple files in 
> parallel. 
> Current approach under utilize the link(even 1G).
> This change will improve the bootstrapping time of a node. 



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

[jira] [Commented] (CASSANDRA-11845) Hanging repair in cassandra 2.2.4

[vin01 (JIRA)]

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

vin01 commented on CASSANDRA-11845:
---

Thanks a lot Paulo! I am going to try it. Present value of vm.max_map_count is 
"65530" which is default I believe.
I am going to increase it to "131072" as recommended by 
https://docs.datastax.com/en/cassandra/2.2/cassandra/install/installRecommendSettings.html.



> Hanging repair in cassandra 2.2.4
> -
>
> Key: CASSANDRA-11845
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11845
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
> Environment: Centos 6
>Reporter: vin01
>Priority: Minor
> Attachments: cassandra-2.2.4.error.log, system.log
>
>
> So after increasing the streaming_timeout_in_ms value to 3 hours, i was able 
> to avoid the socketTimeout errors i was getting earlier 
> (https://issues.apAache.org/jira/browse/CASSANDRA-11826), but now the issue 
> is repair just stays stuck.
> current status :-
> [2016-05-19 05:52:50,835] Repair session a0e590e1-1d99-11e6-9d63-b717b380ffdd 
> for range (-3309358208555432808,-3279958773585646585] finished (progress: 54%)
> [2016-05-19 05:53:09,446] Repair session a0e590e3-1d99-11e6-9d63-b717b380ffdd 
> for range (8149151263857514385,8181801084802729407] finished (progress: 55%)
> [2016-05-19 05:53:13,808] Repair session a0e5b7f1-1d99-11e6-9d63-b717b380ffdd 
> for range (3372779397996730299,3381236471688156773] finished (progress: 55%)
> [2016-05-19 05:53:27,543] Repair session a0e5b7f3-1d99-11e6-9d63-b717b380ffdd 
> for range (-4182952858113330342,-4157904914928848809] finished (progress: 55%)
> [2016-05-19 05:53:41,128] Repair session a0e5df00-1d99-11e6-9d63-b717b380ffdd 
> for range (6499366179019889198,6523760493740195344] finished (progress: 55%)
> And its 10:46:25 Now, almost 5 hours since it has been stuck right there.
> Earlier i could see repair session going on in system.log but there are no 
> logs coming in right now, all i get in logs is regular index summary 
> redistribution logs.
> Last logs for repair i saw in logs :-
> INFO  [RepairJobTask:5] 2016-05-19 05:53:41,125 RepairJob.java:152 - [repair 
> #a0e5df00-1d99-11e6-9d63-b717b380ffdd] TABLE_NAME is fully synced
> INFO  [RepairJobTask:5] 2016-05-19 05:53:41,126 RepairSession.java:279 - 
> [repair #a0e5df00-1d99-11e6-9d63-b717b380ffdd] Session completed successfully
> INFO  [RepairJobTask:5] 2016-05-19 05:53:41,126 RepairRunnable.java:232 - 
> Repair session a0e5df00-1d99-11e6-9d63-b717b380ffdd for range 
> (6499366179019889198,6523760493740195344] finished
> Its an incremental repair, and in "nodetool netstats" output i can see logs 
> like :-
> Repair e3055fb0-1d9d-11e6-9d63-b717b380ffdd
> /Node-2
> Receiving 8 files, 1093461 bytes total. Already received 8 files, 
> 1093461 bytes total
> 
> /data/cassandra/data/KEYSPACE_NAME/TABLE_NAME-01ad9750723e11e4bfe0d3887930a87c/tmp-la-80872-big-Data.db
>  399475/399475 bytes(100%) received from idx:0/Node-2
> 
> /data/cassandra/data/KEYSPACE_NAME/TABLE_NAME-01ad9750723e11e4bfe0d3887930a87c/tmp-la-80879-big-Data.db
>  53809/53809 bytes(100%) received from idx:0/Node-2
> 
> /data/cassandra/data/KEYSPACE_NAME/TABLE_NAME-01ad9750723e11e4bfe0d3887930a87c/tmp-la-80878-big-Data.db
>  89955/89955 bytes(100%) received from idx:0/Node-2
> 
> /data/cassandra/data/KEYSPACE_NAME/TABLE_NAME-01ad9750723e11e4bfe0d3887930a87c/tmp-la-80881-big-Data.db
>  168790/168790 bytes(100%) received from idx:0/Node-2
> 
> /data/cassandra/data/KEYSPACE_NAME/TABLE_NAME-01ad9750723e11e4bfe0d3887930a87c/tmp-la-80886-big-Data.db
>  107785/107785 bytes(100%) received from idx:0/Node-2
> 
> /data/cassandra/data/KEYSPACE_NAME/TABLE_NAME-01ad9750723e11e4bfe0d3887930a87c/tmp-la-80880-big-Data.db
>  52889/52889 bytes(100%) received from idx:0/Node-2
> 
> /data/cassandra/data/KEYSPACE_NAME/TABLE_NAME-01ad9750723e11e4bfe0d3887930a87c/tmp-la-80884-big-Data.db
>  148882/148882 bytes(100%) received from idx:0/Node-2
> 
> /data/cassandra/data/KEYSPACE_NAME/TABLE_NAME-01ad9750723e11e4bfe0d3887930a87c/tmp-la-80883-big-Data.db
>  71876/71876 bytes(100%) received from idx:0/Node-2
> Sending 5 files, 863321 bytes total. Already sent 5 files, 863321 
> bytes total
> 
> /data/cassandra/data/KEYSPACE_NAME/TABLE_NAME-01ad9750723e11e4bfe0d3887930a87c/la-73168-big-Data.db
>  161895/161895 bytes(100%) sent to idx:0/Node-2
> 
> /data/cassandra/data/KEYSPACE_NAME/TABLE_NAME-01ad9750723e11e4bfe0d3887930a87c/la-72604-big-Data.db
>  399865/399865 bytes(100%) sent to idx:0/Node-2
> 
> 

[jira] [Comment Edited] (CASSANDRA-12007) dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test

[Sean McCarthy (JIRA)]

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

Sean McCarthy edited comment on CASSANDRA-12007 at 6/21/16 4:36 PM:


>From what I understand of 11598, we should expect the string ' 127.0.0.2 ' to 
>exist in the trace messages in versions 2.2+. Yet it seems like we're looking 
>for the string '127.0.0.2' in these versions, and the string ' 127.0.0.2 ' in 
>all versions. [~philipthompson]?

Maybe it would just be easier to version gate the test with 
{code}@since("2.2"){code}


was (Author: sean.mccarthy):
>From what I understand of 11598, we should expect the string ' 127.0.0.2 ' to 
>exist in the trace messages in versions 2.2+. Yet it seems like we're looking 
>for the string '127.0.0.2' in these versions, and the string ' 127.0.0.2 ' in 
>all versions. [~philipthompson]?

> dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test
> 
>
> Key: CASSANDRA-12007
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12007
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Sean McCarthy
>  Labels: dtest
> Attachments: node1.log, node2.log, node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/229/testReport/cql_tracing_test/TestCqlTracing/tracing_simple_test
> Failed on CassCI build cassandra-2.1_dtest_jdk8 #229
> Logs are attached.
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/cql_tracing_test.py", line 104, in 
> tracing_simple_test
> self.trace(session)
>   File "/home/automaton/cassandra-dtest/cql_tracing_test.py", line 92, in 
> trace
> self.assertIn(' 127.0.0.2 ', out)
>   File "/usr/lib/python2.7/unittest/case.py", line 803, in assertIn
> self.fail(self._formatMessage(msg, standardMsg))
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "' 127.0.0.2 ' not found
> {code}



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

[jira] [Assigned] (CASSANDRA-11998) dtest failure in offline_tools_test.TestOfflineTools.sstableofflinerelevel_test

[Carl Yeksigian (JIRA)]

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

Carl Yeksigian reassigned CASSANDRA-11998:
--

Assignee: Carl Yeksigian  (was: DS Test Eng)

> dtest failure in 
> offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
> ---
>
> Key: CASSANDRA-11998
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11998
> Project: Cassandra
>  Issue Type: Test
>Reporter: Craig Kodman
>Assignee: Carl Yeksigian
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.2_dtest/635/testReport/offline_tools_test/TestOfflineTools/sstableofflinerelevel_test
> Failed on CassCI build cassandra-2.2_dtest #635



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

[jira] [Commented] (CASSANDRA-12007) dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test

[Sean McCarthy (JIRA)]

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

Sean McCarthy commented on CASSANDRA-12007:
---

>From what I understand of 11598, we should expect the string ' 127.0.0.2 ' to 
>exist in the trace messages in versions 2.2+. Yet it seems like we're looking 
>for the string '127.0.0.2' in these versions, and the string ' 127.0.0.2 ' in 
>all versions. [~philipthompson]?

> dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test
> 
>
> Key: CASSANDRA-12007
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12007
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Sean McCarthy
>  Labels: dtest
> Attachments: node1.log, node2.log, node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/229/testReport/cql_tracing_test/TestCqlTracing/tracing_simple_test
> Failed on CassCI build cassandra-2.1_dtest_jdk8 #229
> Logs are attached.
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/cql_tracing_test.py", line 104, in 
> tracing_simple_test
> self.trace(session)
>   File "/home/automaton/cassandra-dtest/cql_tracing_test.py", line 92, in 
> trace
> self.assertIn(' 127.0.0.2 ', out)
>   File "/usr/lib/python2.7/unittest/case.py", line 803, in assertIn
> self.fail(self._formatMessage(msg, standardMsg))
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "' 127.0.0.2 ' not found
> {code}



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

[jira] [Updated] (CASSANDRA-9507) range metrics are not updated for timeout and unavailable in StorageProxy

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-9507:
--
Status: Open  (was: Patch Available)

> range metrics are not updated for timeout and unavailable in StorageProxy
> -
>
> Key: CASSANDRA-9507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9507
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability
>Reporter: sankalp kohli
>Assignee: Nachiket Patil
>Priority: Minor
> Attachments: Cassandra-9507.diff
>
>
> Looking at the code, it looks like range metrics are not updated for timeouts 
> and unavailable. 



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

[jira] [Commented] (CASSANDRA-9507) range metrics are not updated for timeout and unavailable in StorageProxy

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer commented on CASSANDRA-9507:
---

Thanks for the patch.

It seems that range metrics are also not updated for {{failure}}. Could you 
update your patch and provide one for 3.0 and trunk (the current one does not 
apply).

I guessed that the patch was for 2.2 but it would be nice if you could specify 
the version next time.It simplify the review process.
 

> range metrics are not updated for timeout and unavailable in StorageProxy
> -
>
> Key: CASSANDRA-9507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9507
> Project: Cassandra
>  Issue Type: Bug
>  Components: Observability
>Reporter: sankalp kohli
>Assignee: Nachiket Patil
>Priority: Minor
> Attachments: Cassandra-9507.diff
>
>
> Looking at the code, it looks like range metrics are not updated for timeouts 
> and unavailable. 



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

[jira] [Updated] (CASSANDRA-12038) dtest failure in batch_test.TestBatch.logged_batch_compatibility_3_test

[Philip Thompson (JIRA)]

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

Philip Thompson updated CASSANDRA-12038:

Attachment: node3.log
node2.log
node1.log

> dtest failure in batch_test.TestBatch.logged_batch_compatibility_3_test
> ---
>
> Key: CASSANDRA-12038
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12038
> Project: Cassandra
>  Issue Type: Test
>Reporter: Craig Kodman
>Assignee: Sean McCarthy
>  Labels: dtest
> Attachments: node1.log, node2.log, node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/252/testReport/batch_test/TestBatch/logged_batch_compatibility_3_test
> Failed on CassCI build cassandra-3.0_novnode_dtest #252



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

[jira] [Commented] (CASSANDRA-12038) dtest failure in batch_test.TestBatch.logged_batch_compatibility_3_test

[Philip Thompson (JIRA)]

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

Philip Thompson commented on CASSANDRA-12038:
-

I suppose so. The node fails to start after an upgrade from 2.1 to 3.0.8. It 
seems very flaky, and literally nothing useful is in the logs, so I don't 
expect anyone to make it very far with this, but it's not a test issue.

> dtest failure in batch_test.TestBatch.logged_batch_compatibility_3_test
> ---
>
> Key: CASSANDRA-12038
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12038
> Project: Cassandra
>  Issue Type: Test
>Reporter: Craig Kodman
>Assignee: Sean McCarthy
>  Labels: dtest
> Attachments: node1.log, node2.log, node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/252/testReport/batch_test/TestBatch/logged_batch_compatibility_3_test
> Failed on CassCI build cassandra-3.0_novnode_dtest #252



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

[jira] [Comment Edited] (CASSANDRA-12038) dtest failure in batch_test.TestBatch.logged_batch_compatibility_3_test

[Philip Thompson (JIRA)]

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

Philip Thompson edited comment on CASSANDRA-12038 at 6/21/16 4:18 PM:
--

I suppose so. The node fails to start after an upgrade from 2.1 to 3.0.8. It 
seems very flaky, and literally nothing useful is in the logs, so I don't 
expect anyone to make it very far with this, but it's not a clear test issue.


was (Author: philipthompson):
I suppose so. The node fails to start after an upgrade from 2.1 to 3.0.8. It 
seems very flaky, and literally nothing useful is in the logs, so I don't 
expect anyone to make it very far with this, but it's not a test issue.

> dtest failure in batch_test.TestBatch.logged_batch_compatibility_3_test
> ---
>
> Key: CASSANDRA-12038
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12038
> Project: Cassandra
>  Issue Type: Test
>Reporter: Craig Kodman
>Assignee: Sean McCarthy
>  Labels: dtest
> Attachments: node1.log, node2.log, node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/252/testReport/batch_test/TestBatch/logged_batch_compatibility_3_test
> Failed on CassCI build cassandra-3.0_novnode_dtest #252



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

[jira] [Updated] (CASSANDRA-11920) bloom_filter_fp_chance needs to be validated up front

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-11920:

   Resolution: Fixed
Fix Version/s: 3.0.8
   3.8
   2.2.7
   Status: Resolved  (was: Patch Available)

The tests look good, so +1, committed as 
{{9e85e85bf259cc7839226a7c93475505d262946a}} to 2.2 and merged up to 3.0 and 
trunk.

I don't think any documentation change is required here.  There has always been 
a minimum supported bloom filter FP ratio, we just failed to enforce at the 
right point.

Thanks again for the patch!

> bloom_filter_fp_chance needs to be validated up front
> -
>
> Key: CASSANDRA-11920
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11920
> Project: Cassandra
>  Issue Type: Bug
>  Components: Lifecycle, Local Write-Read Paths
>Reporter: ADARSH KUMAR
>Assignee: Arindam Gupta
>Priority: Minor
>  Labels: lhf
> Fix For: 2.2.7, 3.8, 3.0.8
>
> Attachments: 11920-3.0.txt
>
>
> Hi,
> I was doing some bench-marking on bloom_filter_fp_chance values. Everything 
> worked fine for values .01(default for STCS), .001, .0001. But when I set 
> bloom_filter_fp_chance = .1 i observed following behaviour:
> 1). Reads and writes looked normal from cqlsh.
> 2). SSttables are never created.
> 3). It just creates two files (*-Data.db and *-index.db) of size 0kb.
> 4). nodetool flush does not work and produce following exception:
> java.lang.UnsupportedOperationException: Unable to satisfy 1.0E-5 with 20 
> buckets per element
> at 
> org.apache.cassandra.utils.BloomCalculations.computeBloomSpec(BloomCalculations.java:150)
>  .
> I checked BloomCalculations class and following lines are responsible for 
> this exception:
> if (maxFalsePosProb < probs[maxBucketsPerElement][maxK]) {
>   throw new UnsupportedOperationException(String.format("Unable to 
> satisfy %s with %s buckets per element",
>  maxFalsePosProb, 
> maxBucketsPerElement));
>   }
> From  the code it looks like a hard coaded validation (unless we can change 
> the nuber of buckets).
> So, if this validation is hard coaded then why it is even allowed to set such 
> value of bloom_fileter_fp_chance, that can prevent ssTable generation?
> Please correct this issue.



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

[3/3] cassandra git commit: Merge branch 'cassandra-3.0' into trunk

[tylerhobbs]

Merge branch 'cassandra-3.0' into trunk

Conflicts:
src/java/org/apache/cassandra/schema/TableParams.java


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

Branch: refs/heads/trunk
Commit: 6a7985d87a794e95c5e17a3aa9d73c5ed42177ff
Parents: 063e917 621d08a
Author: Tyler Hobbs 
Authored: Tue Jun 21 11:14:09 2016 -0500
Committer: Tyler Hobbs 
Committed: Tue Jun 21 11:14:09 2016 -0500

--
 CHANGES.txt |  2 +
 .../apache/cassandra/schema/TableParams.java|  7 ++-
 .../cassandra/utils/BloomCalculations.java  | 15 +-
 .../schema/CreateTableValidationTest.java   | 51 
 4 files changed, 71 insertions(+), 4 deletions(-)
--


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

http://git-wip-us.apache.org/repos/asf/cassandra/blob/6a7985d8/src/java/org/apache/cassandra/schema/TableParams.java
--
diff --cc src/java/org/apache/cassandra/schema/TableParams.java
index 16b4427,29d3e29..02112af
--- a/src/java/org/apache/cassandra/schema/TableParams.java
+++ b/src/java/org/apache/cassandra/schema/TableParams.java
@@@ -25,7 -25,7 +25,8 @@@ import com.google.common.base.Objects
  import com.google.common.collect.ImmutableMap;
  
  import org.apache.cassandra.exceptions.ConfigurationException;
+ import org.apache.cassandra.utils.BloomCalculations;
 +
  import static java.lang.String.format;
  
  public final class TableParams

[2/3] cassandra git commit: Merge branch 'cassandra-2.2' into cassandra-3.0

[tylerhobbs]

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/621d08a1
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/621d08a1
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/621d08a1

Branch: refs/heads/trunk
Commit: 621d08a1464d43d828c8eceed57f45268e89a3c3
Parents: 723a143 9e85e85
Author: Tyler Hobbs 
Authored: Tue Jun 21 11:13:12 2016 -0500
Committer: Tyler Hobbs 
Committed: Tue Jun 21 11:13:12 2016 -0500

--
 CHANGES.txt |  2 +
 .../apache/cassandra/schema/TableParams.java|  7 ++-
 .../cassandra/utils/BloomCalculations.java  | 15 +-
 .../schema/CreateTableValidationTest.java   | 51 
 4 files changed, 71 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/621d08a1/CHANGES.txt
--
diff --cc CHANGES.txt
index cc682c4,36009c5..134a5e1
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,33 -1,9 +1,35 @@@
 -2.2.7
 +3.0.8
 + * Fix upgrading schema with super columns with non-text subcomparators 
(CASSANDRA-12023)
 + * Add TimeWindowCompactionStrategy (CASSANDRA-9666)
 +Merged from 2.2:
+  * Validate bloom_filter_fp_chance against lowest supported
+value when the table is created (CASSANDRA-11920)
 - * RandomAccessReader: call isEOF() only when rebuffering, not for every read 
operation (CASSANDRA-12013)
   * Don't send erroneous NEW_NODE notifications on restart (CASSANDRA-11038)
   * StorageService shutdown hook should use a volatile variable 
(CASSANDRA-11984)
 +Merged from 2.1:
 + * Cache local ranges when calculating repair neighbors (CASSANDRA-11934)
 + * Allow LWT operation on static column with only partition keys 
(CASSANDRA-10532)
 + * Create interval tree over canonical sstables to avoid missing sstables 
during streaming (CASSANDRA-11886)
 + * cqlsh COPY FROM: shutdown parent cluster after forking, to avoid 
corrupting SSL connections (CASSANDRA-11749)
 +
 +
 +3.0.7
 + * Fix legacy serialization of Thrift-generated non-compound range tombstones
 +   when communicating with 2.x nodes (CASSANDRA-11930)
 + * Fix Directories instantiations where CFS.initialDirectories should be used 
(CASSANDRA-11849)
 + * Avoid referencing DatabaseDescriptor in AbstractType (CASSANDRA-11912)
 + * Fix sstables not being protected from removal during index build 
(CASSANDRA-11905)
 + * cqlsh: Suppress stack trace from Read/WriteFailures (CASSANDRA-11032)
 + * Remove unneeded code to repair index summaries that have
 +   been improperly down-sampled (CASSANDRA-11127)
 + * Avoid WriteTimeoutExceptions during commit log replay due to materialized
 +   view lock contention (CASSANDRA-11891)
 + * Prevent OOM failures on SSTable corruption, improve tests for corruption 
detection (CASSANDRA-9530)
 + * Use CFS.initialDirectories when clearing snapshots (CASSANDRA-11705)
 + * Allow compaction strategies to disable early open (CASSANDRA-11754)
 + * Refactor Materialized View code (CASSANDRA-11475)
 + * Update Java Driver (CASSANDRA-11615)
 +Merged from 2.2:
   * Persist local metadata earlier in startup sequence (CASSANDRA-11742)
   * Run CommitLog tests with different compression settings (CASSANDRA-9039)
   * cqlsh: fix tab completion for case-sensitive identifiers (CASSANDRA-11664)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/621d08a1/src/java/org/apache/cassandra/schema/TableParams.java
--
diff --cc src/java/org/apache/cassandra/schema/TableParams.java
index 7e44e73,000..29d3e29
mode 100644,00..100644
--- a/src/java/org/apache/cassandra/schema/TableParams.java
+++ b/src/java/org/apache/cassandra/schema/TableParams.java
@@@ -1,377 -1,0 +1,380 @@@
 +/*
 + * 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 ownership.  The ASF licenses this file
 + * to you under the Apache License, Version 2.0 (the
 + * "License"); you may not use this file except in compliance
 + * with the License.  You may obtain a copy of the License at
 + *
 + * http://www.apache.org/licenses/LICENSE-2.0
 + *
 + * Unless required by applicable law or agreed to in writing, software
 + * distributed under the License is distributed on an "AS IS" BASIS,
 + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 + * See the License for the specific language governing permissions and
 + * limitations under the License.
 + */
 +package org.apache.cassandra.schema;
 +
 +import java.nio.ByteBuffer;
 +import 

[1/3] cassandra git commit: Validate bloom_filter_fp_chance during table creation

[tylerhobbs]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 063e91754 -> 6a7985d87


Validate bloom_filter_fp_chance during table creation

Patch by Arinadm Gupta; reviewed by Tyler Hobbs for CASSANDRA-11920


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

Branch: refs/heads/trunk
Commit: 9e85e85bf259cc7839226a7c93475505d262946a
Parents: 5a09627
Author: Arindam Gupta 
Authored: Fri Jun 17 16:06:22 2016 -0500
Committer: Tyler Hobbs 
Committed: Tue Jun 21 11:12:15 2016 -0500

--
 CHANGES.txt |  5 +-
 .../cassandra/cql3/statements/CFPropDefs.java   | 13 -
 .../cassandra/utils/BloomCalculations.java  | 15 +-
 .../schema/CreateTableValidationTest.java   | 51 
 4 files changed, 78 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9e85e85b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index fe4728d..36009c5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
-<<< HEAD
 2.2.7
+ * Validate bloom_filter_fp_chance against lowest supported
+   value when the table is created (CASSANDRA-11920)
  * RandomAccessReader: call isEOF() only when rebuffering, not for every read 
operation (CASSANDRA-12013)
  * Don't send erroneous NEW_NODE notifications on restart (CASSANDRA-11038)
  * StorageService shutdown hook should use a volatile variable 
(CASSANDRA-11984)
@@ -28,10 +29,8 @@
  * Always close cluster with connection in CqlRecordWriter (CASSANDRA-11553)
  * Fix slice queries on ordered COMPACT tables (CASSANDRA-10988)
 Merged from 2.1:
-===
 2.1.15
  * Remove distinction between non-existing static columns and existing but 
null in LWTs (CASSANDRA-9842)
->>> asf/cassandra-2.1
  * Support mlockall on IBM POWER arch (CASSANDRA-11576)
  * Cache local ranges when calculating repair neighbors (CASSANDRA-11933)
  * Allow LWT operation on static column with only partition keys 
(CASSANDRA-10532)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9e85e85b/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java 
b/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
index d897cb7..c02e78e 100644
--- a/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
@@ -26,6 +26,7 @@ import 
org.apache.cassandra.db.compaction.AbstractCompactionStrategy;
 import org.apache.cassandra.exceptions.ConfigurationException;
 import org.apache.cassandra.exceptions.SyntaxException;
 import org.apache.cassandra.io.compress.CompressionParameters;
+import org.apache.cassandra.utils.BloomCalculations;
 
 public class CFPropDefs extends PropertyDefinitions
 {
@@ -211,7 +212,17 @@ public class CFPropDefs extends PropertyDefinitions
 cfm.compactionStrategyOptions(new 
HashMap<>(getCompactionOptions()));
 }
 
-cfm.bloomFilterFpChance(getDouble(KW_BF_FP_CHANCE, 
cfm.getBloomFilterFpChance()));
+double bloomFilterFpChance = getDouble(KW_BF_FP_CHANCE, 
cfm.getBloomFilterFpChance());
+double minBloomFilterFpChanceValue = 
BloomCalculations.minSupportedBloomFilterFpChance();
+if (bloomFilterFpChance <=  minBloomFilterFpChanceValue || 
bloomFilterFpChance > 1)
+{
+throw new ConfigurationException(String.format(
+"%s must be larger than %s and less than or equal to 1.0 
(got %s)",
+KW_BF_FP_CHANCE,
+minBloomFilterFpChanceValue,
+bloomFilterFpChance));
+}
+cfm.bloomFilterFpChance(bloomFilterFpChance);
 
 if (!getCompressionOptions().isEmpty())
 
cfm.compressionParameters(CompressionParameters.create(getCompressionOptions()));

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9e85e85b/src/java/org/apache/cassandra/utils/BloomCalculations.java
--
diff --git a/src/java/org/apache/cassandra/utils/BloomCalculations.java 
b/src/java/org/apache/cassandra/utils/BloomCalculations.java
index b73f531..7ba5452 100644
--- a/src/java/org/apache/cassandra/utils/BloomCalculations.java
+++ b/src/java/org/apache/cassandra/utils/BloomCalculations.java
@@ -26,8 +26,8 @@ package org.apache.cassandra.utils;
  * Filter class by helping to choose correct values of 'bits per element' and
  * 

[1/2] cassandra git commit: Validate bloom_filter_fp_chance during table creation

[tylerhobbs]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-3.0 723a143c9 -> 621d08a14


Validate bloom_filter_fp_chance during table creation

Patch by Arinadm Gupta; reviewed by Tyler Hobbs for CASSANDRA-11920


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

Branch: refs/heads/cassandra-3.0
Commit: 9e85e85bf259cc7839226a7c93475505d262946a
Parents: 5a09627
Author: Arindam Gupta 
Authored: Fri Jun 17 16:06:22 2016 -0500
Committer: Tyler Hobbs 
Committed: Tue Jun 21 11:12:15 2016 -0500

--
 CHANGES.txt |  5 +-
 .../cassandra/cql3/statements/CFPropDefs.java   | 13 -
 .../cassandra/utils/BloomCalculations.java  | 15 +-
 .../schema/CreateTableValidationTest.java   | 51 
 4 files changed, 78 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9e85e85b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index fe4728d..36009c5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
-<<< HEAD
 2.2.7
+ * Validate bloom_filter_fp_chance against lowest supported
+   value when the table is created (CASSANDRA-11920)
  * RandomAccessReader: call isEOF() only when rebuffering, not for every read 
operation (CASSANDRA-12013)
  * Don't send erroneous NEW_NODE notifications on restart (CASSANDRA-11038)
  * StorageService shutdown hook should use a volatile variable 
(CASSANDRA-11984)
@@ -28,10 +29,8 @@
  * Always close cluster with connection in CqlRecordWriter (CASSANDRA-11553)
  * Fix slice queries on ordered COMPACT tables (CASSANDRA-10988)
 Merged from 2.1:
-===
 2.1.15
  * Remove distinction between non-existing static columns and existing but 
null in LWTs (CASSANDRA-9842)
->>> asf/cassandra-2.1
  * Support mlockall on IBM POWER arch (CASSANDRA-11576)
  * Cache local ranges when calculating repair neighbors (CASSANDRA-11933)
  * Allow LWT operation on static column with only partition keys 
(CASSANDRA-10532)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9e85e85b/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java 
b/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
index d897cb7..c02e78e 100644
--- a/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
@@ -26,6 +26,7 @@ import 
org.apache.cassandra.db.compaction.AbstractCompactionStrategy;
 import org.apache.cassandra.exceptions.ConfigurationException;
 import org.apache.cassandra.exceptions.SyntaxException;
 import org.apache.cassandra.io.compress.CompressionParameters;
+import org.apache.cassandra.utils.BloomCalculations;
 
 public class CFPropDefs extends PropertyDefinitions
 {
@@ -211,7 +212,17 @@ public class CFPropDefs extends PropertyDefinitions
 cfm.compactionStrategyOptions(new 
HashMap<>(getCompactionOptions()));
 }
 
-cfm.bloomFilterFpChance(getDouble(KW_BF_FP_CHANCE, 
cfm.getBloomFilterFpChance()));
+double bloomFilterFpChance = getDouble(KW_BF_FP_CHANCE, 
cfm.getBloomFilterFpChance());
+double minBloomFilterFpChanceValue = 
BloomCalculations.minSupportedBloomFilterFpChance();
+if (bloomFilterFpChance <=  minBloomFilterFpChanceValue || 
bloomFilterFpChance > 1)
+{
+throw new ConfigurationException(String.format(
+"%s must be larger than %s and less than or equal to 1.0 
(got %s)",
+KW_BF_FP_CHANCE,
+minBloomFilterFpChanceValue,
+bloomFilterFpChance));
+}
+cfm.bloomFilterFpChance(bloomFilterFpChance);
 
 if (!getCompressionOptions().isEmpty())
 
cfm.compressionParameters(CompressionParameters.create(getCompressionOptions()));

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9e85e85b/src/java/org/apache/cassandra/utils/BloomCalculations.java
--
diff --git a/src/java/org/apache/cassandra/utils/BloomCalculations.java 
b/src/java/org/apache/cassandra/utils/BloomCalculations.java
index b73f531..7ba5452 100644
--- a/src/java/org/apache/cassandra/utils/BloomCalculations.java
+++ b/src/java/org/apache/cassandra/utils/BloomCalculations.java
@@ -26,8 +26,8 @@ package org.apache.cassandra.utils;
  * Filter class by helping to choose correct values of 'bits per 

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

[tylerhobbs]

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/621d08a1
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/621d08a1
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/621d08a1

Branch: refs/heads/cassandra-3.0
Commit: 621d08a1464d43d828c8eceed57f45268e89a3c3
Parents: 723a143 9e85e85
Author: Tyler Hobbs 
Authored: Tue Jun 21 11:13:12 2016 -0500
Committer: Tyler Hobbs 
Committed: Tue Jun 21 11:13:12 2016 -0500

--
 CHANGES.txt |  2 +
 .../apache/cassandra/schema/TableParams.java|  7 ++-
 .../cassandra/utils/BloomCalculations.java  | 15 +-
 .../schema/CreateTableValidationTest.java   | 51 
 4 files changed, 71 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/621d08a1/CHANGES.txt
--
diff --cc CHANGES.txt
index cc682c4,36009c5..134a5e1
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,33 -1,9 +1,35 @@@
 -2.2.7
 +3.0.8
 + * Fix upgrading schema with super columns with non-text subcomparators 
(CASSANDRA-12023)
 + * Add TimeWindowCompactionStrategy (CASSANDRA-9666)
 +Merged from 2.2:
+  * Validate bloom_filter_fp_chance against lowest supported
+value when the table is created (CASSANDRA-11920)
 - * RandomAccessReader: call isEOF() only when rebuffering, not for every read 
operation (CASSANDRA-12013)
   * Don't send erroneous NEW_NODE notifications on restart (CASSANDRA-11038)
   * StorageService shutdown hook should use a volatile variable 
(CASSANDRA-11984)
 +Merged from 2.1:
 + * Cache local ranges when calculating repair neighbors (CASSANDRA-11934)
 + * Allow LWT operation on static column with only partition keys 
(CASSANDRA-10532)
 + * Create interval tree over canonical sstables to avoid missing sstables 
during streaming (CASSANDRA-11886)
 + * cqlsh COPY FROM: shutdown parent cluster after forking, to avoid 
corrupting SSL connections (CASSANDRA-11749)
 +
 +
 +3.0.7
 + * Fix legacy serialization of Thrift-generated non-compound range tombstones
 +   when communicating with 2.x nodes (CASSANDRA-11930)
 + * Fix Directories instantiations where CFS.initialDirectories should be used 
(CASSANDRA-11849)
 + * Avoid referencing DatabaseDescriptor in AbstractType (CASSANDRA-11912)
 + * Fix sstables not being protected from removal during index build 
(CASSANDRA-11905)
 + * cqlsh: Suppress stack trace from Read/WriteFailures (CASSANDRA-11032)
 + * Remove unneeded code to repair index summaries that have
 +   been improperly down-sampled (CASSANDRA-11127)
 + * Avoid WriteTimeoutExceptions during commit log replay due to materialized
 +   view lock contention (CASSANDRA-11891)
 + * Prevent OOM failures on SSTable corruption, improve tests for corruption 
detection (CASSANDRA-9530)
 + * Use CFS.initialDirectories when clearing snapshots (CASSANDRA-11705)
 + * Allow compaction strategies to disable early open (CASSANDRA-11754)
 + * Refactor Materialized View code (CASSANDRA-11475)
 + * Update Java Driver (CASSANDRA-11615)
 +Merged from 2.2:
   * Persist local metadata earlier in startup sequence (CASSANDRA-11742)
   * Run CommitLog tests with different compression settings (CASSANDRA-9039)
   * cqlsh: fix tab completion for case-sensitive identifiers (CASSANDRA-11664)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/621d08a1/src/java/org/apache/cassandra/schema/TableParams.java
--
diff --cc src/java/org/apache/cassandra/schema/TableParams.java
index 7e44e73,000..29d3e29
mode 100644,00..100644
--- a/src/java/org/apache/cassandra/schema/TableParams.java
+++ b/src/java/org/apache/cassandra/schema/TableParams.java
@@@ -1,377 -1,0 +1,380 @@@
 +/*
 + * 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 ownership.  The ASF licenses this file
 + * to you under the Apache License, Version 2.0 (the
 + * "License"); you may not use this file except in compliance
 + * with the License.  You may obtain a copy of the License at
 + *
 + * http://www.apache.org/licenses/LICENSE-2.0
 + *
 + * Unless required by applicable law or agreed to in writing, software
 + * distributed under the License is distributed on an "AS IS" BASIS,
 + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 + * See the License for the specific language governing permissions and
 + * limitations under the License.
 + */
 +package org.apache.cassandra.schema;
 +
 +import java.nio.ByteBuffer;
 +import 

cassandra git commit: Validate bloom_filter_fp_chance during table creation

[tylerhobbs]

Repository: cassandra
Updated Branches:
  refs/heads/cassandra-2.2 5a096274d -> 9e85e85bf


Validate bloom_filter_fp_chance during table creation

Patch by Arinadm Gupta; reviewed by Tyler Hobbs for CASSANDRA-11920


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

Branch: refs/heads/cassandra-2.2
Commit: 9e85e85bf259cc7839226a7c93475505d262946a
Parents: 5a09627
Author: Arindam Gupta 
Authored: Fri Jun 17 16:06:22 2016 -0500
Committer: Tyler Hobbs 
Committed: Tue Jun 21 11:12:15 2016 -0500

--
 CHANGES.txt |  5 +-
 .../cassandra/cql3/statements/CFPropDefs.java   | 13 -
 .../cassandra/utils/BloomCalculations.java  | 15 +-
 .../schema/CreateTableValidationTest.java   | 51 
 4 files changed, 78 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/9e85e85b/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index fe4728d..36009c5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
-<<< HEAD
 2.2.7
+ * Validate bloom_filter_fp_chance against lowest supported
+   value when the table is created (CASSANDRA-11920)
  * RandomAccessReader: call isEOF() only when rebuffering, not for every read 
operation (CASSANDRA-12013)
  * Don't send erroneous NEW_NODE notifications on restart (CASSANDRA-11038)
  * StorageService shutdown hook should use a volatile variable 
(CASSANDRA-11984)
@@ -28,10 +29,8 @@
  * Always close cluster with connection in CqlRecordWriter (CASSANDRA-11553)
  * Fix slice queries on ordered COMPACT tables (CASSANDRA-10988)
 Merged from 2.1:
-===
 2.1.15
  * Remove distinction between non-existing static columns and existing but 
null in LWTs (CASSANDRA-9842)
->>> asf/cassandra-2.1
  * Support mlockall on IBM POWER arch (CASSANDRA-11576)
  * Cache local ranges when calculating repair neighbors (CASSANDRA-11933)
  * Allow LWT operation on static column with only partition keys 
(CASSANDRA-10532)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9e85e85b/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
--
diff --git a/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java 
b/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
index d897cb7..c02e78e 100644
--- a/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CFPropDefs.java
@@ -26,6 +26,7 @@ import 
org.apache.cassandra.db.compaction.AbstractCompactionStrategy;
 import org.apache.cassandra.exceptions.ConfigurationException;
 import org.apache.cassandra.exceptions.SyntaxException;
 import org.apache.cassandra.io.compress.CompressionParameters;
+import org.apache.cassandra.utils.BloomCalculations;
 
 public class CFPropDefs extends PropertyDefinitions
 {
@@ -211,7 +212,17 @@ public class CFPropDefs extends PropertyDefinitions
 cfm.compactionStrategyOptions(new 
HashMap<>(getCompactionOptions()));
 }
 
-cfm.bloomFilterFpChance(getDouble(KW_BF_FP_CHANCE, 
cfm.getBloomFilterFpChance()));
+double bloomFilterFpChance = getDouble(KW_BF_FP_CHANCE, 
cfm.getBloomFilterFpChance());
+double minBloomFilterFpChanceValue = 
BloomCalculations.minSupportedBloomFilterFpChance();
+if (bloomFilterFpChance <=  minBloomFilterFpChanceValue || 
bloomFilterFpChance > 1)
+{
+throw new ConfigurationException(String.format(
+"%s must be larger than %s and less than or equal to 1.0 
(got %s)",
+KW_BF_FP_CHANCE,
+minBloomFilterFpChanceValue,
+bloomFilterFpChance));
+}
+cfm.bloomFilterFpChance(bloomFilterFpChance);
 
 if (!getCompressionOptions().isEmpty())
 
cfm.compressionParameters(CompressionParameters.create(getCompressionOptions()));

http://git-wip-us.apache.org/repos/asf/cassandra/blob/9e85e85b/src/java/org/apache/cassandra/utils/BloomCalculations.java
--
diff --git a/src/java/org/apache/cassandra/utils/BloomCalculations.java 
b/src/java/org/apache/cassandra/utils/BloomCalculations.java
index b73f531..7ba5452 100644
--- a/src/java/org/apache/cassandra/utils/BloomCalculations.java
+++ b/src/java/org/apache/cassandra/utils/BloomCalculations.java
@@ -26,8 +26,8 @@ package org.apache.cassandra.utils;
  * Filter class by helping to choose correct values of 'bits per 

[jira] [Commented] (CASSANDRA-11345) Assertion Errors "Memory was freed" during streaming

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11345:
-

It was just a test cleanup problem (since before there was only one test in the 
suite), so I added a tearDown step, rebased and resubmitted tests:

||2.1||2.2||3.0||trunk||
|[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...pauloricardomg:2.1-11345]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...pauloricardomg:2.2-11345]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...pauloricardomg:3.0-11345]|[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:trunk-11345]|
|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.1-11345-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.2-11345-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-11345-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-11345-testall/lastCompletedBuild/testReport/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.1-11345-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.2-11345-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-11345-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-11345-dtest/lastCompletedBuild/testReport/]|

> Assertion Errors "Memory was freed" during streaming
> 
>
> Key: CASSANDRA-11345
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11345
> Project: Cassandra
>  Issue Type: Bug
>  Components: Streaming and Messaging
>Reporter: Jean-Francois Gosselin
>Assignee: Paulo Motta
>
> We encountered the following AssertionError (twice on the same node) during a 
> repair :
> On node /172.16.63.41
> {noformat}
> INFO  [STREAM-IN-/10.174.216.160] 2016-03-09 02:38:13,900 
> StreamResultFuture.java:180 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Session with /10.174.216.160 is complete  
>   
> WARN  [STREAM-IN-/10.174.216.160] 2016-03-09 02:38:13,900 
> StreamResultFuture.java:207 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Stream failed   
> ERROR [STREAM-OUT-/10.174.216.160] 2016-03-09 02:38:13,906 
> StreamSession.java:505 - [Stream #f6980580-e55f-11e5-8f08-ef9e099ce99e] 
> Streaming error occurred
> java.lang.AssertionError: Memory was freed
>   
>
> at 
> org.apache.cassandra.io.util.SafeMemory.checkBounds(SafeMemory.java:97) 
> ~[apache-cassandra-2.1.13.jar:2.1.13] 
>   
> at org.apache.cassandra.io.util.Memory.getLong(Memory.java:249) 
> ~[apache-cassandra-2.1.13.jar:2.1.13] 
>  
> at 
> org.apache.cassandra.io.compress.CompressionMetadata.getTotalSizeForSections(CompressionMetadata.java:247)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]
> at 
> org.apache.cassandra.streaming.messages.FileMessageHeader.size(FileMessageHeader.java:112)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]
> at 
> org.apache.cassandra.streaming.StreamSession.fileSent(StreamSession.java:546) 
> ~[apache-cassandra-2.1.13.jar:2.1.13] 
> 
> at 
> org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:50)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]  
> at 
> org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:41)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]  
> at 
> org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:45)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]
> at 
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.sendMessage(ConnectionHandler.java:351)
>  ~[apache-cassandra-2.1.13.jar:2.1.13]   
> at 
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.run(ConnectionHandler.java:331)
>  

[jira] [Commented] (CASSANDRA-12007) dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test

[Sean McCarthy (JIRA)]

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

Sean McCarthy commented on CASSANDRA-12007:
---

Duplicate of CASSANDRA-11598

> dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test
> 
>
> Key: CASSANDRA-12007
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12007
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Sean McCarthy
>  Labels: dtest
> Attachments: node1.log, node2.log, node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/229/testReport/cql_tracing_test/TestCqlTracing/tracing_simple_test
> Failed on CassCI build cassandra-2.1_dtest_jdk8 #229
> Logs are attached.
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/cql_tracing_test.py", line 104, in 
> tracing_simple_test
> self.trace(session)
>   File "/home/automaton/cassandra-dtest/cql_tracing_test.py", line 92, in 
> trace
> self.assertIn(' 127.0.0.2 ', out)
>   File "/usr/lib/python2.7/unittest/case.py", line 803, in assertIn
> self.fail(self._formatMessage(msg, standardMsg))
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "' 127.0.0.2 ' not found
> {code}



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

[jira] [Created] (CASSANDRA-12046) dtest failure in repair_tests.repair_test.TestRepair.repair_after_upgrade_test

[Craig Kodman (JIRA)]

Craig Kodman created CASSANDRA-12046:


 Summary: dtest failure in 
repair_tests.repair_test.TestRepair.repair_after_upgrade_test
 Key: CASSANDRA-12046
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12046
 Project: Cassandra
  Issue Type: Test
Reporter: Craig Kodman
Assignee: DS Test Eng


example failure:

http://cassci.datastax.com/job/cassandra-3.0_dtest_win32/258/testReport/repair_tests.repair_test/TestRepair/repair_after_upgrade_test

Failed on CassCI build cassandra-3.0_dtest_win32 #258



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

[jira] [Assigned] (CASSANDRA-12007) dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test

[Sean McCarthy (JIRA)]

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

Sean McCarthy reassigned CASSANDRA-12007:
-

Assignee: Sean McCarthy  (was: DS Test Eng)

> dtest failure in cql_tracing_test.TestCqlTracing.tracing_simple_test
> 
>
> Key: CASSANDRA-12007
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12007
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Sean McCarthy
>  Labels: dtest
> Attachments: node1.log, node2.log, node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_dtest_jdk8/229/testReport/cql_tracing_test/TestCqlTracing/tracing_simple_test
> Failed on CassCI build cassandra-2.1_dtest_jdk8 #229
> Logs are attached.
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/cql_tracing_test.py", line 104, in 
> tracing_simple_test
> self.trace(session)
>   File "/home/automaton/cassandra-dtest/cql_tracing_test.py", line 92, in 
> trace
> self.assertIn(' 127.0.0.2 ', out)
>   File "/usr/lib/python2.7/unittest/case.py", line 803, in assertIn
> self.fail(self._formatMessage(msg, standardMsg))
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "' 127.0.0.2 ' not found
> {code}



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

[jira] [Commented] (CASSANDRA-12024) dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_copy_to_with_child_process_crashing

[Sean McCarthy (JIRA)]

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

Sean McCarthy commented on CASSANDRA-12024:
---

{code}out, err = self.node1.run_cqlsh(cmds="COPY {} TO 
'{}'".format(stress_table, tempfile.name), return_output=True)
{code}

err is an empty string, which I'm interpreting as run_cqlsh having no errors, 
which we were expecting. Possibly a bug, [~philipthompson]?

> dtest failure in 
> cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_copy_to_with_child_process_crashing
> 
>
> Key: CASSANDRA-12024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12024
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Sean McCarthy
>  Labels: dtest
> Attachments: node1.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/360/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_copy_to_with_child_process_crashing
> Failed on CassCI build cassandra-2.1_offheap_dtest #360
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/dtest.py", line 889, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2701, in test_copy_to_with_child_process_crashing
> self.assertIn('some records might be missing', err)
>   File "/usr/lib/python2.7/unittest/case.py", line 803, in assertIn
> self.fail(self._formatMessage(msg, standardMsg))
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> Error Message
> 'some records might be missing' not found in ''
> {code}
> Logs are attached.



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

[jira] [Resolved] (CASSANDRA-12022) dtest failure in repair_tests.repair_test.TestRepair.simple_repair_order_preserving_test

[Philip Thompson (JIRA)]

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

Philip Thompson resolved CASSANDRA-12022.
-
Resolution: Fixed
  Reviewer: Philip Thompson

> dtest failure in 
> repair_tests.repair_test.TestRepair.simple_repair_order_preserving_test
> 
>
> Key: CASSANDRA-12022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12022
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Sean McCarthy
>Priority: Trivial
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/254/testReport/repair_tests.repair_test/TestRepair/simple_repair_order_preserving_test
> Failed on CassCI build cassandra-2.1_novnode_dtest #254
> Cluster doesn't exist when called.
> {code}
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 225, in simple_repair_order_preserving_test
> self._simple_repair(order_preserving_partitioner=True)
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 273, in _simple_repair
> cluster.set_partitioner('org.apache.cassandra.dht.ByteOrderedPartitioner')
> "global name 'cluster' is not defined
> {code}
> The call to cluster is wrapped in an if clause, but isn't defined before that.



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

[jira] [Assigned] (CASSANDRA-12024) dtest failure in cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_copy_to_with_child_process_crashing

[Sean McCarthy (JIRA)]

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

Sean McCarthy reassigned CASSANDRA-12024:
-

Assignee: Sean McCarthy  (was: DS Test Eng)

> dtest failure in 
> cqlsh_tests.cqlsh_copy_tests.CqlshCopyTest.test_copy_to_with_child_process_crashing
> 
>
> Key: CASSANDRA-12024
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12024
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Sean McCarthy
>  Labels: dtest
> Attachments: node1.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_offheap_dtest/360/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_copy_to_with_child_process_crashing
> Failed on CassCI build cassandra-2.1_offheap_dtest #360
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/dtest.py", line 889, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_copy_tests.py", 
> line 2701, in test_copy_to_with_child_process_crashing
> self.assertIn('some records might be missing', err)
>   File "/usr/lib/python2.7/unittest/case.py", line 803, in assertIn
> self.fail(self._formatMessage(msg, standardMsg))
>   File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> Error Message
> 'some records might be missing' not found in ''
> {code}
> Logs are attached.



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

[jira] [Commented] (CASSANDRA-12022) dtest failure in repair_tests.repair_test.TestRepair.simple_repair_order_preserving_test

[Sean McCarthy (JIRA)]

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

Sean McCarthy commented on CASSANDRA-12022:
---

Fix-12022 being tested: 
http://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/132

> dtest failure in 
> repair_tests.repair_test.TestRepair.simple_repair_order_preserving_test
> 
>
> Key: CASSANDRA-12022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12022
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: Sean McCarthy
>Priority: Trivial
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.1_novnode_dtest/254/testReport/repair_tests.repair_test/TestRepair/simple_repair_order_preserving_test
> Failed on CassCI build cassandra-2.1_novnode_dtest #254
> Cluster doesn't exist when called.
> {code}
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 225, in simple_repair_order_preserving_test
> self._simple_repair(order_preserving_partitioner=True)
>   File "/home/automaton/cassandra-dtest/repair_tests/repair_test.py", line 
> 273, in _simple_repair
> cluster.set_partitioner('org.apache.cassandra.dht.ByteOrderedPartitioner')
> "global name 'cluster' is not defined
> {code}
> The call to cluster is wrapped in an if clause, but isn't defined before that.



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

[jira] [Updated] (CASSANDRA-11537) Give clear error when certain nodetool commands are issued before server is ready

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11537:

Status: In Progress  (was: Ready to Commit)

> Give clear error when certain nodetool commands are issued before server is 
> ready
> -
>
> Key: CASSANDRA-11537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11537
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>Priority: Minor
>  Labels: lhf
>
> As an ops person upgrading and servicing Cassandra servers, I require a more 
> clear message when I issue a nodetool command that the server is not ready 
> for it so that I am not confused.
> Technical description:
> If you deploy a new binary, restart, and issue nodetool 
> scrub/compact/updatess etc you get unfriendly assertion. An exception would 
> be easier to understand. Also if a user has turned assertions off it is 
> unclear what might happen. 
> {noformat}
> EC1: Throw exception to make it clear server is still in start up process. 
> :~# nodetool upgradesstables
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:97)
> at 
> org.apache.cassandra.service.StorageService.getValidKeyspace(StorageService.java:2573)
> at 
> org.apache.cassandra.service.StorageService.getValidColumnFamilies(StorageService.java:2661)
> at 
> org.apache.cassandra.service.StorageService.upgradeSSTables(StorageService.java:2421)
> {noformat}
> EC1: 
> Patch against 2.1 (branch)
> https://github.com/apache/cassandra/compare/trunk...edwardcapriolo:exception-on-startup?expand=1



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

[jira] [Commented] (CASSANDRA-12034) Special handling for Netty's direct memory allocation failure

[T Jake Luciani (JIRA)]

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

T Jake Luciani commented on CASSANDRA-12034:


I think we should be careful here since this is adding a new kind of error for 
users to think about.

How is this not a destabilizing condition?  We don't know if it's this users 
response or another that's taking up the memory, or when it will resolve.  
  

> Special handling for Netty's direct memory allocation failure
> -
>
> Key: CASSANDRA-12034
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12034
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Fix For: 3.x
>
>
> With CASSANDRA-12032, Netty throws a 
> {{io.netty.util.internal.OutOfDirectMemoryError}} if there's not enough 
> off-heap memory for the response buffer. We can easily handle this situation 
> and return an error. This is not a condition that destabilizes the system and 
> should therefore not passed to {{JVMStabilityInspector}}.



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

[jira] [Commented] (CASSANDRA-11969) Prevent duplicate ctx.channel().attr() call

[T Jake Luciani (JIRA)]

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

T Jake Luciani commented on CASSANDRA-11969:


+1

> Prevent duplicate ctx.channel().attr() call
> ---
>
> Key: CASSANDRA-11969
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11969
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Trivial
> Fix For: 3.x
>
>
> In {{Frame}} we can save one call to 
> {{ctx.channel().attr(Connection.attributeKey)}}.
> (Will provide a patch soon)



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

[jira] [Commented] (CASSANDRA-12038) dtest failure in batch_test.TestBatch.logged_batch_compatibility_3_test

[Sean McCarthy (JIRA)]

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

Sean McCarthy commented on CASSANDRA-12038:
---

Looks like the cassandra.pid file was never created. Failure happens in 
_update_pid(), when trying to get the pid from cassandra.pid. Possibly a bug, 
[~philipthompson]?

> dtest failure in batch_test.TestBatch.logged_batch_compatibility_3_test
> ---
>
> Key: CASSANDRA-12038
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12038
> Project: Cassandra
>  Issue Type: Test
>Reporter: Craig Kodman
>Assignee: Sean McCarthy
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/252/testReport/batch_test/TestBatch/logged_batch_compatibility_3_test
> Failed on CassCI build cassandra-3.0_novnode_dtest #252



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

[jira] [Updated] (CASSANDRA-11971) More uses of DataOutputBuffer.RECYCLER

[Robert Stupp (JIRA)]

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

Robert Stupp updated CASSANDRA-11971:
-
   Resolution: Fixed
Fix Version/s: (was: 3.x)
   3.8
   Status: Resolved  (was: Patch Available)

Thanks!
Committed as 
[063e91754b22a28a43efccb0c238c577a6bd0b8a|https://github.com/apache/cassandra/commit/063e91754b22a28a43efccb0c238c577a6bd0b8a]
 to [trunk|https://github.com/apache/cassandra/tree/trunk]


> More uses of DataOutputBuffer.RECYCLER
> --
>
> Key: CASSANDRA-11971
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11971
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
>Priority: Minor
> Fix For: 3.8
>
>
> There are a few more possible use cases for {{DataOutputBuffer.RECYCLER}}, 
> which prevents a couple of (larger) allocations.
> (Will provide a patch soon)



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

cassandra git commit: More uses of DataOutputBuffer.RECYCLER

[snazy]

Repository: cassandra
Updated Branches:
  refs/heads/trunk e8d7fe8a2 -> 063e91754


More uses of DataOutputBuffer.RECYCLER

patch by Robert Stupp; reviewed by T Jake Luciani for CASSANDRA-11971


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

Branch: refs/heads/trunk
Commit: 063e91754b22a28a43efccb0c238c577a6bd0b8a
Parents: e8d7fe8
Author: Robert Stupp 
Authored: Tue Jun 21 16:50:54 2016 +0200
Committer: Robert Stupp 
Committed: Tue Jun 21 16:50:54 2016 +0200

--
 src/java/org/apache/cassandra/db/SystemKeyspace.java| 9 +++--
 .../org/apache/cassandra/db/partitions/PartitionUpdate.java | 2 +-
 src/java/org/apache/cassandra/hints/HintsWriter.java| 7 ++-
 src/java/org/apache/cassandra/io/util/DataOutputBuffer.java | 5 +
 src/java/org/apache/cassandra/service/StorageProxy.java | 7 ++-
 5 files changed, 25 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/063e9175/src/java/org/apache/cassandra/db/SystemKeyspace.java
--
diff --git a/src/java/org/apache/cassandra/db/SystemKeyspace.java 
b/src/java/org/apache/cassandra/db/SystemKeyspace.java
index 026eba1..1203834 100644
--- a/src/java/org/apache/cassandra/db/SystemKeyspace.java
+++ b/src/java/org/apache/cassandra/db/SystemKeyspace.java
@@ -640,16 +640,21 @@ public final class SystemKeyspace
 
 private static Map 
truncationAsMapEntry(ColumnFamilyStore cfs, long truncatedAt, CommitLogPosition 
position)
 {
-try (DataOutputBuffer out = new DataOutputBuffer())
+DataOutputBuffer out = null;
+try (DataOutputBuffer ignored = out = DataOutputBuffer.RECYCLER.get())
 {
 CommitLogPosition.serializer.serialize(position, out);
 out.writeLong(truncatedAt);
-return singletonMap(cfs.metadata.cfId, 
ByteBuffer.wrap(out.getData(), 0, out.getLength()));
+return singletonMap(cfs.metadata.cfId, out.asNewBuffer());
 }
 catch (IOException e)
 {
 throw new RuntimeException(e);
 }
+finally
+{
+out.recycle();
+}
 }
 
 public static CommitLogPosition getTruncatedPosition(UUID cfId)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/063e9175/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
--
diff --git a/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java 
b/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
index aacf4f9..d18392c 100644
--- a/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
+++ b/src/java/org/apache/cassandra/db/partitions/PartitionUpdate.java
@@ -274,7 +274,7 @@ public class PartitionUpdate extends AbstractBTreePartition
 try (DataOutputBuffer out = new DataOutputBuffer())
 {
 serializer.serialize(update, out, version);
-return ByteBuffer.wrap(out.getData(), 0, out.getLength());
+return out.asNewBuffer();
 }
 catch (IOException e)
 {

http://git-wip-us.apache.org/repos/asf/cassandra/blob/063e9175/src/java/org/apache/cassandra/hints/HintsWriter.java
--
diff --git a/src/java/org/apache/cassandra/hints/HintsWriter.java 
b/src/java/org/apache/cassandra/hints/HintsWriter.java
index b4da379..ae9e05a 100644
--- a/src/java/org/apache/cassandra/hints/HintsWriter.java
+++ b/src/java/org/apache/cassandra/hints/HintsWriter.java
@@ -74,7 +74,8 @@ class HintsWriter implements AutoCloseable
 
 CRC32 crc = new CRC32();
 
-try (DataOutputBuffer dob = new DataOutputBuffer())
+DataOutputBuffer dob = null;
+try (DataOutputBuffer ignored = dob = DataOutputBuffer.RECYCLER.get())
 {
 // write the descriptor
 descriptor.serialize(dob);
@@ -87,6 +88,10 @@ class HintsWriter implements AutoCloseable
 channel.close();
 throw e;
 }
+finally
+{
+dob.recycle();
+}
 
 if (descriptor.isEncrypted())
 return new EncryptedHintsWriter(directory, descriptor, file, 
channel, fd, crc);

http://git-wip-us.apache.org/repos/asf/cassandra/blob/063e9175/src/java/org/apache/cassandra/io/util/DataOutputBuffer.java
--
diff --git a/src/java/org/apache/cassandra/io/util/DataOutputBuffer.java 

[jira] [Commented] (CASSANDRA-11937) Clean up buffer trimming large buffers in DataOutputBuffer after the Netty upgrade

[Robert Stupp (JIRA)]

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

Robert Stupp commented on CASSANDRA-11937:
--

Netty 4.0.37 is now in trunk.

> Clean up buffer trimming large buffers in DataOutputBuffer after the Netty 
> upgrade
> --
>
> Key: CASSANDRA-11937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11937
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>  Labels: lhf, netty, reminder
>
> In [https://issues.apache.org/jira/browse/CASSANDRA-11838|11838], we're 
> trimming the large buffers in {{DataOutputBuffer}}. The patch is already 
> submitted and merged in [Netty 
> 4.1|https://github.com/netty/netty/commit/bbed330468b5b82c9e4defa59012d0fcdb70f1aa],
>  we only need to make sure that we throw large buffers away1 alltogether 
> instead of trimming them.



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

cassandra git commit: Update to Netty 4.0.37

[snazy]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 448389207 -> e8d7fe8a2


Update to Netty 4.0.37

patch by Robert Stupp; reviewed by T Jake Luciani for CASSANDRA-12032


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

Branch: refs/heads/trunk
Commit: e8d7fe8a289e16d18a83e598c589347ec080029f
Parents: 4483892
Author: Robert Stupp 
Authored: Tue Jun 21 16:47:37 2016 +0200
Committer: Robert Stupp 
Committed: Tue Jun 21 16:47:37 2016 +0200

--
 build.xml   |   2 +-
 conf/cassandra-env.ps1  |   9 ++
 conf/cassandra-env.sh   |   9 ++
 lib/licenses/netty-all-4.0.36.Final.txt | 202 ---
 lib/licenses/netty-all-4.0.37.Final.txt | 202 +++
 lib/netty-all-4.0.36.Final.jar  | Bin 2195921 -> 0 bytes
 lib/netty-all-4.0.37.Final.jar  | Bin 0 -> 2204062 bytes
 7 files changed, 221 insertions(+), 203 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/e8d7fe8a/build.xml
--
diff --git a/build.xml b/build.xml
index 4eb1f1f..9dab8ac 100644
--- a/build.xml
+++ b/build.xml
@@ -413,7 +413,7 @@
   
   
   
-  
+  
   
   
   

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e8d7fe8a/conf/cassandra-env.ps1
--
diff --git a/conf/cassandra-env.ps1 b/conf/cassandra-env.ps1
index 9373ba6..8c4311c 100644
--- a/conf/cassandra-env.ps1
+++ b/conf/cassandra-env.ps1
@@ -350,6 +350,15 @@ Function SetCassandraEnvironment
 #$env:HEAP_NEWSIZE="800M"
 CalculateHeapSizes
 
+# Direct memory used for native-protocol network I/O is no longer
+# managed by the JVM. Instead, Netty allows three options to
+# manage it via the system property io.netty.maxDirectMemory:
+# == 0  behavior as before, uses JVM to manage direct memory (slowest).
+# < 0   manages direct memory directly, max direct memory as 
-XX:MaxDirectMemorySize.
+# > 0   manages direct memory directly, max direct memory as specified.
+#   Note, that appreviations like 2g or 500m are NOT accepted.
+#$env:JVM_OPTS="$env:JVM_OPTS -Dio.netty.maxDirectMemory=2147483648"
+
 ParseJVMInfo
 
 # We only set -Xms and -Xmx if they were not defined on jvm.options file

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e8d7fe8a/conf/cassandra-env.sh
--
diff --git a/conf/cassandra-env.sh b/conf/cassandra-env.sh
index 93434c9..6d5de21 100644
--- a/conf/cassandra-env.sh
+++ b/conf/cassandra-env.sh
@@ -167,6 +167,15 @@ USING_G1=$?
 # Set this to control the amount of arenas per-thread in glibc
 #export MALLOC_ARENA_MAX=4
 
+# Direct memory used for native-protocol network I/O is no longer
+# managed by the JVM. Instead, Netty allows three options to
+# manage it via the system property io.netty.maxDirectMemory:
+# == 0  behavior as before, uses JVM to manage direct memory (slowest).
+# < 0   manages direct memory directly, max direct memory as 
-XX:MaxDirectMemorySize.
+# > 0   manages direct memory directly, max direct memory as specified.
+#   Note, that appreviations like 2g or 500m are NOT accepted.
+#export JVM_OPTS="$JVM_OPTS -Dio.netty.maxDirectMemory=2147483648"
+
 # only calculate the size if it's not set manually
 if [ "x$MAX_HEAP_SIZE" = "x" ] && [ "x$HEAP_NEWSIZE" = "x" -o $USING_G1 -eq 0 
]; then
 calculate_heap_sizes

http://git-wip-us.apache.org/repos/asf/cassandra/blob/e8d7fe8a/lib/licenses/netty-all-4.0.36.Final.txt
--
diff --git a/lib/licenses/netty-all-4.0.36.Final.txt 
b/lib/licenses/netty-all-4.0.36.Final.txt
deleted file mode 100644
index d645695..000
--- a/lib/licenses/netty-all-4.0.36.Final.txt
+++ /dev/null
@@ -1,202 +0,0 @@
-
- Apache License
-   Version 2.0, January 2004
-http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-  "License" shall mean the terms and conditions for use, reproduction,
-  and distribution as defined by Sections 1 through 9 of this document.
-
-  "Licensor" shall mean the copyright owner or entity authorized by
-  the copyright owner that is granting the License.
-
-  "Legal Entity" shall mean the union of the acting 

[jira] [Updated] (CASSANDRA-12032) Update to Netty 4.0.37

[Robert Stupp (JIRA)]

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

Robert Stupp updated CASSANDRA-12032:
-
   Resolution: Fixed
Fix Version/s: (was: 3.x)
   3.8
   Status: Resolved  (was: Patch Available)

Thanks!
Committed as 
[e8d7fe8a289e16d18a83e598c589347ec080029f|https://github.com/apache/cassandra/commit/e8d7fe8a289e16d18a83e598c589347ec080029f]
 to [trunk|https://github.com/apache/cassandra/tree/trunk]


> Update to Netty 4.0.37
> --
>
> Key: CASSANDRA-12032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12032
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Robert Stupp
>Assignee: Robert Stupp
> Fix For: 3.8
>
>
> Update Netty to 4.0.37
> (no C* code changes in this ticket)



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

[jira] [Assigned] (CASSANDRA-12038) dtest failure in batch_test.TestBatch.logged_batch_compatibility_3_test

[Sean McCarthy (JIRA)]

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

Sean McCarthy reassigned CASSANDRA-12038:
-

Assignee: Sean McCarthy  (was: DS Test Eng)

> dtest failure in batch_test.TestBatch.logged_batch_compatibility_3_test
> ---
>
> Key: CASSANDRA-12038
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12038
> Project: Cassandra
>  Issue Type: Test
>Reporter: Craig Kodman
>Assignee: Sean McCarthy
>  Labels: dtest
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/252/testReport/batch_test/TestBatch/logged_batch_compatibility_3_test
> Failed on CassCI build cassandra-3.0_novnode_dtest #252



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

[jira] [Updated] (CASSANDRA-9842) Inconsistent behavior for '= null' conditions on static columns

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-9842:
--
Attachment: 9842-3.0.txt
9842-2.1.txt

> Inconsistent behavior for '= null' conditions on static columns
> ---
>
> Key: CASSANDRA-9842
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9842
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: cassandra-2.1.8 on Ubuntu 15.04
>Reporter: Chandra Sekar
>Assignee: Alex Petrov
> Fix For: 2.1.15, 2.2.7, 3.8, 3.0.8
>
> Attachments: 9842-2.1.txt, 9842-3.0.txt
>
>
> Both inserting a row (in a non-existent partition) and updating a static 
> column in the same LWT fails. Creating the partition before performing the 
> LWT works.
> h3. Table Definition
> {code}
> create table txtable(pcol bigint, ccol bigint, scol bigint static, ncol text, 
> primary key((pcol), ccol));
> {code}
> h3. Inserting row in non-existent partition and updating static column in one 
> LWT
> {code}
> begin batch
> insert into txtable (pcol, ccol, ncol) values (1, 1, 'A');
> update txtable set scol = 1 where pcol = 1 if scol = null;
> apply batch;
> [applied]
> ---
>  False
> {code}
> h3. Creating partition before LWT
> {code}
> insert into txtable (pcol, scol) values (1, null) if not exists;
> begin batch
> insert into txtable (pcol, ccol, ncol) values (1, 1, 'A');
> update txtable set scol = 1 where pcol = 1 if scol = null;
> apply batch;
> [applied]
> ---
>  True
> {code}



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

[jira] [Updated] (CASSANDRA-9842) Inconsistent behavior for '= null' conditions on static columns

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-9842:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Committed into 2.1 at 85f2bbfd1c6803977ecc1c2053527363078bce22 and merge into 
2.2, 3.0 and trunk

> Inconsistent behavior for '= null' conditions on static columns
> ---
>
> Key: CASSANDRA-9842
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9842
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: cassandra-2.1.8 on Ubuntu 15.04
>Reporter: Chandra Sekar
>Assignee: Alex Petrov
> Fix For: 2.1.15, 2.2.7, 3.8, 3.0.8
>
>
> Both inserting a row (in a non-existent partition) and updating a static 
> column in the same LWT fails. Creating the partition before performing the 
> LWT works.
> h3. Table Definition
> {code}
> create table txtable(pcol bigint, ccol bigint, scol bigint static, ncol text, 
> primary key((pcol), ccol));
> {code}
> h3. Inserting row in non-existent partition and updating static column in one 
> LWT
> {code}
> begin batch
> insert into txtable (pcol, ccol, ncol) values (1, 1, 'A');
> update txtable set scol = 1 where pcol = 1 if scol = null;
> apply batch;
> [applied]
> ---
>  False
> {code}
> h3. Creating partition before LWT
> {code}
> insert into txtable (pcol, scol) values (1, null) if not exists;
> begin batch
> insert into txtable (pcol, ccol, ncol) values (1, 1, 'A');
> update txtable set scol = 1 where pcol = 1 if scol = null;
> apply batch;
> [applied]
> ---
>  True
> {code}



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

[jira] [Updated] (CASSANDRA-9842) Inconsistent behavior for '= null' conditions on static columns

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-9842:
--
Fix Version/s: (was: 3.0.x)
   (was: 2.2.x)
   (was: 2.1.x)
   (was: 3.x)
   3.0.8
   3.8
   2.2.7
   2.1.15

> Inconsistent behavior for '= null' conditions on static columns
> ---
>
> Key: CASSANDRA-9842
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9842
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: cassandra-2.1.8 on Ubuntu 15.04
>Reporter: Chandra Sekar
>Assignee: Alex Petrov
> Fix For: 2.1.15, 2.2.7, 3.8, 3.0.8
>
>
> Both inserting a row (in a non-existent partition) and updating a static 
> column in the same LWT fails. Creating the partition before performing the 
> LWT works.
> h3. Table Definition
> {code}
> create table txtable(pcol bigint, ccol bigint, scol bigint static, ncol text, 
> primary key((pcol), ccol));
> {code}
> h3. Inserting row in non-existent partition and updating static column in one 
> LWT
> {code}
> begin batch
> insert into txtable (pcol, ccol, ncol) values (1, 1, 'A');
> update txtable set scol = 1 where pcol = 1 if scol = null;
> apply batch;
> [applied]
> ---
>  False
> {code}
> h3. Creating partition before LWT
> {code}
> insert into txtable (pcol, scol) values (1, null) if not exists;
> begin batch
> insert into txtable (pcol, ccol, ncol) values (1, 1, 'A');
> update txtable set scol = 1 where pcol = 1 if scol = null;
> apply batch;
> [applied]
> ---
>  True
> {code}



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

[jira] [Updated] (CASSANDRA-9842) Inconsistent behavior for '= null' conditions on static columns

[Benjamin Lerer (JIRA)]

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

Benjamin Lerer updated CASSANDRA-9842:
--
Component/s: CQL

> Inconsistent behavior for '= null' conditions on static columns
> ---
>
> Key: CASSANDRA-9842
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9842
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL
> Environment: cassandra-2.1.8 on Ubuntu 15.04
>Reporter: Chandra Sekar
>Assignee: Alex Petrov
> Fix For: 2.1.15, 2.2.7, 3.8, 3.0.8
>
>
> Both inserting a row (in a non-existent partition) and updating a static 
> column in the same LWT fails. Creating the partition before performing the 
> LWT works.
> h3. Table Definition
> {code}
> create table txtable(pcol bigint, ccol bigint, scol bigint static, ncol text, 
> primary key((pcol), ccol));
> {code}
> h3. Inserting row in non-existent partition and updating static column in one 
> LWT
> {code}
> begin batch
> insert into txtable (pcol, ccol, ncol) values (1, 1, 'A');
> update txtable set scol = 1 where pcol = 1 if scol = null;
> apply batch;
> [applied]
> ---
>  False
> {code}
> h3. Creating partition before LWT
> {code}
> insert into txtable (pcol, scol) values (1, null) if not exists;
> begin batch
> insert into txtable (pcol, ccol, ncol) values (1, 1, 'A');
> update txtable set scol = 1 where pcol = 1 if scol = null;
> apply batch;
> [applied]
> ---
>  True
> {code}



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

[4/4] cassandra git commit: Merge branch cassandra-3.0 into trunk

[blerer]

Merge branch cassandra-3.0 into trunk


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

Branch: refs/heads/trunk
Commit: 44838920709e0333ec105c299fa8cbb1f0905f93
Parents: 5382f4e 723a143
Author: Benjamin Lerer 
Authored: Tue Jun 21 16:33:12 2016 +0200
Committer: Benjamin Lerer 
Committed: Tue Jun 21 16:33:25 2016 +0200

--
 .../operations/InsertUpdateIfConditionTest.java | 290 +++
 1 file changed, 290 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/44838920/test/unit/org/apache/cassandra/cql3/validation/operations/InsertUpdateIfConditionTest.java
--

[3/4] cassandra git commit: Merge branch cassandra-2.2 into cassandra-3.0

[blerer]

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/723a143c
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/723a143c
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/723a143c

Branch: refs/heads/trunk
Commit: 723a143c9d71ba8b3450cad8a0ad178f133a3869
Parents: b657223 5a09627
Author: Benjamin Lerer 
Authored: Tue Jun 21 16:28:25 2016 +0200
Committer: Benjamin Lerer 
Committed: Tue Jun 21 16:30:06 2016 +0200

--
 .../operations/InsertUpdateIfConditionTest.java | 290 +++
 1 file changed, 290 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/723a143c/test/unit/org/apache/cassandra/cql3/validation/operations/InsertUpdateIfConditionTest.java
--
diff --cc 
test/unit/org/apache/cassandra/cql3/validation/operations/InsertUpdateIfConditionTest.java
index 2d59a11,fc6cc2e..a1ee4f8
--- 
a/test/unit/org/apache/cassandra/cql3/validation/operations/InsertUpdateIfConditionTest.java
+++ 
b/test/unit/org/apache/cassandra/cql3/validation/operations/InsertUpdateIfConditionTest.java
@@@ -23,10 -23,8 +23,11 @@@ import org.junit.Test
  import org.apache.cassandra.cql3.CQLTester;
  import org.apache.cassandra.exceptions.InvalidRequestException;
  import org.apache.cassandra.exceptions.SyntaxException;
 +import org.apache.cassandra.schema.SchemaKeyspace;
  
 +import static java.lang.String.format;
  import static org.junit.Assert.assertEquals;
++import static org.junit.Assert.assertThat;
  import static org.junit.Assert.assertTrue;
  
  public class InsertUpdateIfConditionTest extends CQLTester
@@@ -1018,10 -979,295 +1019,299 @@@
  
  // drop and confirm
  execute("DROP TYPE IF EXISTS mytype");
 -assertEmpty(execute("SELECT type_name from system.schema_usertypes 
where keyspace_name = ? and type_name = ?", KEYSPACE, "mytype"));
 +assertEmpty(execute(format("SELECT type_name from %s.%s where 
keyspace_name = ? and type_name = ?",
 +   SchemaKeyspace.NAME,
 +   SchemaKeyspace.TYPES),
 +KEYSPACE,
 +"mytype"));
  }
+ 
+ @Test
+ public void testConditionalUpdatesOnStaticColumns() throws Throwable
+ {
+ createTable("CREATE TABLE %s (a int, b int, s int static, d text, 
PRIMARY KEY (a, b))");
+ 
+ // pre-existing row
+ execute("INSERT INTO %s (a, b, s, d) values (6, 6, 100, 'a')");
+ assertRows(execute("UPDATE %s SET s = 6 WHERE a = 6 IF s = 100"),
+row(true));
+ assertRows(execute("SELECT * FROM %s WHERE a = 6"),
+row(6, 6, 6, "a"));
+ 
+ // pre-existing row with null in the static column
+ execute("INSERT INTO %s (a, b, d) values (7, 7, 'a')");
+ assertRows(execute("UPDATE %s SET s = 7 WHERE a = 7 IF s = NULL"),
+row(true));
+ assertRows(execute("SELECT * FROM %s WHERE a = 7"),
+row(7, 7, 7, "a"));
+ 
+ // deleting row before CAS
+ execute("DELETE FROM %s WHERE a = 8;");
+ assertRows(execute("UPDATE %s SET s = 8 WHERE a = 8 IF s = NULL"),
+row(true));
+ assertRows(execute("SELECT * FROM %s WHERE a = 8"),
+row(8, null, 8, null));
+ }
+ 
+ @Test
+ public void testConditionalUpdatesWithNullValues() throws Throwable
+ {
+ createTable("CREATE TABLE %s (a int, b int, s int static, d text, 
PRIMARY KEY (a, b))");
+ 
+ // pre-populate, leave out static column
+ for (int i = 1; i <= 5; i++)
+ execute("INSERT INTO %s (a, b) VALUES (?, ?)", i, i);
+ 
+ conditionalUpdatesWithNonExistingOrNullValues();
+ 
+ // rejected: IN doesn't contain null
+ assertRows(execute("UPDATE %s SET s = 30 WHERE a = 3 IF s IN 
(10,20,30)"),
+row(false));
+ assertRows(execute("SELECT * FROM %s WHERE a = 3"),
+row(3, 3, null, null));
+ 
+ // rejected: comparing number with NULL always returns false
+ for (String operator: new String[] { ">", "<", ">=", "<=", "="})
+ {
+ assertRows(execute("UPDATE %s SET s = 50 WHERE a = 5 IF s " + 
operator + " 3"),
+row(false));
+ assertRows(execute("SELECT * FROM %s WHERE a = 5"),
+row(5, 5, null, null));
+ }
+ 
+ }
+ 
+ @Test
+ public void testConditionalUpdatesWithNonExistingValues() throws Throwable
+ {
+ createTable("CREATE TABLE %s (a int, b int, s int static, d text, 
PRIMARY KEY 

[2/4] cassandra git commit: Merge branch cassandra-2.1 into cassandra-2.2

[blerer]

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/5a096274
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5a096274
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5a096274

Branch: refs/heads/trunk
Commit: 5a096274dc592c35efe0dfaa12bf4bc40b02402b
Parents: 68398ad 85f2bbf
Author: Benjamin Lerer 
Authored: Tue Jun 21 16:25:23 2016 +0200
Committer: Benjamin Lerer 
Committed: Tue Jun 21 16:25:23 2016 +0200

--
 CHANGES.txt |   5 +
 .../cql3/statements/ModificationStatement.java  |   5 +-
 .../apache/cassandra/service/StorageProxy.java  |   5 +-
 .../operations/InsertUpdateIfConditionTest.java | 291 ++-
 4 files changed, 302 insertions(+), 4 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5a096274/CHANGES.txt
--
diff --cc CHANGES.txt
index ef993fe,7944967..fe4728d
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,32 -1,5 +1,37 @@@
++<<< HEAD
 +2.2.7
 + * RandomAccessReader: call isEOF() only when rebuffering, not for every read 
operation (CASSANDRA-12013)
 + * Don't send erroneous NEW_NODE notifications on restart (CASSANDRA-11038)
 + * StorageService shutdown hook should use a volatile variable 
(CASSANDRA-11984)
 + * Persist local metadata earlier in startup sequence (CASSANDRA-11742)
 + * Run CommitLog tests with different compression settings (CASSANDRA-9039)
 + * cqlsh: fix tab completion for case-sensitive identifiers (CASSANDRA-11664)
 + * Avoid showing estimated key as -1 in tablestats (CASSANDRA-11587)
 + * Fix possible race condition in CommitLog.recover (CASSANDRA-11743)
 + * Enable client encryption in sstableloader with cli options 
(CASSANDRA-11708)
 + * Possible memory leak in NIODataInputStream (CASSANDRA-11867)
 + * Fix commit log replay after out-of-order flush completion (CASSANDRA-9669)
 + * Add seconds to cqlsh tracing session duration (CASSANDRA-11753)
 + * Prohibit Reverse Counter type as part of the PK (CASSANDRA-9395)
 + * cqlsh: correctly handle non-ascii chars in error messages (CASSANDRA-11626)
 + * Exit JVM if JMX server fails to startup (CASSANDRA-11540)
 + * Produce a heap dump when exiting on OOM (CASSANDRA-9861)
 + * Avoid read repairing purgeable tombstones on range slices (CASSANDRA-11427)
 + * Restore ability to filter on clustering columns when using a 2i 
(CASSANDRA-11510)
 + * JSON datetime formatting needs timezone (CASSANDRA-11137)
 + * Fix is_dense recalculation for Thrift-updated tables (CASSANDRA-11502)
 + * Remove unnescessary file existence check during anticompaction 
(CASSANDRA-11660)
 + * Add missing files to debian packages (CASSANDRA-11642)
 + * Avoid calling Iterables::concat in loops during 
ModificationStatement::getFunctions (CASSANDRA-11621)
 + * cqlsh: COPY FROM should use regular inserts for single statement batches 
and
 +   report errors correctly if workers processes crash on initialization 
(CASSANDRA-11474)
 + * Always close cluster with connection in CqlRecordWriter (CASSANDRA-11553)
 + * Fix slice queries on ordered COMPACT tables (CASSANDRA-10988)
 +Merged from 2.1:
++===
+ 2.1.15
+  * Remove distinction between non-existing static columns and existing but 
null in LWTs (CASSANDRA-9842)
++>>> asf/cassandra-2.1
   * Support mlockall on IBM POWER arch (CASSANDRA-11576)
   * Cache local ranges when calculating repair neighbors (CASSANDRA-11933)
   * Allow LWT operation on static column with only partition keys 
(CASSANDRA-10532)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5a096274/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5a096274/src/java/org/apache/cassandra/service/StorageProxy.java
--

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5a096274/test/unit/org/apache/cassandra/cql3/validation/operations/InsertUpdateIfConditionTest.java
--