[jira] [Updated] (CASSANDRA-12261) dtest failure in write_failures_test.TestWriteFailures.test_thrift

[Stefania (JIRA)]

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

Stefania updated CASSANDRA-12261:
-
Status: Patch Available  (was: In Progress)

> dtest failure in write_failures_test.TestWriteFailures.test_thrift
> --
>
> Key: CASSANDRA-12261
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12261
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Stefania
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.9_novnode_dtest/14/testReport/write_failures_test/TestWriteFailures/test_thrift
> Failure is
> {code}
> Unexpected error in node3 log, error: 
> ERROR [NonPeriodicTasks:1] 2016-07-20 07:09:52,127 LogTransaction.java:205 - 
> Unable to delete 
> /tmp/dtest-CSPEFG/test/node3/data2/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/mb-2-big-Data.db
>  as it does not exist
> Unexpected error in node3 log, error: 
> ERROR [NonPeriodicTasks:1] 2016-07-20 07:09:52,334 LogTransaction.java:205 - 
> Unable to delete 
> /tmp/dtest-CSPEFG/test/node3/data2/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/mb-15-big-Data.db
>  as it does not exist
> Unexpected error in node3 log, error: 
> ERROR [NonPeriodicTasks:1] 2016-07-20 07:09:52,337 LogTransaction.java:205 - 
> Unable to delete 
> /tmp/dtest-CSPEFG/test/node3/data2/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/mb-31-big-Data.db
>  as it does not exist
> Unexpected error in node3 log, error: 
> ERROR [NonPeriodicTasks:1] 2016-07-20 07:09:52,339 LogTransaction.java:205 - 
> Unable to delete 
> /tmp/dtest-CSPEFG/test/node3/data2/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/mb-18-big-Data.db
>  as it does not exist
> {code}



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

[jira] [Commented] (CASSANDRA-12261) dtest failure in write_failures_test.TestWriteFailures.test_thrift

[Stefania (JIRA)]

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

Stefania commented on CASSANDRA-12261:
--

This test seems to have failed only once with this specific failure and it 
cannot be reproduced locally. [~mambocab], are you aware of any other tests 
with the same problem or a reasonably reliable way to reproduce this?

The sstable transaction tidier deletes the sstable data file but at present it 
does not check if the data file exists. I've added this check and, if the 
sstable was not new, a new error message that should tell us if the sstable 
tidier ran without data file. After all sstable tidiers have run, the 
transaction tidier does another pass to ensure no content files are left before 
deleting the actual transaction log file. Here we were missing a folder sync, 
so I think it's not 100% impossible that {{record.getExistingFiles()}} returned 
a wrong result including files that were deleted just before by the sstable 
tidiers, although this wouldn't explain why only data files were reported as 
non existing. I've added the folder sync call. Unless the same file is involved 
in two different transactions, which shouldn't happen, there shouldn't be any 
race between the call to record.getExistingFiles() and LogTransaction::delete 
in LogFile.deleteRecordFiles().

I've also added the exception call stack in LogTransaction.delete(), but only 
to the debug log file.

I've prepared the patches fro 3.9 and trunk:

||3.9||trunk||
|[patch|https://github.com/stef1927/cassandra/commits/12261-3.9]|[patch|https://github.com/stef1927/cassandra/commits/12261]|
|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12261-3.9-testall/]|[testall|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12261-testall/]|
|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12261-3.9-dtest/]|[dtest|http://cassci.datastax.com/view/Dev/view/stef1927/job/stef1927-12261-dtest/]|

This problem could technically happen in 3.0 as well, but I would rather not 
disrupt 3.0 unless we are sure there is an issue in the first place.

> dtest failure in write_failures_test.TestWriteFailures.test_thrift
> --
>
> Key: CASSANDRA-12261
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12261
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Stefania
>  Labels: dtest
> Fix For: 3.x
>
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.9_novnode_dtest/14/testReport/write_failures_test/TestWriteFailures/test_thrift
> Failure is
> {code}
> Unexpected error in node3 log, error: 
> ERROR [NonPeriodicTasks:1] 2016-07-20 07:09:52,127 LogTransaction.java:205 - 
> Unable to delete 
> /tmp/dtest-CSPEFG/test/node3/data2/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/mb-2-big-Data.db
>  as it does not exist
> Unexpected error in node3 log, error: 
> ERROR [NonPeriodicTasks:1] 2016-07-20 07:09:52,334 LogTransaction.java:205 - 
> Unable to delete 
> /tmp/dtest-CSPEFG/test/node3/data2/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/mb-15-big-Data.db
>  as it does not exist
> Unexpected error in node3 log, error: 
> ERROR [NonPeriodicTasks:1] 2016-07-20 07:09:52,337 LogTransaction.java:205 - 
> Unable to delete 
> /tmp/dtest-CSPEFG/test/node3/data2/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/mb-31-big-Data.db
>  as it does not exist
> Unexpected error in node3 log, error: 
> ERROR [NonPeriodicTasks:1] 2016-07-20 07:09:52,339 LogTransaction.java:205 - 
> Unable to delete 
> /tmp/dtest-CSPEFG/test/node3/data2/system_schema/tables-afddfb9dbc1e30688056eed6c302ba09/mb-18-big-Data.db
>  as it does not exist
> {code}



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

[jira] [Commented] (CASSANDRA-10368) Support Restricting non-PK Cols in Materialized View Select Statements

[Jochen Niebuhr (JIRA)]

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

Jochen Niebuhr commented on CASSANDRA-10368:


[~thobbs] glad to hear that, thanks for the merge.

do you know when this will appear in a binary release and in the corresponding 
docker image?

> Support Restricting non-PK Cols in Materialized View Select Statements
> --
>
> Key: CASSANDRA-10368
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10368
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tyler Hobbs
>Assignee: Jochen Niebuhr
>Priority: Minor
> Fix For: 3.10
>
> Attachments: 10368-3.8.txt
>
>
> CASSANDRA-9664 allows materialized views to restrict primary key columns in 
> the select statement.  Due to CASSANDRA-10261, the patch did not include 
> support for restricting non-PK columns.  Now that the timestamp issue has 
> been resolved, we can add support for this.



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

[jira] [Comment Edited] (CASSANDRA-9630) Killing cassandra process results in unclosed connections

[Farzad Panahi (JIRA)]

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

Farzad Panahi edited comment on CASSANDRA-9630 at 7/28/16 1:14 AM:
---

I am experiencing a similar problem. 

Cassandra version: 3.0.8
Environment: Amazon EC2

Error Case:
When I restart Cassandra service on a node, after the node comes up it sees 
some or all of other nodes as DN even though other nodes see this node as UN. 

Here is the output of netstat and nodetool status for this error case:

1. right after stopping cassandra service on node 10.4.68.222:
{code}
--
ip-10-4-54-176
tcp0  0 10.4.54.176:51268   10.4.68.222:7000
TIME_WAIT   
tcp0  0 10.4.54.176:56135   10.4.68.222:7000
TIME_WAIT   
tcp1  0 10.4.54.176:43697   10.4.68.222:7000
CLOSE_WAIT  
tcp0  0 10.4.54.176:52372   10.4.68.222:7000
TIME_WAIT   
--
--
ip-10-4-54-177
tcp0  0 10.4.54.177:56960   10.4.68.222:7000
TIME_WAIT   
tcp0  0 10.4.54.177:54539   10.4.68.222:7000
TIME_WAIT   
tcp0  0 10.4.54.177:32823   10.4.68.222:7000
TIME_WAIT   
tcp1  0 10.4.54.177:48985   10.4.68.222:7000
CLOSE_WAIT  
--
--
ip-10-4-68-222
tcp0  0 10.4.68.222:700010.4.54.176:43697   
FIN_WAIT2   
tcp0  0 10.4.68.222:700010.4.54.177:48985   
FIN_WAIT2   
tcp0  0 10.4.68.222:700010.4.68.222:54419   
TIME_WAIT   
tcp0  0 10.4.68.222:700010.4.43.65:43197
FIN_WAIT2   
tcp0  0 10.4.68.222:700010.4.68.221:44149   
FIN_WAIT2   
tcp0  0 10.4.68.222:700010.4.68.222:41302   
TIME_WAIT   
tcp0  0 10.4.68.222:700010.4.43.66:54321
FIN_WAIT2   
--
--
ip-10-4-68-221
tcp0  0 10.4.68.221:49599   10.4.68.222:7000
TIME_WAIT   
tcp0  0 10.4.68.221:55033   10.4.68.222:7000
TIME_WAIT   
tcp0  0 10.4.68.221:51628   10.4.68.222:7000
TIME_WAIT   
tcp1  0 10.4.68.221:44149   10.4.68.222:7000
CLOSE_WAIT  
--
--
ip-10-4-43-66
tcp0  0 10.4.43.66:5593010.4.68.222:7000
TIME_WAIT   
tcp1  0 10.4.43.66:5432110.4.68.222:7000
CLOSE_WAIT  
tcp0  0 10.4.43.66:6096810.4.68.222:7000
TIME_WAIT   
tcp0  0 10.4.43.66:4908710.4.68.222:7000
TIME_WAIT   
--
--
ip-10-4-43-65
tcp1  0 10.4.43.65:4319710.4.68.222:7000
CLOSE_WAIT  
tcp0  0 10.4.43.65:3646710.4.68.222:7000
TIME_WAIT   
tcp0  0 10.4.43.65:5331710.4.68.222:7000
TIME_WAIT   
tcp0  0 10.4.43.65:5489710.4.68.222:7000
TIME_WAIT   
--
{code}

2. a bit after stopping cassandra service on node 10.4.68.222:
{code}
--
ip-10-4-54-176
tcp1  0 10.4.54.176:43697   10.4.68.222:7000
CLOSE_WAIT  
--
--
ip-10-4-54-177
--
--
ip-10-4-68-222
--
--
ip-10-4-68-221
tcp1  0 10.4.68.221:44149   10.4.68.222:7000
CLOSE_WAIT  
--
--
ip-10-4-43-66
tcp1  0 10.4.43.66:5432110.4.68.222:7000
CLOSE_WAIT  
--
--
ip-10-4-43-65
tcp1  0 10.4.43.65:4319710.4.68.222:7000
CLOSE_WAIT  
--
{code}

3. after starting cassandra service on node 10.4.68.222: 
{code}
--
ip-10-4-54-176
tcp0  0 10.4.54.176:42460   10.4.68.222:7000
ESTABLISHED 
tcp1 303403 10.4.54.176:43697   10.4.68.222:7000
CLOSE_WAIT  
tcp0  

[jira] [Commented] (CASSANDRA-9630) Killing cassandra process results in unclosed connections

[Farzad Panahi (JIRA)]

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

Farzad Panahi commented on CASSANDRA-9630:
--

I am experiencing similar issue. 

Cassandra version: 3.0.8
Environment: Amazon EC2

Error Case:
When I restart Cassandra service on a node, after the node comes up it sees 
some or all of other nodes as DN even though other nodes see this node as UN. 

Here is the output of netstat and nodetool status for this error case:

1. right after stopping cassandra service on node 10.4.68.222:
{code}
--
ip-10-4-54-176
tcp0  0 10.4.54.176:51268   10.4.68.222:7000
TIME_WAIT   
tcp0  0 10.4.54.176:56135   10.4.68.222:7000
TIME_WAIT   
tcp1  0 10.4.54.176:43697   10.4.68.222:7000
CLOSE_WAIT  
tcp0  0 10.4.54.176:52372   10.4.68.222:7000
TIME_WAIT   
--
--
ip-10-4-54-177
tcp0  0 10.4.54.177:56960   10.4.68.222:7000
TIME_WAIT   
tcp0  0 10.4.54.177:54539   10.4.68.222:7000
TIME_WAIT   
tcp0  0 10.4.54.177:32823   10.4.68.222:7000
TIME_WAIT   
tcp1  0 10.4.54.177:48985   10.4.68.222:7000
CLOSE_WAIT  
--
--
ip-10-4-68-222
tcp0  0 10.4.68.222:700010.4.54.176:43697   
FIN_WAIT2   
tcp0  0 10.4.68.222:700010.4.54.177:48985   
FIN_WAIT2   
tcp0  0 10.4.68.222:700010.4.68.222:54419   
TIME_WAIT   
tcp0  0 10.4.68.222:700010.4.43.65:43197
FIN_WAIT2   
tcp0  0 10.4.68.222:700010.4.68.221:44149   
FIN_WAIT2   
tcp0  0 10.4.68.222:700010.4.68.222:41302   
TIME_WAIT   
tcp0  0 10.4.68.222:700010.4.43.66:54321
FIN_WAIT2   
--
--
ip-10-4-68-221
tcp0  0 10.4.68.221:49599   10.4.68.222:7000
TIME_WAIT   
tcp0  0 10.4.68.221:55033   10.4.68.222:7000
TIME_WAIT   
tcp0  0 10.4.68.221:51628   10.4.68.222:7000
TIME_WAIT   
tcp1  0 10.4.68.221:44149   10.4.68.222:7000
CLOSE_WAIT  
--
--
ip-10-4-43-66
tcp0  0 10.4.43.66:5593010.4.68.222:7000
TIME_WAIT   
tcp1  0 10.4.43.66:5432110.4.68.222:7000
CLOSE_WAIT  
tcp0  0 10.4.43.66:6096810.4.68.222:7000
TIME_WAIT   
tcp0  0 10.4.43.66:4908710.4.68.222:7000
TIME_WAIT   
--
--
ip-10-4-43-65
tcp1  0 10.4.43.65:4319710.4.68.222:7000
CLOSE_WAIT  
tcp0  0 10.4.43.65:3646710.4.68.222:7000
TIME_WAIT   
tcp0  0 10.4.43.65:5331710.4.68.222:7000
TIME_WAIT   
tcp0  0 10.4.43.65:5489710.4.68.222:7000
TIME_WAIT   
--
{code}

2. a bit after stopping cassandra service on node 10.4.68.222:
{code}
--
ip-10-4-54-176
tcp1  0 10.4.54.176:43697   10.4.68.222:7000
CLOSE_WAIT  
--
--
ip-10-4-54-177
--
--
ip-10-4-68-222
--
--
ip-10-4-68-221
tcp1  0 10.4.68.221:44149   10.4.68.222:7000
CLOSE_WAIT  
--
--
ip-10-4-43-66
tcp1  0 10.4.43.66:5432110.4.68.222:7000
CLOSE_WAIT  
--
--
ip-10-4-43-65
tcp1  0 10.4.43.65:4319710.4.68.222:7000
CLOSE_WAIT  
--
{code}

3. after starting cassandra service on node 10.4.68.222: 
{code}
--
ip-10-4-54-176
tcp0  0 10.4.54.176:42460   10.4.68.222:7000
ESTABLISHED 
tcp1 303403 10.4.54.176:43697   10.4.68.222:7000
CLOSE_WAIT  
tcp0  0 10.4.54.176:42109   10.4.68.222:7000   

[jira] [Commented] (CASSANDRA-11687) dtest failure in rebuild_test.TestRebuild.simple_rebuild_test

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11687:
-

submitted [multiplexer 
run|https://cassci.datastax.com/view/Parameterized/job/parameterized_dtest_multiplexer/189/]

> dtest failure in rebuild_test.TestRebuild.simple_rebuild_test
> -
>
> Key: CASSANDRA-11687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11687
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Russ Hatch
>Assignee: Yuki Morishita
>  Labels: dtest
>
> single failure on most recent run (3.0 no-vnode)
> {noformat}
> concurrent rebuild should not be allowed, but one rebuild command should have 
> succeeded.
> {noformat}
> http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/217/testReport/rebuild_test/TestRebuild/simple_rebuild_test
> Failed on CassCI build cassandra-3.0_novnode_dtest #217



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

[jira] [Commented] (CASSANDRA-11465) dtest failure in cql_tracing_test.TestCqlTracing.tracing_unknown_impl_test

[Paulo Motta (JIRA)]

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

Paulo Motta commented on CASSANDRA-11465:
-

The previous runs failed with the same reason. I resubmitted them separately 
(with a delay between them as to not overload the apache repos), and they seem 
to be running. Please mark as ready to commit if CI executes successfully this 
time.

> dtest failure in cql_tracing_test.TestCqlTracing.tracing_unknown_impl_test
> --
>
> Key: CASSANDRA-11465
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11465
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Philip Thompson
>Assignee: Stefania
>  Labels: dtest
>
> Failing on the following assert, on trunk only: 
> {{self.assertEqual(len(errs[0]), 1)}}
> Is not failing consistently.
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1087/testReport/cql_tracing_test/TestCqlTracing/tracing_unknown_impl_test
> Failed on CassCI build trunk_dtest #1087



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

[jira] [Updated] (CASSANDRA-10368) Support Restricting non-PK Cols in Materialized View Select Statements

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-10368:

   Resolution: Fixed
Fix Version/s: (was: 3.x)
   3.10
   Status: Resolved  (was: Patch Available)

The test results look good.

+1, committed as {{5051c0f6eb3f984600600c9577d6b5ece9038c74}} to trunk.

Thanks again, [~jniebuhr]!

> Support Restricting non-PK Cols in Materialized View Select Statements
> --
>
> Key: CASSANDRA-10368
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10368
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL
>Reporter: Tyler Hobbs
>Assignee: Jochen Niebuhr
>Priority: Minor
> Fix For: 3.10
>
> Attachments: 10368-3.8.txt
>
>
> CASSANDRA-9664 allows materialized views to restrict primary key columns in 
> the select statement.  Due to CASSANDRA-10261, the patch did not include 
> support for restricting non-PK columns.  Now that the timestamp issue has 
> been resolved, we can add support for this.



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

cassandra git commit: Support Restricting non-PK Cols in MV Select Statements

[tylerhobbs]

Repository: cassandra
Updated Branches:
  refs/heads/trunk 503148b3d -> 5051c0f6e


Support Restricting non-PK Cols in MV Select Statements

Patch by Jochen Niebuhr; reviewed by Tyler Hobbs for CASSANDRA-10368


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

Branch: refs/heads/trunk
Commit: 5051c0f6eb3f984600600c9577d6b5ece9038c74
Parents: 503148b
Author: Jochen Niebuhr 
Authored: Tue Jul 26 13:09:35 2016 -0500
Committer: Tyler Hobbs 
Committed: Wed Jul 27 18:32:41 2016 -0500

--
 CHANGES.txt |   2 +
 .../cql3/statements/CreateViewStatement.java|   8 -
 .../cassandra/cql3/ViewFilteringTest.java   | 320 +++
 3 files changed, 322 insertions(+), 8 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cassandra/blob/5051c0f6/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 04b2a3f..7ad965e 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,6 @@
 3.10
+ * Support filtering on non-PRIMARY KEY columns in the CREATE
+   MATERIALIZED VIEW statement's WHERE clause (CASSANDRA-10368)
  * Unify STDOUT and SYSTEMLOG logback format (CASSANDRA-12004)
  * COPY FROM should raise error for non-existing input files (CASSANDRA-12174)
  * Faster write path (CASSANDRA-12269)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5051c0f6/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java
--
diff --git 
a/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java 
b/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java
index 5e14e72..8fe9f7e 100644
--- a/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java
@@ -203,14 +203,6 @@ public class CreateViewStatement extends 
SchemaAlteringStatement
 if (!prepared.boundNames.isEmpty())
 throw new InvalidRequestException("Cannot use query parameters in 
CREATE MATERIALIZED VIEW statements");
 
-if (!restrictions.nonPKRestrictedColumns(false).isEmpty())
-{
-throw new InvalidRequestException(String.format(
-"Non-primary key columns cannot be restricted in the 
SELECT statement used for materialized view " +
-"creation (got restrictions on: %s)",
-
restrictions.nonPKRestrictedColumns(false).stream().map(def -> 
def.name.toString()).collect(Collectors.joining(", ";
-}
-
 String whereClauseText = 
View.relationsToWhereClause(whereClause.relations);
 
 Set basePrimaryKeyCols = new HashSet<>();

http://git-wip-us.apache.org/repos/asf/cassandra/blob/5051c0f6/test/unit/org/apache/cassandra/cql3/ViewFilteringTest.java
--
diff --git a/test/unit/org/apache/cassandra/cql3/ViewFilteringTest.java 
b/test/unit/org/apache/cassandra/cql3/ViewFilteringTest.java
index 245ceb7..12cb673 100644
--- a/test/unit/org/apache/cassandra/cql3/ViewFilteringTest.java
+++ b/test/unit/org/apache/cassandra/cql3/ViewFilteringTest.java
@@ -28,7 +28,15 @@ import org.junit.Test;
 import com.datastax.driver.core.exceptions.InvalidQueryException;
 import junit.framework.Assert;
 
+import org.apache.cassandra.concurrent.SEPExecutor;
+import org.apache.cassandra.concurrent.Stage;
+import org.apache.cassandra.concurrent.StageManager;
+import org.apache.cassandra.config.CFMetaData;
+import org.apache.cassandra.config.ColumnDefinition;
+import org.apache.cassandra.db.ColumnFamilyStore;
+import org.apache.cassandra.db.Keyspace;
 import org.apache.cassandra.db.SystemKeyspace;
+import org.apache.cassandra.utils.FBUtilities;
 
 public class ViewFilteringTest extends CQLTester
 {
@@ -61,6 +69,16 @@ public class ViewFilteringTest extends CQLTester
 views.add(name);
 }
 
+private void updateView(String query, Object... params) throws Throwable
+{
+executeNet(protocolVersion, query, params);
+while (!(((SEPExecutor) 
StageManager.getStage(Stage.VIEW_MUTATION)).getPendingTasks() == 0
+&& ((SEPExecutor) 
StageManager.getStage(Stage.VIEW_MUTATION)).getActiveCount() == 0))
+{
+Thread.sleep(1);
+}
+}
+
 private void dropView(String name) throws Throwable
 {
 executeNet(protocolVersion, "DROP MATERIALIZED VIEW " + name);
@@ -1303,4 +1321,306 @@ public class ViewFilteringTest extends CQLTester
 

[jira] [Commented] (CASSANDRA-10664) Fix failing tests

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie commented on CASSANDRA-10664:
-

[~philipthompson]: Are the remaining failures broken out? i.e. can this be 
closed now?

> Fix failing tests
> -
>
> Key: CASSANDRA-10664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10664
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sylvain Lebresne
>  Labels: dtest
> Fix For: 3.0.x
>
>
> This is the continuation of CASSANDRA-10166, just a meta-ticket to group all 
> tickets related to fixing any unit test or dtest.



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

[jira] [Updated] (CASSANDRA-12323) dtest failure in compaction_test.TestCompaction_with_DateTieredCompactionStrategy.bloomfilter_size_test

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-12323:

Assignee: Marcus Eriksson

> dtest failure in 
> compaction_test.TestCompaction_with_DateTieredCompactionStrategy.bloomfilter_size_test
> ---
>
> Key: CASSANDRA-12323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12323
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Craig Kodman
>Assignee: Marcus Eriksson
>  Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.9_novnode_dtest/19/testReport/compaction_test/TestCompaction_with_DateTieredCompactionStrategy/bloomfilter_size_test
> 500352 not less than or equal to 15



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

[jira] [Updated] (CASSANDRA-12315) dtest failure in cqlsh_tests.cqlsh_tests.TestCqlsh.test_client_warnings

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-12315:

Assignee: Tyler Hobbs

> dtest failure in cqlsh_tests.cqlsh_tests.TestCqlsh.test_client_warnings
> ---
>
> Key: CASSANDRA-12315
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12315
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Tyler Hobbs
>  Labels: cqlsh, dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1317/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_client_warnings
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools.py", line 290, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_tests.py", line 
> 1424, in test_client_warnings
> self.assertEqual(len(stderr), 0, "Failed to execute cqlsh: 
> {}".format(stderr))
>   File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
> assertion_func(first, second, msg=msg)
>   File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual
> raise self.failureException(msg)
> 'Failed to execute cqlsh: :3:OperationTimedOut: errors={\'127.0.0.1\': 
> \'Client request timeout. See Session.execute[_async](timeout)\'}, 
> last_host=127.0.0.1\n:5:InvalidRequest: Error from server: code=2200 
> [Invalid query] message="Keyspace \'client_warnings\' does not 
> exist"\n:7:InvalidRequest: Error from server: code=2200 [Invalid 
> query] message="No keyspace has been specified. USE a keyspace, or explicitly 
> specify keyspace.tablename"
> {code}



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

[jira] [Updated] (CASSANDRA-12264) dtest failure in repair_tests.incremental_repair_test.TestIncRepair.sstable_marking_test

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-12264:

Assignee: Marcus Eriksson

> dtest failure in 
> repair_tests.incremental_repair_test.TestIncRepair.sstable_marking_test
> 
>
> Key: CASSANDRA-12264
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12264
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: Marcus Eriksson
>  Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.9_dtest/15/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_marking_test
> {code}
> Error Message
> 'Repaired at: 0' unexpectedly found in 'SSTable: 
> {code}
> Related failure:
> http://cassci.datastax.com/job/trunk_dtest/1315/testReport/repair_tests.incremental_repair_test/TestIncRepair/sstable_marking_test/



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

[jira] [Updated] (CASSANDRA-11687) dtest failure in rebuild_test.TestRebuild.simple_rebuild_test

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-11687:

Reviewer: Paulo Motta

> dtest failure in rebuild_test.TestRebuild.simple_rebuild_test
> -
>
> Key: CASSANDRA-11687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11687
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Russ Hatch
>Assignee: Yuki Morishita
>  Labels: dtest
>
> single failure on most recent run (3.0 no-vnode)
> {noformat}
> concurrent rebuild should not be allowed, but one rebuild command should have 
> succeeded.
> {noformat}
> http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/217/testReport/rebuild_test/TestRebuild/simple_rebuild_test
> Failed on CassCI build cassandra-3.0_novnode_dtest #217



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

[jira] [Updated] (CASSANDRA-12312) Restore JVM metric export for metric reporters

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-12312:

Reviewer: T Jake Luciani

> Restore JVM metric export for metric reporters
> --
>
> Key: CASSANDRA-12312
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12312
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Stefan Podkowinski
>Assignee: Stefan Podkowinski
> Fix For: 2.2.x, 3.0.x, 3.x
>
> Attachments: 12312-2.2.patch, 12312-3.0.patch, 12312-trunk.patch, 
> metrics-jvm-3.1.0.jar.asc
>
>
> JVM instrumentation as part of dropwizard metrics has been moved to a 
> separate {{metrics-jvm}} artifact in metrics-v3.0. After CASSANDRA-5657, no 
> jvm related metrics will be exported to any reporter configured via 
> {{metrics-reporter-config}}, as this isn't part of {{metrics-core}} anymore. 
> As memory and GC stats are essential for monitoring Cassandra, this turns out 
> to be a blocker for us for upgrading to 2.2.
> I've included a patch that would add the now separate {{metrics-jvm}} package 
> and enables some of the provided metrics on startup in case a metrics 
> reporter is used ({{-Dcassandra.metricsReporterConfigFile}}).



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

[jira] [Updated] (CASSANDRA-12311) Propagate TombstoneOverwhelmingException to the client

[Joshua McKenzie (JIRA)]

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

Joshua McKenzie updated CASSANDRA-12311:

Reviewer: Tyler Hobbs

> Propagate TombstoneOverwhelmingException to the client
> --
>
> Key: CASSANDRA-12311
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12311
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: Geoffrey Yu
>Assignee: Geoffrey Yu
>Priority: Minor
> Fix For: 4.x
>
> Attachments: 12311-trunk.txt
>
>
> Right now if a data node fails to perform a read because it ran into a 
> {{TombstoneOverwhelmingException}}, it only responds back to the coordinator 
> node with a generic failure. Under this scheme, the coordinator won't be able 
> to know exactly why the request failed and subsequently the client only gets 
> a generic {{ReadFailureException}}. It would be useful to inform the client 
> that their read failed because we read too many tombstones. We should have 
> the data nodes reply with a failure type so the coordinator can pass this 
> information to the client.



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

[jira] [Updated] (CASSANDRA-10993) Make read and write requests paths fully non-blocking, eliminate related stages

[Tyler Hobbs (JIRA)]

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

Tyler Hobbs updated CASSANDRA-10993:

Attachment: tpc-benchmarks.txt

I have a first round of benchmark results of CASSANDRA-10993-WIP vs trunk (at 
{{007a3f57a328eaace19daca54901ccb70522d89f}}).  I'm still working on rebasing 
the RxJava work for comparison.

This setup is testing a single C* node with RF=1.  All reads are served from a 
memtable.

The data was populated with a cassandra-stress write with the following options:
{noformat}
write n=200 -pop seq=1..10
{noformat}

Reads were performed with six different stress clients (on separate servers) 
simultaneously.  All of the stress clients executed the following:
{noformat}
read n=1000 no-warmup -rate threads=950 -pop seq=1..1
{noformat}

I tested with different numbers of threads, and 950 seemed to maximize the 
throughput for both 10993 and trunk.

Here's a quick summary of the results:
* 10993 achieved 220236 reads/sec, trunk achieved 198576 reads/sec.
* 10993 median latency is quite a bit lower (~13ms vs ~20ms)
* 10993 95th latency is a little higher (~82ms vs 60ms)
* 10993 99th and 99.9th latencies are roughly double that of trunk

I did test setting {{concurrent_reads}} > {{native_transport_max_threads}} on 
trunk as recommended in CASSANDRA-10528, but it had no significant effect on 
performance.

The detailed stress results for these runs can be found in the attached 
{{tpc-benchmarks.txt}} file.

> Make read and write requests paths fully non-blocking, eliminate related 
> stages
> ---
>
> Key: CASSANDRA-10993
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10993
> Project: Cassandra
>  Issue Type: Sub-task
>  Components: Coordination, Local Write-Read Paths
>Reporter: Aleksey Yeschenko
>Assignee: Tyler Hobbs
> Fix For: 3.x
>
> Attachments: 10993-reads-no-evloop-integration-six-node-stress.svg, 
> tpc-benchmarks.txt
>
>
> Building on work done by [~tjake] (CASSANDRA-10528), [~slebresne] 
> (CASSANDRA-5239), and others, convert read and write request paths to be 
> fully non-blocking, to enable the eventual transition from SEDA to TPC 
> (CASSANDRA-10989)
> Eliminate {{MUTATION}}, {{COUNTER_MUTATION}}, {{VIEW_MUTATION}}, {{READ}}, 
> and {{READ_REPAIR}} stages, move read and write execution directly to Netty 
> context.
> For lack of decent async I/O options on Linux, we’ll still have to retain an 
> extra thread pool for serving read requests for data not residing in our page 
> cache (CASSANDRA-5863), however.
> Implementation-wise, we only have two options available to us: explicit FSMs 
> and chained futures. Fibers would be the third, and easiest option, but 
> aren’t feasible in Java without resorting to direct bytecode manipulation 
> (ourselves or using [quasar|https://github.com/puniverse/quasar]).
> I have seen 4 implementations bases on chained futures/promises now - three 
> in Java and one in C++ - and I’m not convinced that it’s the optimal (or 
> sane) choice for representing our complex logic - think 2i quorum read 
> requests with timeouts at all levels, read repair (blocking and 
> non-blocking), and speculative retries in the mix, {{SERIAL}} reads and 
> writes.
> I’m currently leaning towards an implementation based on explicit FSMs, and 
> intend to provide a prototype - soonish - for comparison with 
> {{CompletableFuture}}-like variants.
> Either way the transition is a relatively boring straightforward refactoring.
> There are, however, some extension points on both write and read paths that 
> we do not control:
> - authorisation implementations will have to be non-blocking. We have control 
> over built-in ones, but for any custom implementation we will have to execute 
> them in a separate thread pool
> - 2i hooks on the write path will need to be non-blocking
> - any trigger implementations will not be allowed to block
> - UDFs and UDAs
> We are further limited by API compatibility restrictions in the 3.x line, 
> forbidding us to alter, or add any non-{{default}} interface methods to those 
> extension points, so these pose a problem.
> Depending on logistics, expecting to get this done in time for 3.4 or 3.6 
> feature release.



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

[jira] [Resolved] (CASSANDRA-12065) dtest failure in repair_tests.repair_test.TestRepair.repair_after_upgrade_test

[Paulo Motta (JIRA)]

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

Paulo Motta resolved CASSANDRA-12065.
-
Resolution: Duplicate

Fixed by CASSANDRA-12057.

> dtest failure in repair_tests.repair_test.TestRepair.repair_after_upgrade_test
> --
>
> Key: CASSANDRA-12065
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12065
> Project: Cassandra
>  Issue Type: Test
>Reporter: Craig Kodman
>Assignee: DS Test Eng
>  Labels: dtest, windows
>
> example failure:
> http://cassci.datastax.com/job/cassandra-3.0_dtest_win32/259/testReport/repair_tests.repair_test/TestRepair/repair_after_upgrade_test
> Failed on CassCI build cassandra-3.0_dtest_win32 #259



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

[jira] [Comment Edited] (CASSANDRA-12253) Fix exceptions when enabling gossip on proxy nodes.

[Dikang Gu (JIRA)]

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

Dikang Gu edited comment on CASSANDRA-12253 at 7/27/16 9:47 PM:


or sth like this (0002-for-proxy-node-not-set-gossip-tokens.patch)? If we want 
to keep the assertion.


was (Author: dikanggu):
or sth like this? If we want to keep the assertion.

> Fix exceptions when enabling gossip on proxy nodes.
> ---
>
> Key: CASSANDRA-12253
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12253
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Minor
> Fix For: 2.2.x
>
> Attachments: 0001-for-proxy-node-not-set-gossip-tokens.patch, 
> 0002-for-proxy-node-not-set-gossip-tokens.patch
>
>
> We have a tier of Cassandra nodes running with join_ring=false flag, which we 
> call proxy nodes, and they will never join the ring.
> The problem is that sometimes we need to disable and enable the gossip on 
> those nodes, and `nodetool enablegossip` throws exceptions when we do that:
> {code}
> java.lang.AssertionError
> at 
> org.apache.cassandra.service.StorageService.getLocalTokens(StorageService.java:2213)
> at 
> org.apache.cassandra.service.StorageService.startGossiping(StorageService.java:371)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
> at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {code}



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

[jira] [Updated] (CASSANDRA-12253) Fix exceptions when enabling gossip on proxy nodes.

[Dikang Gu (JIRA)]

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

Dikang Gu updated CASSANDRA-12253:
--
Attachment: 0002-for-proxy-node-not-set-gossip-tokens.patch

or sth like this? If we want to keep the assertion.

> Fix exceptions when enabling gossip on proxy nodes.
> ---
>
> Key: CASSANDRA-12253
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12253
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Minor
> Fix For: 2.2.x
>
> Attachments: 0001-for-proxy-node-not-set-gossip-tokens.patch, 
> 0002-for-proxy-node-not-set-gossip-tokens.patch
>
>
> We have a tier of Cassandra nodes running with join_ring=false flag, which we 
> call proxy nodes, and they will never join the ring.
> The problem is that sometimes we need to disable and enable the gossip on 
> those nodes, and `nodetool enablegossip` throws exceptions when we do that:
> {code}
> java.lang.AssertionError
> at 
> org.apache.cassandra.service.StorageService.getLocalTokens(StorageService.java:2213)
> at 
> org.apache.cassandra.service.StorageService.startGossiping(StorageService.java:371)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
> at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {code}



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

[jira] [Commented] (CASSANDRA-11949) GC log directory should be created in startup scripts

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-11949:


It looks like we already fix the gc.log location in deb packages, so I assume 
this is OK - 
https://github.com/apache/cassandra/blob/trunk/debian/patches/002cassandra_logdir_fix.dpatch

> GC log directory should be created in startup scripts
> -
>
> Key: CASSANDRA-11949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11949
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Fix For: 2.2.8, 3.0.9, 3.9
>
>
> In [CASSANDRA-10140], we enabled GC logging by default, since the overhead 
> was low and asking people providing diagnostics to restart can often make it 
> more difficult to diagnose problems.
> The default GC log path is set to {{$CASSANDRA_HOME/logs/gc.log}} in 
> {{cassandra-env.sh}}, a directory that is not present in a fresh 
> clone/install. Even if logback creates this directory later in startup, it is 
> not present when the JVM initiates GC logging, so GC logging will silently 
> fail for this first Cassandra run
> I haven't tested this in Windows but suspect the same problem may occur. 
> Since lots of tooling around Cassandra won't create this directory, we should 
> instead consider attempting to create it in our startup scripts.



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

[jira] [Commented] (CASSANDRA-12253) Fix exceptions when enabling gossip on proxy nodes.

[Dikang Gu (JIRA)]

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

Dikang Gu commented on CASSANDRA-12253:
---

[~jkni], oh, I see, sorry I miss read your code. so basically you removed the 
assertion of the tokens, if you think it's safe to remove that, then I'm good 
with your patch. Thanks!

> Fix exceptions when enabling gossip on proxy nodes.
> ---
>
> Key: CASSANDRA-12253
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12253
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Minor
> Fix For: 2.2.x
>
> Attachments: 0001-for-proxy-node-not-set-gossip-tokens.patch
>
>
> We have a tier of Cassandra nodes running with join_ring=false flag, which we 
> call proxy nodes, and they will never join the ring.
> The problem is that sometimes we need to disable and enable the gossip on 
> those nodes, and `nodetool enablegossip` throws exceptions when we do that:
> {code}
> java.lang.AssertionError
> at 
> org.apache.cassandra.service.StorageService.getLocalTokens(StorageService.java:2213)
> at 
> org.apache.cassandra.service.StorageService.startGossiping(StorageService.java:371)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
> at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {code}



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

[jira] [Commented] (CASSANDRA-12334) HP Fortify Analysis

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis commented on CASSANDRA-12334:


Hi [~EdAInWestOC], thanks for taking the time to report your findings!  Please 
create any further tickets as subtasks of this one so we can track them better.

> HP Fortify Analysis
> ---
>
> Key: CASSANDRA-12334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12334
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jonathan Ellis
>Priority: Minor
>




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

[jira] [Updated] (CASSANDRA-12326) Use of getByAddress() to retrieve InetAddress object

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12326:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Use of getByAddress() to retrieve InetAddress object
> 
>
> Key: CASSANDRA-12326
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12326
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> There are four places in the Cassandra source code that rely upon a call to 
> getByAddress() to retrieve an InetAddress object. The information returned by 
> getByAddress() is not trustworthy. Attackers can spoof DNS entries and 
> depending on getByAddress alone invites DNS spoofing attacks.
> The four places in the Cassandra source code where getByAddress() is used:
> MutationVerbHandler.java Line 58
> CompactEndpointSerializationHelper.java Line 38
> InetAddressSerializer.java Line 38, 58
> MutationVerbHandler.java, lines 49-59:
> {code:java}
> 49 if (from == null)
> 50 {
> 51 replyTo = message.from;
> 52 byte[] forwardBytes = message.parameters.get(Mutation.FORWARD_TO);
> 53 if (forwardBytes != null)
> 54 forwardToLocalNodes(message.payload, message.verb, forwardBytes, 
> message.from);
> 55 }
> 56 else
> 57 {
> 58 replyTo = InetAddress.getByAddress(from);
> 59 }
> {code}



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

[jira] [Updated] (CASSANDRA-12299) Privacy Violation - Heap Inspection

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12299:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Privacy Violation - Heap Inspection
> ---
>
> Key: CASSANDRA-12299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12299
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> In the file CqlConfigHelper.java on lines 508, 533, 534 and 592 a string 
> object is used to store sensitive data. String objects are immutable and 
> should not be used to store sensitive data. Sensitive data should be stored 
> in char or byte arrays and the contents of those arrays should be cleared 
> ASAP. Operations performed on string objects will require that the original 
> object be copied and the operation be applied in the new copy of the string 
> object. This results in the likelihood that multiple copies of sensitive data 
> will be present in the heap until garbage collection takes place.
> The snippet below shows the issue on line 508:
> CqlConfigHelper.java, lines 505-518:
> {code:java}
> 505 private static Optional 
> getDefaultAuthProvider(Configuration conf)
> 506 {
> 507 Optional username = getStringSetting(USERNAME, conf);
> 508 Optional password = getStringSetting(PASSWORD, conf);
> 509 
> 510 if (username.isPresent() && password.isPresent())
> 511 {
> 512 return Optional.of(new PlainTextAuthProvider(username.get(), 
> password.get()));
> 513 }
> 514 else
> 515 {
> 516 return Optional.absent();
> 517 }
> 518 }
> {code}



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

[jira] [Updated] (CASSANDRA-12328) Path Manipulation

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12328:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Path Manipulation
> -
>
> Key: CASSANDRA-12328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12328
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> There are multiple places in the Cassandra source code where a string that 
> determines the path of a file is not examined prior to use. Path traversal 
> vulnerabilities are common software security problems and failure to validate 
> the path prior to open/creating a file may result in operating in a directory 
> that is outside the intended control sphere.
> Path manipulation issues were found in the following locations:
> CompactionManager.java Line 637
> Descriptor.java Line 224
> MetadataSerializer.java Line 83, 153
> CommitLog.java Line 199
> LogTransaction.java Line 311
> WindowsFailedSnapshotTracker.java Line 51, 55, 60, 78, 84, 95
> LegacyMetadataSerializer.java Line 84
> FileUtils.java Line 116, 172, 354, 368, 386, 437
> RewindableDataInputStreamPlus.java Line 226
> CassandraDaemon.java Line 557
> NodeTool.java Line 261
> CustomClassLoader.java Line 77
> CoalescingStrategies.java Line 54, 150
> FBUtilities.java Line 309, 748
> The following snippet is from CompactionManager.java where unvalidated input 
> is parsed and used to create a new File object on line 637:
> {code:java}
> CompactionManager.java, lines 621-638:
> 621 public void forceUserDefinedCompaction(String dataFiles)
> 622 {
> 623 String[] filenames = dataFiles.split(",");
> 624 Multimap descriptors = 
> ArrayListMultimap.create();
> 625 
> 626 for (String filename : filenames)
> 627 {
> 628 // extract keyspace and columnfamily name from filename
> 629 Descriptor desc = Descriptor.fromFilename(filename.trim());
> 630 if (Schema.instance.getCFMetaData(desc) == null)
> 631 {
> 632 logger.warn("Schema does not exist for file {}. Skipping.", 
> filename);
> 633 continue;
> 634 }
> 635 // group by keyspace/columnfamily
> 636 ColumnFamilyStore cfs = 
> Keyspace.open(desc.ksname).getColumnFamilyStore(desc.cfname);
> 637 descriptors.put(cfs, cfs.getDirectories().find(new 
> File(filename.trim()).getName()));
> 638 }
> {code}



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

[jira] [Updated] (CASSANDRA-12324) Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select Classes or Code

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12324:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select 
> Classes or Code
> --
>
> Key: CASSANDRA-12324
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12324
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Dynamically loaded code has the potential to be malicious. The application 
> uses external input to select which classes or code to use, but it does not 
> sufficiently prevent the input from selecting improper classes or code.
> The snippet below shows the issue which ends on line 436 by returning an 
> object associated with a class by name.
> {code:java}
> FBUtilities.java, lines 432-442:
> 432 public static  Class classForName(String classname, String 
> readable) throws ConfigurationException
> 433 {
> 434 try
> 435 {
> 436 return (Class)Class.forName(classname);
> 437 }
> 438 catch (ClassNotFoundException | NoClassDefFoundError e)
> 439 {
> 440 throw new ConfigurationException(String.format("Unable to find %s 
> class '%s'", readable, classname), e);
> 441 }
> 442 }
> {code}



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

[jira] [Updated] (CASSANDRA-12325) Access Specifier Manipulation

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12325:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Access Specifier Manipulation
> -
>
> Key: CASSANDRA-12325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12325
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> There are 18 instances in the Cassandra source code where setAccessible() is 
> used to suppress Java language access checking. Static analysis automation 
> tools, like Fortify, will log every instance of the use of setAccessible() 
> and its use represents a possible security issue.
> The use of setAccessble() can cause security problems if the Java access 
> checking is suppressed longer than required or another approach could be 
> taken other than suppressing access checking. This issue will list all 18 
> instances where setAccessible() is used and the usage of this method should 
> be reviewed and checked to make sure it is not used inappropriately.
> setAccessible() is used in the following places:
> UDHelper.java Line 49
> HadoopCompat.java Line 109, 113, 118, 150, 152, 154
> Memory.java Line 42
> GCInspector.java Line 68
> Locks.java Line 33
> Ref.java Line 626
> FastByteOperations.java Line 150
> FBUtilities.java Line 539
> Hex.java Line 128
> MemoryUtil.java Line 61
> SyncUtil.java Line 33, 45, 57
> UDHelper.java, lines 45-56:
> {code:java}
> 45 try
> 46 {
> 47 Class cls = 
> Class.forName("com.datastax.driver.core.DataTypeClassNameParser");
> 48 Method m = cls.getDeclaredMethod("parseOne", String.class, 
> ProtocolVersion.class, CodecRegistry.class);
> 49 m.setAccessible(true);
> 50 methodParseOne = MethodHandles.lookup().unreflect(m);
> 51 codecRegistry = new CodecRegistry();
> 52 }
> 53 catch (Exception e)
> 54 {
> 55 throw new RuntimeException(e);
> 56 }
> {code}



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

[jira] [Updated] (CASSANDRA-12303) Privacy Violation - Heap Inspection

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12303:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Privacy Violation - Heap Inspection
> ---
>
> Key: CASSANDRA-12303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12303
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> In the file AbstractJmxClient.java on lines 69 and 147 a string object is 
> used to store sensitive data. String objects are immutable and should not be 
> used to store sensitive data. Sensitive data should be stored in char or byte 
> arrays and the contents of those arrays should be cleared ASAP. Operations 
> performed on string objects will require that the original object be copied 
> and the operation be applied in the new copy of the string object. This 
> results in the likelihood that multiple copies of sensitive data will be 
> present in the heap until garbage collection takes place.
> The snippet below shows the issue on line 69:
> AbstractJmxClient.java, lines 51-71:
> {code:java}
> 51 protected final String password;
> 52 protected JMXConnection jmxConn;
> 53 protected PrintStream out = System.out;
> . . .
> 64 public AbstractJmxClient(String host, Integer port, String username, 
> String password) throws IOException
> 65 {
> 66 this.host = (host != null) ? host : DEFAULT_HOST;
> 67 this.port = (port != null) ? port : DEFAULT_JMX_PORT;
> 68 this.username = username;
> 69 this.password = password;
> 70 jmxConn = new JMXConnection(this.host, this.port, username, password);
> 71 }
> {code}



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

[jira] [Updated] (CASSANDRA-12298) Privacy Violation - Heap Inspection

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12298:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Privacy Violation - Heap Inspection
> ---
>
> Key: CASSANDRA-12298
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12298
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>Assignee: Jason Brown
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included 
> an automated analysis using HP Fortify v4.21 SCA and a manual analysis 
> utilizing SciTools Understand v4. The results of that 
> analysis includes the issue below.
> Issue:
> In the file RoleOptions.java on line 89 a string object is used to store 
> sensitive data. String objects are immutable and should not be used to store 
> sensitive data. Sensitive data should be stored in char or byte arrays and 
> the contents of those arrays should be cleared ASAP. Operations performed on 
> string objects will require that the original object be copied and the 
> operation be applied in the new copy of the string object. This results in 
> the likelihood that multiple copies of sensitive data will be present in the 
> heap until garbage collection takes place.
> The snippet below shows the issue on line 89:
> RoleOptions.java, lines 87-90:
> {code:java}
> 87 public Optional getPassword()
> 88 {
> 89 return 
> Optional.fromNullable((String)options.get(IRoleManager.Option.PASSWORD));
> 90 }
> {code}



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

[jira] [Updated] (CASSANDRA-12301) Privacy Violation - Heap Inspection

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12301:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Privacy Violation - Heap Inspection
> ---
>
> Key: CASSANDRA-12301
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12301
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> In the file SSLTransportFactory.java on lines 72 and 76 a string object is 
> used to store sensitive data. String objects are immutable and should not be 
> used to store sensitive data. Sensitive data should be stored in char or byte 
> arrays and the contents of those arrays should be cleared ASAP. Operations 
> performed on string objects will require that the original object be copied 
> and the operation be applied in the new copy of the string object. This 
> results in the likelihood that multiple copies of sensitive data will be 
> present in the heap until garbage collection takes place.
> The snippet below shows the issue on lines 72 and 76:
> SSLTransportFactory.java, lines 47-81:
> {code:java}
> 47 private String truststore;
> 48 private String truststorePassword;
> 49 private String keystore;
> 50 private String keystorePassword;
> 51 private String protocol;
> 52 private String[] cipherSuites;
> . . .
> 66 @Override
> 67 public void setOptions(Map options)
> 68 {
> 69 if (options.containsKey(TRUSTSTORE))
> 70 truststore = options.get(TRUSTSTORE);
> 71 if (options.containsKey(TRUSTSTORE_PASSWORD))
> 72 truststorePassword = options.get(TRUSTSTORE_PASSWORD);
> 73 if (options.containsKey(KEYSTORE))
> 74 keystore = options.get(KEYSTORE);
> 75 if (options.containsKey(KEYSTORE_PASSWORD))
> 76 keystorePassword = options.get(KEYSTORE_PASSWORD);
> 77 if (options.containsKey(PROTOCOL))
> 78 protocol = options.get(PROTOCOL);
> 79 if (options.containsKey(CIPHER_SUITES))
> 80 cipherSuites = options.get(CIPHER_SUITES).split(",");
> 81 }
> {code}



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

[jira] [Updated] (CASSANDRA-12327) Use of getAllByName() to retrieve IP addresses

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12327:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Use of getAllByName() to retrieve IP addresses
> --
>
> Key: CASSANDRA-12327
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12327
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Use of getAllByName() to retrieve an IP addresses is not trustworthy. 
> Attackers can spoof DNS entries.
> The file LimitedLocalNodeFirstLocalBalancingPolicy.java calls getAllByName() 
> on line 66.
> LimitedLocalNodeFirstLocalBalancingPolicy.java, lines 64-72:
> {code:java}
> 64 try
> 65 {
> 66 InetAddress[] addresses = InetAddress.getAllByName(replica);
> 67 Collections.addAll(replicaAddresses, addresses);
> 68 }
> 69 catch (UnknownHostException e)
> 70 {
> 71 logger.warn("Invalid replica host name: {}, skipping it", replica);
> 72 }
> {code}



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

[jira] [Updated] (CASSANDRA-12332) Weak SecurityManager Check: Overridable Method

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12332:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Weak SecurityManager Check: Overridable Method
> --
>
> Key: CASSANDRA-12332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12332
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Non-final methods that perform security checks may be overridden in ways that 
> bypass security checks.
> {code:java}
> CassandraDaemon.java, lines 155-165:
> 155 protected void setup()
> 156 {
> 157 // Delete any failed snapshot deletions on Windows - see 
> CASSANDRA-9658
> 158 if (FBUtilities.isWindows())
> 159 WindowsFailedSnapshotTracker.deleteOldSnapshots();
> 160 
> 161 ThreadAwareSecurityManager.install();
> 162 
> 163 logSystemInfo();
> 164 
> 165 CLibrary.tryMlockall();
> {code}



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

[jira] [Commented] (CASSANDRA-11949) GC log directory should be created in startup scripts

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-11949:


I suppose we could do something like ISC cron does and add the dirs to git with 
a placeholder and adjust .gitignore accordingly for running from a git checkout?
{noformat}
(trunk)mshuler@hana:~/git/cassandra$ cat /etc/cron.weekly/.placeholder 
# DO NOT EDIT OR REMOVE
# This file is a simple placeholder to keep dpkg from removing this directory
{noformat}

Alternatively, if we only really care about release packages, the artifacts 
target in build.xml could create the directories, I would think.

> GC log directory should be created in startup scripts
> -
>
> Key: CASSANDRA-11949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11949
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Fix For: 2.2.8, 3.0.9, 3.9
>
>
> In [CASSANDRA-10140], we enabled GC logging by default, since the overhead 
> was low and asking people providing diagnostics to restart can often make it 
> more difficult to diagnose problems.
> The default GC log path is set to {{$CASSANDRA_HOME/logs/gc.log}} in 
> {{cassandra-env.sh}}, a directory that is not present in a fresh 
> clone/install. Even if logback creates this directory later in startup, it is 
> not present when the JVM initiates GC logging, so GC logging will silently 
> fail for this first Cassandra run
> I haven't tested this in Windows but suspect the same problem may occur. 
> Since lots of tooling around Cassandra won't create this directory, we should 
> instead consider attempting to create it in our startup scripts.



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

[jira] [Updated] (CASSANDRA-12331) Unreleased Resource: Sockets

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12331:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Unreleased Resource: Sockets
> 
>
> Key: CASSANDRA-12331
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12331
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Sockets are low level resources that must be explicitly released so 
> subsequent callers will have access to previously used sockets. In the file 
> RMIServerSocketFactoryImpl.java on lines 15-16 a socket is acquired and 
> eventually returned to the caller on line 18.
> If an exception is thrown by the code on line 17 the socket acquired on lines 
> 15-16 will not be released for subsequent reuse.
> RMIServerSocketFactoryImpl.java, lines 13-19:
> {code:java}
> 13 public ServerSocket createServerSocket(final int pPort) throws IOException
> 14 {
> 15 ServerSocket socket = ServerSocketFactory.getDefault()
> 16  .createServerSocket(pPort, 0, 
> InetAddress.getLoopbackAddress());
> 17 socket.setReuseAddress(true);
> 18 return socket;
> 19 }
> {code}



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

[jira] [Updated] (CASSANDRA-12329) Unreleased Resource: Sockets

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12329:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Unreleased Resource: Sockets
> 
>
> Key: CASSANDRA-12329
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12329
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Sockets are low level resources that must be explicitly released so 
> subsequent callers will have access to previously used sockets. In the file 
> SSLFactory.java on line 62 a SSL server socket is acquired and eventually 
> returned to the caller on line 69.
> If an exception is thrown by any of the code between lines 62 and 69 the 
> socket acquired on line 62 will not be released for subsequent reuse..
> {code:java}
> SSLFactory.java, lines 59-70:
> 59 public static SSLServerSocket getServerSocket(EncryptionOptions options, 
> InetAddress address, int port) throws IOException
> 60 {
> 61 SSLContext ctx = createSSLContext(options, true);
> 62 SSLServerSocket serverSocket = 
> (SSLServerSocket)ctx.getServerSocketFactory().createServerSocket();
> 63 serverSocket.setReuseAddress(true);
> 64 String[] suites = 
> filterCipherSuites(serverSocket.getSupportedCipherSuites(), 
> options.cipher_suites);
> 65 serverSocket.setEnabledCipherSuites(suites);
> 66 serverSocket.setNeedClientAuth(options.require_client_auth);
> 67 serverSocket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
> 68 serverSocket.bind(new InetSocketAddress(address, port), 500);
> 69 return serverSocket;
> 70 }
> {code}



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

[jira] [Updated] (CASSANDRA-12330) Unreleased Resource: Sockets

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12330:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Unreleased Resource: Sockets
> 
>
> Key: CASSANDRA-12330
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12330
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Sockets are low level resources that must be explicitly released so 
> subsequent callers will have access to previously used sockets. In the file 
> DefaultConnectionFactory.java on line 52 a socket is acquired and eventually 
> returned to the caller on line 55.
> If an exception is thrown by any of the code between lines 52 and 55 the 
> socket acquired on line 52 will not be released for subsequent reuse.
> DefaultConnectionFactory.java, lines 50-73:
> {code:java}
> 50 try
> 51 {
> 52 Socket socket = OutboundTcpConnectionPool.newSocket(peer);
> 53 
> socket.setSoTimeout(DatabaseDescriptor.getStreamingSocketTimeout());
> 54 socket.setKeepAlive(true);
> 55 return socket;
> 56 }
> 57 catch (IOException e)
> 58 {
> 59 if (++attempts >= MAX_CONNECT_ATTEMPTS)
> 60 throw e;
> 61 
> 62 long waitms = DatabaseDescriptor.getRpcTimeout() * 
> (long)Math.pow(2, attempts);
> 63 logger.warn("Failed attempt {} to connect to {}. Retrying in {} 
> ms. ({})", attempts, peer, waitms, e);
> 64 try
> 65 {
> 66 Thread.sleep(waitms);
> 67 }
> 68 catch (InterruptedException wtf)
> 69 {
> 70 throw new IOException("interrupted", wtf);
> 71 }
> 72 }
> 73 }
> {code}



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

[jira] [Updated] (CASSANDRA-12333) Password Management: Hardcoded Password

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12333:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Password Management: Hardcoded Password
> ---
>
> Key: CASSANDRA-12333
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12333
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Hardcoded passwords may compromise system security in a way that cannot be 
> easily remedied. In CassandraRoleManager.java on line 77 the default 
> superuser password is set to "cassandra".
> CassandraRoleManager.java, lines 72-77:
> {code:java}
> 72 public class CassandraRoleManager implements IRoleManager
> 73 {
> 74 private static final Logger logger = 
> LoggerFactory.getLogger(CassandraRoleManager.class);
> 75 
> 76 static final String DEFAULT_SUPERUSER_NAME = "cassandra";
> 77 static final String DEFAULT_SUPERUSER_PASSWORD = "cassandra";
> CassandraRoleManager.java, lines 326-338:
> 326 private static void setupDefaultRole()
> 327 {
> 328 try
> 329 {
> 330 if (!hasExistingRoles())
> 331 {
> 332 QueryProcessor.process(String.format("INSERT INTO %s.%s 
> (role, is_superuser, can_login, salted_hash) " +
> 333  "VALUES ('%s', true, 
> true, '%s')",
> 334  AuthKeyspace.NAME,
> 335  AuthKeyspace.ROLES,
> 336  DEFAULT_SUPERUSER_NAME,
> 337  
> escape(hashpw(DEFAULT_SUPERUSER_PASSWORD))),
> 338
> consistencyForRole(DEFAULT_SUPERUSER_NAME));
> {code}



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

[jira] [Commented] (CASSANDRA-12253) Fix exceptions when enabling gossip on proxy nodes.

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-12253:
---

That assertion is hit in {{getLocalTokens}} - my proposed patch would no longer 
use that and instead would use {{SystemKeyspace.getSavedTokens}} directly. This 
is the approach we use 
[elsewhere|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StorageService.java#L665]
 in the flow for join_ring.

The specific case that your patch changes the behavior for is that in which we 
have a regular healthy node that leaves the ring for some period of time, and 
we want to bring it back by using join_ring=False and running a repair. During 
this process, if you stopped and then started gossip, the gossip states would 
no longer have the appropriate tokens entry.

> Fix exceptions when enabling gossip on proxy nodes.
> ---
>
> Key: CASSANDRA-12253
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12253
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Minor
> Fix For: 2.2.x
>
> Attachments: 0001-for-proxy-node-not-set-gossip-tokens.patch
>
>
> We have a tier of Cassandra nodes running with join_ring=false flag, which we 
> call proxy nodes, and they will never join the ring.
> The problem is that sometimes we need to disable and enable the gossip on 
> those nodes, and `nodetool enablegossip` throws exceptions when we do that:
> {code}
> java.lang.AssertionError
> at 
> org.apache.cassandra.service.StorageService.getLocalTokens(StorageService.java:2213)
> at 
> org.apache.cassandra.service.StorageService.startGossiping(StorageService.java:371)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
> at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at 

[jira] [Updated] (CASSANDRA-12310) Use of getByName() to retrieve IP address

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12310:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Use of getByName() to retrieve IP address
> -
>
> Key: CASSANDRA-12310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12310
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> There are many places in the Cassandra source code that rely upon a call to 
> getByName() to retrieve an IP address. The information returned by 
> getByName() is not trustworthy. Attackers can spoof DNS entries and depending 
> on getByName alone invites DNS spoofing attacks.
> getByName() is used in multiple locations within the CASSANDRA source code:
> DatabaseDescriptor.java Line 193, 213, 233, 254, 947, 949
> RingCache.java Line 82
> InetAddressType.java Line 52
> FailureDetector.java Line 186
> Gossiper.java Line 228, 571, 1517, 1522
> CqlBulkRecordWriter.java Line 142, 301
> HintsService.java Line 265
> DynamicEndpointSnitch.java Line 320
> Ec2MultiRegionSnitch.java Line 49
> EndpointSnitchInfo.java Line 46, 51
> PropertyFileSnitch.java Line 175
> ReconnectableSnitchHelper.java Line 52
> SimpleSeedProvider.java Line 55
> MessagingService.java Line 943
> StorageService.java Line 1766, 1835, 2526
> ProgressInfoCompositeData.java Line 96
> SessionInfoCompositeData.java Line 126, 127
> BulkLoader.java Line 399, 422
> SetHostStat.java Line 50
> This is an example from the file DatabaseDescriptor.java where there are 
> examples of the use of getByName() on line 193, 213, 233, 254, 947 and 949.
> DatabaseDescriptor.java, lines 231-238:
> {code:java}
> 231 try
> 232 {
> 233 rpcAddress = InetAddress.getByName(config.rpc_address);
> 234 }
> 235 catch (UnknownHostException e)
> 236 {
> 237 throw new ConfigurationException("Unknown host in rpc_address " + 
> config.rpc_address, false);
> 238 }
> {code}



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

[jira] [Updated] (CASSANDRA-12322) Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select Classes or Code

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12322:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select 
> Classes or Code
> --
>
> Key: CASSANDRA-12322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12322
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Dynamically loaded code has the potential to be malicious. The application 
> uses external input to select which classes or code to use, but it does not 
> sufficiently prevent the input from selecting improper classes or code.
> The snippet below shows the issue on lines 112-116 by instantiating a class 
> by name.
> FastByteOperations.java, lines 103-127:
> {code:java}
> 103 static ByteOperations getBest()
> 104 {
> 105 String arch = System.getProperty("os.arch");
> 106 boolean unaligned = arch.equals("i386") || arch.equals("x86")
> 107 || arch.equals("amd64") || 
> arch.equals("x86_64") || arch.equals("s390x");
> 108 if (!unaligned)
> 109 return new PureJavaOperations();
> 110 try
> 111 {
> 112 Class theClass = Class.forName(UNSAFE_COMPARER_NAME);
> 113 
> 114 // yes, UnsafeComparer does implement Comparer
> 115 @SuppressWarnings("unchecked")
> 116 ByteOperations comparer = (ByteOperations) 
> theClass.getConstructor().newInstance();
> 117 return comparer;
> 118 }
> 119 catch (Throwable t)
> 120 {
> 121 JVMStabilityInspector.inspectThrowable(t);
> 122 // ensure we really catch *everything*
> 123 return new PureJavaOperations();
> 124 }
> 125 }
> 126 
> 127 }
> {code}



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

[jira] [Updated] (CASSANDRA-12318) Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select Classes or Code

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12318:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select 
> Classes or Code
> --
>
> Key: CASSANDRA-12318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12318
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Dynamically loaded code has the potential to be malicious. The application 
> uses external input to select which classes or code to use, but it does not 
> sufficiently prevent the input from selecting improper classes or code.
> The snippet below shows the issue on lines 144-146 by instantiating an object 
> associated with a class by name.
> CacheService.java, lines 135-162:
> {code:java}
> 135 private AutoSavingCache initRowCache()
> 136 {
> 137 logger.info("Initializing row cache with capacity of {} MBs", 
> DatabaseDescriptor.getRowCacheSizeInMB());
> 138 
> 139 CacheProvider cacheProvider;
> 140 String cacheProviderClassName = 
> DatabaseDescriptor.getRowCacheSizeInMB() > 0
> 141 ? 
> DatabaseDescriptor.getRowCacheClassName() : 
> "org.apache.cassandra.cache.NopCacheProvider";
> 142 try
> 143 {
> 144 Class> 
> cacheProviderClass =
> 145 (Class>) 
> Class.forName(cacheProviderClassName);
> 146 cacheProvider = cacheProviderClass.newInstance();
> 147 }
> 148 catch (Exception e)
> 149 {
> 150 throw new RuntimeException("Cannot find configured row cache 
> provider class " + DatabaseDescriptor.getRowCacheClassName());
> 151 }
> 152 
> 153 // cache object
> 154 ICache rc = cacheProvider.create();
> 155 AutoSavingCache rowCache = new 
> AutoSavingCache<>(rc, CacheType.ROW_CACHE, new RowCacheSerializer());
> 156 
> 157 int rowCacheKeysToSave = DatabaseDescriptor.getRowCacheKeysToSave();
> 158 
> 159 rowCache.scheduleSaving(DatabaseDescriptor.getRowCacheSavePeriod(), 
> rowCacheKeysToSave);
> 160 
> 161 return rowCache;
> 162 }
> {code}



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

[jira] [Updated] (CASSANDRA-12317) Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select Classes or Code

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12317:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select 
> Classes or Code
> --
>
> Key: CASSANDRA-12317
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12317
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Dynamically loaded code has the potential to be malicious. The application 
> uses external input to select which classes or code to use, but it does not 
> sufficiently prevent the input from selecting improper classes or code.
> The snippet below shows the issue which ends on line 198 by returning an 
> object associated with a class by name.
> CompressionParams.java, lines 190-204:
> {code:java}
> 190 private static Class parseCompressorClass(String className) throws 
> ConfigurationException
> 191 {
> 192 if (className == null || className.isEmpty())
> 193 return null;
> 194 
> 195 className = className.contains(".") ? className : 
> "org.apache.cassandra.io.compress." + className;
> 196 try
> 197 {
> 198 return Class.forName(className);
> 199 }
> 200 catch (Exception e)
> 201 {
> 202 throw new ConfigurationException("Could not create Compression 
> for type " + className, e);
> 203 }
> 204 }
> {code}



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

[jira] [Updated] (CASSANDRA-12321) Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select Classes or Code

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12321:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select 
> Classes or Code
> --
>
> Key: CASSANDRA-12321
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12321
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Dynamically loaded code has the potential to be malicious. The application 
> uses external input to select which classes or code to use, but it does not 
> sufficiently prevent the input from selecting improper classes or code.
> The snippet below shows the issue on lines 523-532 by instantiating a class 
> by name.
> CoalescingStrategies.java, lines 494-538:
> {code:java}
> 494 @VisibleForTesting
> 495 static CoalescingStrategy newCoalescingStrategy(String strategy,
> 496 int coalesceWindow,
> 497 Parker parker,
> 498 Logger logger,
> 499 String displayName)
> 500 {
> 501 String classname = null;
> 502 String strategyCleaned = strategy.trim().toUpperCase();
> 503 switch(strategyCleaned)
> 504 {
> 505 case "MOVINGAVERAGE":
> 506 classname = MovingAverageCoalescingStrategy.class.getName();
> 507 break;
> 508 case "FIXED":
> 509 classname = FixedCoalescingStrategy.class.getName();
> 510 break;
> 511 case "TIMEHORIZON":
> 512 classname = 
> TimeHorizonMovingAverageCoalescingStrategy.class.getName();
> 513 break;
> 514 case "DISABLED":
> 515 classname = DisabledCoalescingStrategy.class.getName();
> 516 break;
> 517 default:
> 518 classname = strategy;
> 519 }
> 520 
> 521 try
> 522 {
> 523 Class clazz = Class.forName(classname);
> 524 
> 525 if (!CoalescingStrategy.class.isAssignableFrom(clazz))
> 526 {
> 527 throw new RuntimeException(classname + " is not an instance 
> of CoalescingStrategy");
> 528 }
> 529 
> 530 Constructor constructor = clazz.getConstructor(int.class, 
> Parker.class, Logger.class, String.class);
> 531 
> 532 return 
> (CoalescingStrategy)constructor.newInstance(coalesceWindow, parker, logger, 
> displayName);
> 533 }
> 534 catch (Exception e)
> 535 {
> 536 throw new RuntimeException(e);
> 537 }
> 538 }
> {code}



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

[jira] [Updated] (CASSANDRA-12319) Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select Classes or Code

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12319:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select 
> Classes or Code
> --
>
> Key: CASSANDRA-12319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12319
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Dynamically loaded code has the potential to be malicious. The application 
> uses external input to select which classes or code to use, but it does not 
> sufficiently prevent the input from selecting improper classes or code.
> The snippet below shows the issue which ends on line 63 by instantiating a 
> class by name.
> TServerCustomFactory.java, lines 41-73:
> {code:java}
> 41 public TServer buildTServer(TServerFactory.Args args)
> 42 {
> 43 TServer server;
> 44 if (ThriftServer.SYNC.equalsIgnoreCase(serverType))
> 45 {
> 46 server = new CustomTThreadPoolServer.Factory().buildTServer(args);
> 47 }
> 48 else if(ThriftServer.ASYNC.equalsIgnoreCase(serverType))
> 49 {
> 50 server = new CustomTNonBlockingServer.Factory().buildTServer(args);
> 51 logger.info(String.format("Using non-blocking/asynchronous thrift 
> server on %s : %s", args.addr.getHostName(), args.addr.getPort()));
> 52 }
> 53 else if(ThriftServer.HSHA.equalsIgnoreCase(serverType))
> 54 {
> 55 server = new THsHaDisruptorServer.Factory().buildTServer(args);
> 56 logger.info(String.format("Using custom half-sync/half-async 
> thrift server on %s : %s", args.addr.getHostName(), args.addr.getPort()));
> 57 }
> 58 else
> 59 {
> 60 TServerFactory serverFactory;
> 61 try
> 62 {
> 63 serverFactory = (TServerFactory) 
> Class.forName(serverType).newInstance();
> 64 }
> 65 catch (Exception e)
> 66 {
> 67 throw new RuntimeException("Failed to instantiate server 
> factory:" + serverType, e);
> 68 }
> 69 server = serverFactory.buildTServer(args);
> 70 logger.info(String.format("Using custom thrift server %s on %s : 
> %s", server.getClass().getName(), args.addr.getHostName(), 
> args.addr.getPort()));
> 71 }
> 72 return server;
> 73 }
> {code}



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

[jira] [Updated] (CASSANDRA-12320) Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select Classes or Code

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12320:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select 
> Classes or Code
> --
>
> Key: CASSANDRA-12320
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12320
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Dynamically loaded code has the potential to be malicious. The application 
> uses external input to select which classes or code to use, but it does not 
> sufficiently prevent the input from selecting improper classes or code.
> The snippet below shows the issue on lines 537-539 and 568 by instantiating a 
> class by name.
> BulkLoader.java, lines 521-577:
> {code:java}
> 521 public LoaderOptions validateArguments()
> 522 {
> 523 // Both username and password need to be provided
> 524 if ((user != null) != (passwd != null))
> 525 errorMsg("Username and password must both be provided", 
> getCmdLineOptions());
> 526 
> 527 if (user != null)
> 528 {
> 529 // Support for 3rd party auth providers that support plain text 
> credentials.
> 530 // In this case the auth provider must provide a constructor of 
> the form:
> 531 //
> 532 // public MyAuthProvider(String username, String password)
> 533 if (authProviderName != null)
> 534 {
> 535 try
> 536 {
> 537 Class authProviderClass = Class.forName(authProviderName);
> 538 Constructor constructor = 
> authProviderClass.getConstructor(String.class, String.class);
> 539 authProvider = 
> (AuthProvider)constructor.newInstance(user, passwd);
> 540 }
> 541 catch (ClassNotFoundException e)
> 542 {
> 543 errorMsg("Unknown auth provider: " + e.getMessage(), 
> getCmdLineOptions());
> 544 }
> 545 catch (NoSuchMethodException e)
> 546 {
> 547 errorMsg("Auth provider does not support plain text 
> credentials: " + e.getMessage(), getCmdLineOptions());
> 548 }
> 549 catch (InstantiationException | IllegalAccessException | 
> IllegalArgumentException | InvocationTargetException e)
> 550 {
> 551 errorMsg("Could not create auth provider with plain text 
> credentials: " + e.getMessage(), getCmdLineOptions());
> 552 }
> 553 }
> 554 else
> 555 {
> 556 // If a 3rd party auth provider wasn't provided use the 
> driver plain text provider
> 557 authProvider = new PlainTextAuthProvider(user, passwd);
> 558 }
> 559 }
> 560 // Alternate support for 3rd party auth providers that don't use 
> plain text credentials.
> 561 // In this case the auth provider must provide a nullary constructor 
> of the form:
> 562 //
> 563 // public MyAuthProvider()
> 564 else if (authProviderName != null)
> 565 {
> 566 try
> 567 {
> 568 authProvider = 
> (AuthProvider)Class.forName(authProviderName).newInstance();
> 569 }
> 570 catch (ClassNotFoundException | InstantiationException | 
> IllegalAccessException e)
> 571 {
> 572 errorMsg("Unknown auth provider" + e.getMessage(), 
> getCmdLineOptions());
> 573 }
> 574 }
> 575 
> 576 return this;
> 577 }
> {code}



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

[jira] [Updated] (CASSANDRA-12304) Privacy Violation - Heap Inspection

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12304:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Privacy Violation - Heap Inspection
> ---
>
> Key: CASSANDRA-12304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12304
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> In the file BulkLoader.java on line 387 a string object is used to store 
> sensitive data. String objects are immutable and should not be used to store 
> sensitive data. Sensitive data should be stored in char or byte arrays and 
> the contents of those arrays should be cleared ASAP. Operations performed on 
> string objects will require that the original object be copied and the 
> operation be applied in the new copy of the string object. This results in 
> the likelihood that multiple copies of sensitive data will be present in the 
> heap until garbage collection takes place.
> The snippet below shows the issue on line 387:
> BulkLoader.java, lines 318-387:
> {code:java}
> 318 public String passwd;
> . . .
> 337 public static LoaderOptions parseArgs(String cmdArgs[])
> 338 {
> 339 CommandLineParser parser = new GnuParser();
> 340 CmdLineOptions options = getCmdLineOptions();
> 341 try
> 342 {
> . . .
> 386 if (cmd.hasOption(PASSWD_OPTION))
> 387 opts.passwd = cmd.getOptionValue(PASSWD_OPTION);
> {code}



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

[jira] [Updated] (CASSANDRA-12306) Privacy VIolation - Heap Inspection

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12306:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Privacy VIolation - Heap Inspection
> ---
>
> Key: CASSANDRA-12306
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12306
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> In the file NodeTool.java on lines 239, 242 and 291 a string object is used 
> to store sensitive data. String objects are immutable and should not be used 
> to store sensitive data. Sensitive data should be stored in char or byte 
> arrays and the contents of those arrays should be cleared ASAP. Operations 
> performed on string objects will require that the original object be copied 
> and the operation be applied in the new copy of the string object. This 
> results in the likelihood that multiple copies of sensitive data will be 
> present in the heap until garbage collection takes place.
> The snippet below shows the issue on line 239 and 242:
> NodeTool.java, lines 229-243:
> {code:java}
> 229 private String password = EMPTY;
> 230 
> 231 @Option(type = OptionType.GLOBAL, name = {"-pwf", "--password-file"}, 
> description = "Path to the JMX password file")
> 232 private String passwordFilePath = EMPTY;
> 233 
> 234 @Override
> 235 public void run()
> 236 {
> 237 if (isNotEmpty(username)) {
> 238 if (isNotEmpty(passwordFilePath))
> 239 password = readUserPasswordFromFile(username, 
> passwordFilePath);
> 240 
> 241 if (isEmpty(password))
> 242 password = promptAndReadPassword();
> 243 }
> {code}



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

[jira] [Updated] (CASSANDRA-12309) Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select Classes or Code

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12309:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select 
> Classes or Code
> --
>
> Key: CASSANDRA-12309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12309
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Dynamically loaded code has the potential to be malicious. The application 
> uses external input to select which classes or code to use, but it does not 
> sufficiently prevent the input from selecting improper classes or code.
> The snippet below shows the issue on line 588 and the method returns a new 
> instance on line 594 or 598.
> CqlConfigHelper.java, lines 584-605:
> {code:java}
> 584 private static AuthProvider getClientAuthProvider(String 
> factoryClassName, Configuration conf)
> 585 {
> 586 try
> 587 {
> 588 Class c = Class.forName(factoryClassName);
> 589 if (PlainTextAuthProvider.class.equals(c))
> 590 {
> 591 String username = getStringSetting(USERNAME, conf).or("");
> 592 String password = getStringSetting(PASSWORD, conf).or("");
> 593 return (AuthProvider) c.getConstructor(String.class, 
> String.class)
> 594 .newInstance(username, password);
> 595 }
> 596 else
> 597 {
> 598 return (AuthProvider) c.newInstance();
> 599 }
> 600 }
> 601 catch (Exception e)
> 602 {
> 603 throw new RuntimeException("Failed to instantiate auth provider:" 
> + factoryClassName, e);
> 604 }
> 605 }
> {code}



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

[jira] [Commented] (CASSANDRA-11949) GC log directory should be created in startup scripts

[Michael Shuler (JIRA)]

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

Michael Shuler commented on CASSANDRA-11949:


Are we talking about debian packages or the -bin.tar.gz? Both? 

The debian packages create the directories here: 
https://github.com/apache/cassandra/blob/trunk/debian/dirs
The logs directory is set to /var/log/cassandra, so looking at this: 
https://github.com/apache/cassandra/compare/trunk...mm-binary:11949-2.2
..that is incorrect for a deb installation. Logs should not be written to a 
directory under $CASSANDRA_HOME (/usr/share/cassandra in deb's case), nor 
should a directory be made there by a startup file. This would mean keeping 2 
different cassandra-env.sh files, which isn't the end of the world, but 
unfortunate.

I think the correct thing to do in the case of debian packages is to write 
gc.log to the correct log location, which already exists at deb install time, 
not create a new log dir in the wrong location in -env.sh.

> GC log directory should be created in startup scripts
> -
>
> Key: CASSANDRA-11949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11949
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Mahdi Mohammadi
>Priority: Minor
> Fix For: 2.2.8, 3.0.9, 3.9
>
>
> In [CASSANDRA-10140], we enabled GC logging by default, since the overhead 
> was low and asking people providing diagnostics to restart can often make it 
> more difficult to diagnose problems.
> The default GC log path is set to {{$CASSANDRA_HOME/logs/gc.log}} in 
> {{cassandra-env.sh}}, a directory that is not present in a fresh 
> clone/install. Even if logback creates this directory later in startup, it is 
> not present when the JVM initiates GC logging, so GC logging will silently 
> fail for this first Cassandra run
> I haven't tested this in Windows but suspect the same problem may occur. 
> Since lots of tooling around Cassandra won't create this directory, we should 
> instead consider attempting to create it in our startup scripts.



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

[jira] [Updated] (CASSANDRA-12308) Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select Classes or Code

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12308:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select 
> Classes or Code
> --
>
> Key: CASSANDRA-12308
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12308
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Dynamically loaded code has the potential to be malicious. The application 
> uses external input to select which classes or code to use, but it does not 
> sufficiently prevent the input from selecting improper classes or code.
> The snippet below shows the issue which ends on line 585 by instantiating a 
> class by name.
> ConfigHelper.java, lines 558-591:
> {code:java}
> 558 @SuppressWarnings("resource")
> 559 public static Cassandra.Client createConnection(Configuration conf, 
> String host, Integer port) throws IOException
> 560 {
> 561 try
> 562 {
> 563 TTransport transport = 
> getClientTransportFactory(conf).openTransport(host, port);
> 564 return new Cassandra.Client(new TBinaryProtocol(transport, true, 
> true));
> 565 }
> 566 catch (Exception e)
> 567 {
> 568 throw new IOException("Unable to connect to server " + host + ":" 
> + port, e);
> 569 }
> 570 }
> 571 
> 572 public static ITransportFactory getClientTransportFactory(Configuration 
> conf)
> 573 {
> 574 String factoryClassName = conf.get(ITransportFactory.PROPERTY_KEY, 
> TFramedTransportFactory.class.getName());
> 575 ITransportFactory factory = 
> getClientTransportFactory(factoryClassName);
> 576 Map options = getOptions(conf, 
> factory.supportedOptions());
> 577 factory.setOptions(options);
> 578 return factory;
> 579 }
> 580 
> 581 private static ITransportFactory getClientTransportFactory(String 
> factoryClassName)
> 582 {
> 583 try
> 584 {
> 585 return (ITransportFactory) 
> Class.forName(factoryClassName).newInstance();
> 586 }
> 587 catch (Exception e)
> 588 {
> 589 throw new RuntimeException("Failed to instantiate transport 
> factory:" + factoryClassName, e);
> 590 }
> 591 }
> {code}



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

[jira] [Updated] (CASSANDRA-12295) Double check locking pattern

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12295:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Double check locking pattern
> 
>
> Key: CASSANDRA-12295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12295
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> The file ketspace.java includes a double check locking pattern. The double 
> check locking pattern is an incorrect idiom that does not achieve its 
> intended effect.For more information see LCK-10J in the CERT Oracle Coding 
> Standard for Java 
> https://www.securecoding.cert.org/confluence/display/java/LCK10-J.+Use+a+correct+form+of+the+double-checked+locking+idiom
> The snippet below shows the double check locking pattern:
> Keyspace.java, lines 115-135:
> {code:java}
> 115 private static Keyspace open(String keyspaceName, Schema schema, boolean 
> loadSSTables)
> 116 {
> 117 Keyspace keyspaceInstance = schema.getKeyspaceInstance(keyspaceName);
> 118 
> 119 if (keyspaceInstance == null)
> 120 {
> 121 // instantiate the Keyspace.  we could use putIfAbsent but it's 
> important to making sure it is only done once
> 122 // per keyspace, so we synchronize and re-check before doing it.
> 123 synchronized (Keyspace.class)
> 124 {
> 125 keyspaceInstance = schema.getKeyspaceInstance(keyspaceName);
> 126 if (keyspaceInstance == null)
> 127 {
> 128 // open and store the keyspace
> 129 keyspaceInstance = new Keyspace(keyspaceName, 
> loadSSTables);
> 130 schema.storeKeyspaceInstance(keyspaceInstance);
> 131 }
> 132 }
> 133 }
> 134 return keyspaceInstance;
> 135 }
> {code}



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

[jira] [Updated] (CASSANDRA-12297) Privacy VIolation - Heap Inspection

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12297:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Privacy VIolation - Heap Inspection
> ---
>
> Key: CASSANDRA-12297
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12297
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>Assignee: Jason Brown
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included 
> an automated analysis using HP Fortify v4.21 SCA and a manual analysis 
> utilizing SciTools Understand v4. The results of that 
> analysis includes the issue below.
> Issue:
> In the file PasswordAuthenticator.java on line 129, 164 and 222 a string 
> object is used to store sensitive data. String objects are immutable and 
> should not be used to store sensitive data. Sensitive data should be stored 
> in char or byte arrays and the contents of those arrays should be cleared 
> ASAP. Operations performed on string objects will require that the original 
> object be copied and the operation be applied in the new copy of the string 
> object. This results in the likelihood that multiple copies of sensitive data 
> being present in the heap until garbage collection takes place.
> The snippet below shows the issue on line 129:
> PasswordAuthenticator.java, lines 123-134:
> {code:java}
> 123 public AuthenticatedUser legacyAuthenticate(Map 
> credentials) throws AuthenticationException
> 124 {
> 125 String username = credentials.get(USERNAME_KEY);
> 126 if (username == null)
> 127 throw new AuthenticationException(String.format("Required key 
> '%s' is missing", USERNAME_KEY));
> 128 
> 129 String password = credentials.get(PASSWORD_KEY);
> 130 if (password == null)
> 131 throw new AuthenticationException(String.format("Required key 
> '%s' is missing", PASSWORD_KEY));
> 132 
> 133 return authenticate(username, password);
> 134 }
> {code}



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

[jira] [Updated] (CASSANDRA-12305) Privacy VIolation - Heap Inspection

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12305:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Privacy VIolation - Heap Inspection
> ---
>
> Key: CASSANDRA-12305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12305
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
> Fix For: 3.0.x
>
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> In the file NodeProbe.java on lines 139 and 181 a string object is used to 
> store sensitive data. String objects are immutable and should not be used to 
> store sensitive data. Sensitive data should be stored in char or byte arrays 
> and the contents of those arrays should be cleared ASAP. Operations performed 
> on string objects will require that the original object be copied and the 
> operation be applied in the new copy of the string object. This results in 
> the likelihood that multiple copies of sensitive data will be present in the 
> heap until garbage collection takes place.
> The snippet below shows the issue on line 139:
> NodeProbe.java, lines 105-141:
> {code:java}
> 105 private String password;
> . . .
> 131 public NodeProbe(String host, int port, String username, String password) 
> throws IOException
> 132 {
> 133 assert username != null && !username.isEmpty() && password != null && 
> !password.isEmpty()
> 134: "neither username nor password can be blank";
> 135 
> 136 this.host = host;
> 137 this.port = port;
> 138 this.username = username;
> 139 this.password = password;
> 140 connect();
> 141 }
> {code}



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

[jira] [Updated] (CASSANDRA-12307) Command Injection

[Jonathan Ellis (JIRA)]

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

Jonathan Ellis updated CASSANDRA-12307:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> Command Injection
> -
>
> Key: CASSANDRA-12307
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12307
> Project: Cassandra
>  Issue Type: Sub-task
>Reporter: Eduardo Aguinaga
>Priority: Critical
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Two commands, archiveCommand and restoreCommand, are stored as string 
> properties and retrieved on lines 91 and 92 of CommitLogArchiver.java. The 
> only processing performed on the command strings is that tokens are replaced 
> by data available at runtime. 
> A malicious command could be entered into the system by storing the malicious 
> command in place of the valid archiveCommand or restoreCommand. The malicious 
> command would then be executed on line 265 within the exec method.
> Any commands that are stored and retrieved should be verified prior to 
> execution. Assuming that the command is safe because it is stored as a local 
> property invites security issues.
> {code:java}
> CommitLogArchiver.java, lines 91-92:
> 91 String archiveCommand = commitlog_commands.getProperty("archive_command");
> 92 String restoreCommand = commitlog_commands.getProperty("restore_command");
> CommitLogArchiver.java, lines 261-266:
> 261 private void exec(String command) throws IOException
> 262 {
> 263 ProcessBuilder pb = new ProcessBuilder(command.split(" "));
> 264 pb.redirectErrorStream(true);
> 265 FBUtilities.exec(pb);
> 266 }
> CommitLogArchiver.java, lines 152-166:
> 152 public void maybeArchive(final String path, final String name)
> 153 {
> 154 if (Strings.isNullOrEmpty(archiveCommand))
> 155 return;
> 156 
> 157 archivePending.put(name, executor.submit(new WrappedRunnable()
> 158 {
> 159 protected void runMayThrow() throws IOException
> 160 {
> 161 String command = archiveCommand.replace("%name", name);
> 162 command = command.replace("%path", path);
> 163 exec(command);
> 164 }
> 165 }));
> 166 }
> {code}



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

[jira] [Commented] (CASSANDRA-12253) Fix exceptions when enabling gossip on proxy nodes.

[Dikang Gu (JIRA)]

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

Dikang Gu commented on CASSANDRA-12253:
---

[~jkni], thanks for looking this! The exception was thrown at this line

{code}
assert tokens != null && !tokens.isEmpty(); // should not be called before 
initServer sets this
{code}

I think your patch can not prevent this, and I'm not sure if it's safe to 
remove the assertion.

For my patch, if the node already joined the ring, or it should join the ring, 
we should always expect to be able to get the tokens and set them, right?

> Fix exceptions when enabling gossip on proxy nodes.
> ---
>
> Key: CASSANDRA-12253
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12253
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Minor
> Fix For: 2.2.x
>
> Attachments: 0001-for-proxy-node-not-set-gossip-tokens.patch
>
>
> We have a tier of Cassandra nodes running with join_ring=false flag, which we 
> call proxy nodes, and they will never join the ring.
> The problem is that sometimes we need to disable and enable the gossip on 
> those nodes, and `nodetool enablegossip` throws exceptions when we do that:
> {code}
> java.lang.AssertionError
> at 
> org.apache.cassandra.service.StorageService.getLocalTokens(StorageService.java:2213)
> at 
> org.apache.cassandra.service.StorageService.startGossiping(StorageService.java:371)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
> at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {code}



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

[jira] [Created] (CASSANDRA-12334) HP Fortify Analysis

[Jonathan Ellis (JIRA)]

Jonathan Ellis created CASSANDRA-12334:
--

 Summary: HP Fortify Analysis
 Key: CASSANDRA-12334
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12334
 Project: Cassandra
  Issue Type: Bug
Reporter: Jonathan Ellis
Priority: Minor






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

[jira] [Assigned] (CASSANDRA-12313) dtest failure in replace_address_test.TestReplaceAddress.replace_with_insufficient_replicas_test

[Joel Knighton (JIRA)]

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

Joel Knighton reassigned CASSANDRA-12313:
-

Assignee: Joel Knighton  (was: DS Test Eng)

> dtest failure in 
> replace_address_test.TestReplaceAddress.replace_with_insufficient_replicas_test
> 
>
> Key: CASSANDRA-12313
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12313
> Project: Cassandra
>  Issue Type: Test
>Reporter: Craig Kodman
>Assignee: Joel Knighton
>  Labels: dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log, 
> node4.log, node4_debug.log, node4_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/cassandra-2.2_dtest_jdk8/288/testReport/replace_address_test/TestReplaceAddress/replace_with_insufficient_replicas_test



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

[jira] [Updated] (CASSANDRA-11687) dtest failure in rebuild_test.TestRebuild.simple_rebuild_test

[Yuki Morishita (JIRA)]

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

Yuki Morishita updated CASSANDRA-11687:
---
Status: Patch Available  (was: Open)

> dtest failure in rebuild_test.TestRebuild.simple_rebuild_test
> -
>
> Key: CASSANDRA-11687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11687
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Russ Hatch
>Assignee: Yuki Morishita
>  Labels: dtest
>
> single failure on most recent run (3.0 no-vnode)
> {noformat}
> concurrent rebuild should not be allowed, but one rebuild command should have 
> succeeded.
> {noformat}
> http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/217/testReport/rebuild_test/TestRebuild/simple_rebuild_test
> Failed on CassCI build cassandra-3.0_novnode_dtest #217



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

[jira] [Commented] (CASSANDRA-11687) dtest failure in rebuild_test.TestRebuild.simple_rebuild_test

[Yuki Morishita (JIRA)]

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

Yuki Morishita commented on CASSANDRA-11687:


dtest PR here: https://github.com/riptano/cassandra-dtest/pull/1146

> dtest failure in rebuild_test.TestRebuild.simple_rebuild_test
> -
>
> Key: CASSANDRA-11687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11687
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Russ Hatch
>Assignee: Yuki Morishita
>  Labels: dtest
>
> single failure on most recent run (3.0 no-vnode)
> {noformat}
> concurrent rebuild should not be allowed, but one rebuild command should have 
> succeeded.
> {noformat}
> http://cassci.datastax.com/job/cassandra-3.0_novnode_dtest/217/testReport/rebuild_test/TestRebuild/simple_rebuild_test
> Failed on CassCI build cassandra-3.0_novnode_dtest #217



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

[jira] [Commented] (CASSANDRA-10810) Make rebuild operations resumable

[Kaide Mu (JIRA)]

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

Kaide Mu commented on CASSANDRA-10810:
--

Pull request created. https://github.com/riptano/cassandra-dtest/pull/1145/files
Thanks.

> Make rebuild operations resumable
> -
>
> Key: CASSANDRA-10810
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10810
> Project: Cassandra
>  Issue Type: Wish
>  Components: Streaming and Messaging
>Reporter: Jeremy Hanna
>Assignee: Kaide Mu
> Fix For: 3.x
>
>
> Related to CASSANDRA-8942, now that we can resume bootstrap operations, this 
> could also be possible with rebuild operations, such as when you bootstrap 
> new nodes in a completely new datacenter in two steps.



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

[jira] [Commented] (CASSANDRA-11126) select_distinct_with_deletions_test failing on non-vnode environments

[Jim Witschey (JIRA)]

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

Jim Witschey commented on CASSANDRA-11126:
--

Yeah, there's been some UI churn as we've been 1) trying to remove our 
dependence on environment variables and 2) trying to make the upgrade tests 
more maintainable. Sorry about that. The following command demonstrates that 
this is still a bug:

{code}
RUN_STATIC_UPGRADE_MATRIX=true CASSANDRA_VERSION=git:trunk 
JAVA8_HOME=/usr/lib/jvm/java-8-oracle JAVA7_HOME=/usr/lib/jvm/java-7-oracle 
./run_dtests.py --vnodes false  --nose-options='-v' 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_2_x_To_indev_3_0_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_2_x_To_indev_3_x.select_distinct_with_deletions_test
{code}

To run these upgrade tests upgrading to a version in a local directory, you can 
do the following:

{code}
LOCAL_GIT_REPO=/home/mambocab/cstar_src/cassandra 
CASSANDRA_VERSION=local:ccm_local_demo_branch 
JAVA8_HOME=/usr/lib/jvm/java-8-oracle JAVA7_HOME=/usr/lib/jvm/java-7-oracle 
./run_dtests.py --vnodes false  --nose-options='-vv' 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_2_x_To_indev_3_0_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_2_x_To_indev_3_x.select_distinct_with_deletions_test
 
{code}

Depending on the C* version at the branch specified in {{CASSANDRA_VERSION}}, 
each test will either run or be skipped. If the branch is on the 3.0 line, 
it'll be upgraded to in the {{*_3.0.x}} classes, and if it's on the 3.X line, 
it'll be upgraded to in the {{*_3.x}} test classes. Otherwise, the test will be 
skipped.

Sorry again for the interface churn; this could definitely use some 
documentation

> select_distinct_with_deletions_test failing on non-vnode environments
> -
>
> Key: CASSANDRA-11126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11126
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Ryan McGuire
>Assignee: Sylvain Lebresne
>  Labels: dtest
> Fix For: 3.0.x
>
>
> Looks like this was fixed in CASSANDRA-10762, but not for non-vnode 
> environments:
> {code}
> $ DISABLE_VNODES=yes KEEP_TEST_DIR=yes CASSANDRA_VERSION=git:cassandra-3.0 
> PRINT_DEBUG=true nosetests -s -v 
> upgrade_tests/cql_tests.py:TestCQLNodes2RF1.select_distinct_with_deletions_test
> select_distinct_with_deletions_test 
> (upgrade_tests.cql_tests.TestCQLNodes2RF1) ... cluster ccm directory: 
> /tmp/dtest-UXb0un
> http://git-wip-us.apache.org/repos/asf/cassandra.git git:cassandra-3.0
> Custom init_config not found. Setting defaults.
> Done setting configuration options:
> {   'num_tokens': None,
> 'phi_convict_threshold': 5,
> 'range_request_timeout_in_ms': 1,
> 'read_request_timeout_in_ms': 1,
> 'request_timeout_in_ms': 1,
> 'truncate_request_timeout_in_ms': 1,
> 'write_request_timeout_in_ms': 1}
> getting default job version for 3.0.3
> UpgradePath(starting_version='binary:2.2.3', upgrade_version=None)
> starting from 2.2.3
> upgrading to {'install_dir': 
> '/home/ryan/.ccm/repository/gitCOLONcassandra-3.0'}
> Querying upgraded node
> FAIL
> ==
> FAIL: select_distinct_with_deletions_test 
> (upgrade_tests.cql_tests.TestCQLNodes2RF1)
> --
> Traceback (most recent call last):
>   File "/home/ryan/git/datastax/cassandra-dtest/upgrade_tests/cql_tests.py", 
> line 3360, in select_distinct_with_deletions_test
> self.assertEqual(9, len(rows))
> AssertionError: 9 != 8
>  >> begin captured logging << 
> dtest: DEBUG: cluster ccm directory: /tmp/dtest-UXb0un
> dtest: DEBUG: Custom init_config not found. Setting defaults.
> dtest: DEBUG: Done setting configuration options:
> {   'num_tokens': None,
> 'phi_convict_threshold': 5,
> 'range_request_timeout_in_ms': 1,
> 'read_request_timeout_in_ms': 1,
> 'request_timeout_in_ms': 1,
> 'truncate_request_timeout_in_ms': 1,
> 'write_request_timeout_in_ms': 1}
> dtest: DEBUG: getting default job 

[jira] [Comment Edited] (CASSANDRA-11126) select_distinct_with_deletions_test failing on non-vnode environments

[Jim Witschey (JIRA)]

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

Jim Witschey edited comment on CASSANDRA-11126 at 7/27/16 8:35 PM:
---

Yeah, there's been some UI churn as we've been 1) trying to remove our 
dependence on environment variables and 2) trying to make the upgrade tests 
more maintainable. Sorry about that. The following command demonstrates that 
this is still a bug:

{code}
RUN_STATIC_UPGRADE_MATRIX=true CASSANDRA_VERSION=git:trunk 
JAVA8_HOME=/usr/lib/jvm/java-8-oracle JAVA7_HOME=/usr/lib/jvm/java-7-oracle 
./run_dtests.py --vnodes false  --nose-options='-v' 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_2_x_To_indev_3_0_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_2_x_To_indev_3_x.select_distinct_with_deletions_test
{code}

To run these upgrade tests upgrading to a version in a local directory, you can 
do the following:

{code}
LOCAL_GIT_REPO=/home/mambocab/cstar_src/cassandra 
CASSANDRA_VERSION=local:ccm_local_demo_branch 
JAVA8_HOME=/usr/lib/jvm/java-8-oracle JAVA7_HOME=/usr/lib/jvm/java-7-oracle 
./run_dtests.py --vnodes false  --nose-options='-vv' 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_2_x_To_indev_3_0_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_2_x_To_indev_3_x.select_distinct_with_deletions_test
 
{code}

Depending on the C* version at the branch specified in {{CASSANDRA_VERSION}}, 
each test will either run or be skipped. If the branch is on the 3.0 line, 
it'll be upgraded to in the {{*_3.0.x}} classes, and if it's on the 3.X line, 
it'll be upgraded to in the {{*_3.x}} test classes. Otherwise, the test will be 
skipped.

Sorry again for the interface churn; this could definitely use some 
documentation


was (Author: mambocab):
Yeah, there's been some UI churn as we've been 1) trying to remove our 
dependence on environment variables and 2) trying to make the upgrade tests 
more maintainable. Sorry about that. The following command demonstrates that 
this is still a bug:

{code}
RUN_STATIC_UPGRADE_MATRIX=true CASSANDRA_VERSION=git:trunk 
JAVA8_HOME=/usr/lib/jvm/java-8-oracle JAVA7_HOME=/usr/lib/jvm/java-7-oracle 
./run_dtests.py --vnodes false  --nose-options='-v' 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_2_x_To_indev_3_0_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_2_x_To_indev_3_x.select_distinct_with_deletions_test
{code}

To run these upgrade tests upgrading to a version in a local directory, you can 
do the following:

{code}
LOCAL_GIT_REPO=/home/mambocab/cstar_src/cassandra 
CASSANDRA_VERSION=local:ccm_local_demo_branch 
JAVA8_HOME=/usr/lib/jvm/java-8-oracle JAVA7_HOME=/usr/lib/jvm/java-7-oracle 
./run_dtests.py --vnodes false  --nose-options='-vv' 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_0_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_3_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_2_x_To_indev_3_0_x.select_distinct_with_deletions_test
 
upgrade_tests/cql_tests.py:TestCQLNodes2RF1_Upgrade_current_2_2_x_To_indev_3_x.select_distinct_with_deletions_test
 
{code}

Depending on the C* version at the branch specified in {{CASSANDRA_VERSION}}, 
each test will either run or be skipped. If the branch is on the 3.0 line, 
it'll be upgraded to in the {{*_3.0.x}} classes, and if it's on the 3.X line, 
it'll be upgraded to in the {{*_3.x}} test classes. Otherwise, the test will be 
skipped.

Sorry again for the interface churn; this could definitely use some 
documentation

> select_distinct_with_deletions_test failing on non-vnode environments
> -
>
> Key: CASSANDRA-11126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11126
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Ryan McGuire
>

[jira] [Commented] (CASSANDRA-12236) RTE from new CDC column breaks in flight queries.

[Russ Hatch (JIRA)]

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

Russ Hatch commented on CASSANDRA-12236:


With any luck we'll get results on the autojobs created job here:

http://cassci.datastax.com/view/All_Jobs/job/pcmanus-upgrade_12236-upgrade/1/

> RTE from new CDC column breaks in flight queries.
> -
>
> Key: CASSANDRA-12236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12236
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jeremiah Jordan
>Assignee: Sylvain Lebresne
> Fix For: 3.x
>
> Attachments: 12236.txt
>
>
> This RTE is not harmless. It will cause the internode connection to break 
> which will cause all in flight requests between these nodes to die/timeout.
> {noformat}
> - Due to changes in schema migration handling and the storage format 
> after 3.0, you will
>   see error messages such as:
>  "java.lang.RuntimeException: Unknown column cdc during 
> deserialization"
>   in your system logs on a mixed-version cluster during upgrades. This 
> error message
>   is harmless and due to the 3.8 nodes having cdc added to their schema 
> tables while
>   the <3.8 nodes do not. This message should cease once all nodes are 
> upgraded to 3.8.
>   As always, refrain from schema changes during cluster upgrades.
> {noformat}



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

[jira] [Updated] (CASSANDRA-12253) Fix exceptions when enabling gossip on proxy nodes.

[Joel Knighton (JIRA)]

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

Joel Knighton updated CASSANDRA-12253:
--
Status: Awaiting Feedback  (was: Open)

> Fix exceptions when enabling gossip on proxy nodes.
> ---
>
> Key: CASSANDRA-12253
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12253
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Minor
> Fix For: 2.2.x
>
> Attachments: 0001-for-proxy-node-not-set-gossip-tokens.patch
>
>
> We have a tier of Cassandra nodes running with join_ring=false flag, which we 
> call proxy nodes, and they will never join the ring.
> The problem is that sometimes we need to disable and enable the gossip on 
> those nodes, and `nodetool enablegossip` throws exceptions when we do that:
> {code}
> java.lang.AssertionError
> at 
> org.apache.cassandra.service.StorageService.getLocalTokens(StorageService.java:2213)
> at 
> org.apache.cassandra.service.StorageService.startGossiping(StorageService.java:371)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
> at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {code}



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

[jira] [Updated] (CASSANDRA-12253) Fix exceptions when enabling gossip on proxy nodes.

[Joel Knighton (JIRA)]

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

Joel Knighton updated CASSANDRA-12253:
--
Status: Open  (was: Patch Available)

> Fix exceptions when enabling gossip on proxy nodes.
> ---
>
> Key: CASSANDRA-12253
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12253
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Minor
> Fix For: 2.2.x
>
> Attachments: 0001-for-proxy-node-not-set-gossip-tokens.patch
>
>
> We have a tier of Cassandra nodes running with join_ring=false flag, which we 
> call proxy nodes, and they will never join the ring.
> The problem is that sometimes we need to disable and enable the gossip on 
> those nodes, and `nodetool enablegossip` throws exceptions when we do that:
> {code}
> java.lang.AssertionError
> at 
> org.apache.cassandra.service.StorageService.getLocalTokens(StorageService.java:2213)
> at 
> org.apache.cassandra.service.StorageService.startGossiping(StorageService.java:371)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
> at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {code}



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

[jira] [Commented] (CASSANDRA-12253) Fix exceptions when enabling gossip on proxy nodes.

[Joel Knighton (JIRA)]

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

Joel Knighton commented on CASSANDRA-12253:
---

We should definitely fix the assertion error here - that said, I'd rather not 
change the {{startGossiping}} behavior for the case where a node has tokens and 
is started with join_ring False.

What about a patch similar to 
[this|https://github.com/jkni/cassandra/commit/8987f3506171c1fe7e2035a512be37f2e82e3906]?
 That would fix your case of not joining the ring with no tokens while 
maintaining the behavior when we have tokens.


> Fix exceptions when enabling gossip on proxy nodes.
> ---
>
> Key: CASSANDRA-12253
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12253
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Dikang Gu
>Assignee: Dikang Gu
>Priority: Minor
> Fix For: 2.2.x
>
> Attachments: 0001-for-proxy-node-not-set-gossip-tokens.patch
>
>
> We have a tier of Cassandra nodes running with join_ring=false flag, which we 
> call proxy nodes, and they will never join the ring.
> The problem is that sometimes we need to disable and enable the gossip on 
> those nodes, and `nodetool enablegossip` throws exceptions when we do that:
> {code}
> java.lang.AssertionError
> at 
> org.apache.cassandra.service.StorageService.getLocalTokens(StorageService.java:2213)
> at 
> org.apache.cassandra.service.StorageService.startGossiping(StorageService.java:371)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
> at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
> at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
> at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
> at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {code}



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

[jira] [Updated] (CASSANDRA-12328) Path Manipulation

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga updated CASSANDRA-12328:
-
Description: 
Overview:
In May through June of 2016 a static analysis was performed on version 3.0.5 of 
the Cassandra source code. The analysis included an automated analysis using HP 
Fortify v4.21 SCA and a manual analysis utilizing SciTools Understand v4. The 
results of that analysis includes the issue below.

Issue:
There are multiple places in the Cassandra source code where a string that 
determines the path of a file is not examined prior to use. Path traversal 
vulnerabilities are common software security problems and failure to validate 
the path prior to open/creating a file may result in operating in a directory 
that is outside the intended control sphere.

Path manipulation issues were found in the following locations:
CompactionManager.java Line 637
Descriptor.java Line 224
MetadataSerializer.java Line 83, 153
CommitLog.java Line 199
LogTransaction.java Line 311
WindowsFailedSnapshotTracker.java Line 51, 55, 60, 78, 84, 95
LegacyMetadataSerializer.java Line 84
FileUtils.java Line 116, 172, 354, 368, 386, 437
RewindableDataInputStreamPlus.java Line 226
CassandraDaemon.java Line 557
NodeTool.java Line 261
CustomClassLoader.java Line 77
CoalescingStrategies.java Line 54, 150
FBUtilities.java Line 309, 748

The following snippet is from CompactionManager.java where unvalidated input is 
parsed and used to create a new File object on line 637:
{code:java}
CompactionManager.java, lines 621-638:
621 public void forceUserDefinedCompaction(String dataFiles)
622 {
623 String[] filenames = dataFiles.split(",");
624 Multimap descriptors = 
ArrayListMultimap.create();
625 
626 for (String filename : filenames)
627 {
628 // extract keyspace and columnfamily name from filename
629 Descriptor desc = Descriptor.fromFilename(filename.trim());
630 if (Schema.instance.getCFMetaData(desc) == null)
631 {
632 logger.warn("Schema does not exist for file {}. Skipping.", 
filename);
633 continue;
634 }
635 // group by keyspace/columnfamily
636 ColumnFamilyStore cfs = 
Keyspace.open(desc.ksname).getColumnFamilyStore(desc.cfname);
637 descriptors.put(cfs, cfs.getDirectories().find(new 
File(filename.trim()).getName()));
638 }
{code}

  was:
Overview:
In May through June of 2016 a static analysis was performed on version 3.0.5 of 
the Cassandra source code. The analysis included an automated analysis using HP 
Fortify v4.21 SCA and a manual analysis utilizing SciTools Understand v4. The 
results of that analysis includes the issue below.

Issue:
There are several places in the Cassandra source code where a string that 
determines the path of a file is not examined prior to use. Path traversal 
vulnerabilities are common software security problems and failure to validate 
the path prior to open/creating a file may result in operating in a directory 
that is outside the intended control sphere.

Path manipulation issues were found in the following locations:
CompactionManager.java Line 637
Descriptor.java Line 224
MetadataSerializer.java Line 83

The following snippet is from CompactionManager.java where unvalidated input is 
parsed and used to create a new File object on line 637:
{code:java}
CompactionManager.java, lines 621-638:
621 public void forceUserDefinedCompaction(String dataFiles)
622 {
623 String[] filenames = dataFiles.split(",");
624 Multimap descriptors = 
ArrayListMultimap.create();
625 
626 for (String filename : filenames)
627 {
628 // extract keyspace and columnfamily name from filename
629 Descriptor desc = Descriptor.fromFilename(filename.trim());
630 if (Schema.instance.getCFMetaData(desc) == null)
631 {
632 logger.warn("Schema does not exist for file {}. Skipping.", 
filename);
633 continue;
634 }
635 // group by keyspace/columnfamily
636 ColumnFamilyStore cfs = 
Keyspace.open(desc.ksname).getColumnFamilyStore(desc.cfname);
637 descriptors.put(cfs, cfs.getDirectories().find(new 
File(filename.trim()).getName()));
638 }
{code}


> Path Manipulation
> -
>
> Key: CASSANDRA-12328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12328
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> There 

[jira] [Updated] (CASSANDRA-12301) Privacy Violation - Heap Inspection

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga updated CASSANDRA-12301:
-
Summary: Privacy Violation - Heap Inspection  (was: Privacy VIolation - 
Heap Inspection)

> Privacy Violation - Heap Inspection
> ---
>
> Key: CASSANDRA-12301
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12301
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> In the file SSLTransportFactory.java on lines 72 and 76 a string object is 
> used to store sensitive data. String objects are immutable and should not be 
> used to store sensitive data. Sensitive data should be stored in char or byte 
> arrays and the contents of those arrays should be cleared ASAP. Operations 
> performed on string objects will require that the original object be copied 
> and the operation be applied in the new copy of the string object. This 
> results in the likelihood that multiple copies of sensitive data will be 
> present in the heap until garbage collection takes place.
> The snippet below shows the issue on lines 72 and 76:
> SSLTransportFactory.java, lines 47-81:
> {code:java}
> 47 private String truststore;
> 48 private String truststorePassword;
> 49 private String keystore;
> 50 private String keystorePassword;
> 51 private String protocol;
> 52 private String[] cipherSuites;
> . . .
> 66 @Override
> 67 public void setOptions(Map options)
> 68 {
> 69 if (options.containsKey(TRUSTSTORE))
> 70 truststore = options.get(TRUSTSTORE);
> 71 if (options.containsKey(TRUSTSTORE_PASSWORD))
> 72 truststorePassword = options.get(TRUSTSTORE_PASSWORD);
> 73 if (options.containsKey(KEYSTORE))
> 74 keystore = options.get(KEYSTORE);
> 75 if (options.containsKey(KEYSTORE_PASSWORD))
> 76 keystorePassword = options.get(KEYSTORE_PASSWORD);
> 77 if (options.containsKey(PROTOCOL))
> 78 protocol = options.get(PROTOCOL);
> 79 if (options.containsKey(CIPHER_SUITES))
> 80 cipherSuites = options.get(CIPHER_SUITES).split(",");
> 81 }
> {code}



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

[jira] [Updated] (CASSANDRA-12299) Privacy Violation - Heap Inspection

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga updated CASSANDRA-12299:
-
Summary: Privacy Violation - Heap Inspection  (was: Privacy VIolation - 
Heap Inspection)

> Privacy Violation - Heap Inspection
> ---
>
> Key: CASSANDRA-12299
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12299
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> In the file CqlConfigHelper.java on lines 508, 533, 534 and 592 a string 
> object is used to store sensitive data. String objects are immutable and 
> should not be used to store sensitive data. Sensitive data should be stored 
> in char or byte arrays and the contents of those arrays should be cleared 
> ASAP. Operations performed on string objects will require that the original 
> object be copied and the operation be applied in the new copy of the string 
> object. This results in the likelihood that multiple copies of sensitive data 
> will be present in the heap until garbage collection takes place.
> The snippet below shows the issue on line 508:
> CqlConfigHelper.java, lines 505-518:
> {code:java}
> 505 private static Optional 
> getDefaultAuthProvider(Configuration conf)
> 506 {
> 507 Optional username = getStringSetting(USERNAME, conf);
> 508 Optional password = getStringSetting(PASSWORD, conf);
> 509 
> 510 if (username.isPresent() && password.isPresent())
> 511 {
> 512 return Optional.of(new PlainTextAuthProvider(username.get(), 
> password.get()));
> 513 }
> 514 else
> 515 {
> 516 return Optional.absent();
> 517 }
> 518 }
> {code}



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

[jira] [Updated] (CASSANDRA-12303) Privacy Violation - Heap Inspection

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga updated CASSANDRA-12303:
-
Summary: Privacy Violation - Heap Inspection  (was: Privacy VIolation - 
Heap Inspection)

> Privacy Violation - Heap Inspection
> ---
>
> Key: CASSANDRA-12303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12303
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> In the file AbstractJmxClient.java on lines 69 and 147 a string object is 
> used to store sensitive data. String objects are immutable and should not be 
> used to store sensitive data. Sensitive data should be stored in char or byte 
> arrays and the contents of those arrays should be cleared ASAP. Operations 
> performed on string objects will require that the original object be copied 
> and the operation be applied in the new copy of the string object. This 
> results in the likelihood that multiple copies of sensitive data will be 
> present in the heap until garbage collection takes place.
> The snippet below shows the issue on line 69:
> AbstractJmxClient.java, lines 51-71:
> {code:java}
> 51 protected final String password;
> 52 protected JMXConnection jmxConn;
> 53 protected PrintStream out = System.out;
> . . .
> 64 public AbstractJmxClient(String host, Integer port, String username, 
> String password) throws IOException
> 65 {
> 66 this.host = (host != null) ? host : DEFAULT_HOST;
> 67 this.port = (port != null) ? port : DEFAULT_JMX_PORT;
> 68 this.username = username;
> 69 this.password = password;
> 70 jmxConn = new JMXConnection(this.host, this.port, username, password);
> 71 }
> {code}



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

[jira] [Updated] (CASSANDRA-12298) Privacy Violation - Heap Inspection

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga updated CASSANDRA-12298:
-
Reproduced In: 3.0.5
  Summary: Privacy Violation - Heap Inspection  (was: Privacy VIolation 
- Heap Inspection)

> Privacy Violation - Heap Inspection
> ---
>
> Key: CASSANDRA-12298
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12298
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>Assignee: Jason Brown
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included 
> an automated analysis using HP Fortify v4.21 SCA and a manual analysis 
> utilizing SciTools Understand v4. The results of that 
> analysis includes the issue below.
> Issue:
> In the file RoleOptions.java on line 89 a string object is used to store 
> sensitive data. String objects are immutable and should not be used to store 
> sensitive data. Sensitive data should be stored in char or byte arrays and 
> the contents of those arrays should be cleared ASAP. Operations performed on 
> string objects will require that the original object be copied and the 
> operation be applied in the new copy of the string object. This results in 
> the likelihood that multiple copies of sensitive data will be present in the 
> heap until garbage collection takes place.
> The snippet below shows the issue on line 89:
> RoleOptions.java, lines 87-90:
> {code:java}
> 87 public Optional getPassword()
> 88 {
> 89 return 
> Optional.fromNullable((String)options.get(IRoleManager.Option.PASSWORD));
> 90 }
> {code}



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

[jira] [Updated] (CASSANDRA-12325) Access Specifier Manipulation

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga updated CASSANDRA-12325:
-
Reproduced In: 3.0.5
Fix Version/s: (was: 3.0.5)

> Access Specifier Manipulation
> -
>
> Key: CASSANDRA-12325
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12325
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> There are 18 instances in the Cassandra source code where setAccessible() is 
> used to suppress Java language access checking. Static analysis automation 
> tools, like Fortify, will log every instance of the use of setAccessible() 
> and its use represents a possible security issue.
> The use of setAccessble() can cause security problems if the Java access 
> checking is suppressed longer than required or another approach could be 
> taken other than suppressing access checking. This issue will list all 18 
> instances where setAccessible() is used and the usage of this method should 
> be reviewed and checked to make sure it is not used inappropriately.
> setAccessible() is used in the following places:
> UDHelper.java Line 49
> HadoopCompat.java Line 109, 113, 118, 150, 152, 154
> Memory.java Line 42
> GCInspector.java Line 68
> Locks.java Line 33
> Ref.java Line 626
> FastByteOperations.java Line 150
> FBUtilities.java Line 539
> Hex.java Line 128
> MemoryUtil.java Line 61
> SyncUtil.java Line 33, 45, 57
> UDHelper.java, lines 45-56:
> {code:java}
> 45 try
> 46 {
> 47 Class cls = 
> Class.forName("com.datastax.driver.core.DataTypeClassNameParser");
> 48 Method m = cls.getDeclaredMethod("parseOne", String.class, 
> ProtocolVersion.class, CodecRegistry.class);
> 49 m.setAccessible(true);
> 50 methodParseOne = MethodHandles.lookup().unreflect(m);
> 51 codecRegistry = new CodecRegistry();
> 52 }
> 53 catch (Exception e)
> 54 {
> 55 throw new RuntimeException(e);
> 56 }
> {code}



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

[jira] [Commented] (CASSANDRA-12324) Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select Classes or Code

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga commented on CASSANDRA-12324:
--

Thank you...updating all me entries.

 

  


> Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select 
> Classes or Code
> --
>
> Key: CASSANDRA-12324
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12324
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Dynamically loaded code has the potential to be malicious. The application 
> uses external input to select which classes or code to use, but it does not 
> sufficiently prevent the input from selecting improper classes or code.
> The snippet below shows the issue which ends on line 436 by returning an 
> object associated with a class by name.
> {code:java}
> FBUtilities.java, lines 432-442:
> 432 public static  Class classForName(String classname, String 
> readable) throws ConfigurationException
> 433 {
> 434 try
> 435 {
> 436 return (Class)Class.forName(classname);
> 437 }
> 438 catch (ClassNotFoundException | NoClassDefFoundError e)
> 439 {
> 440 throw new ConfigurationException(String.format("Unable to find %s 
> class '%s'", readable, classname), e);
> 441 }
> 442 }
> {code}



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

[jira] [Updated] (CASSANDRA-12326) Use of getByAddress() to retrieve InetAddress object

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga updated CASSANDRA-12326:
-
Reproduced In: 3.0.5
Fix Version/s: (was: 3.0.5)

> Use of getByAddress() to retrieve InetAddress object
> 
>
> Key: CASSANDRA-12326
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12326
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> There are four places in the Cassandra source code that rely upon a call to 
> getByAddress() to retrieve an InetAddress object. The information returned by 
> getByAddress() is not trustworthy. Attackers can spoof DNS entries and 
> depending on getByAddress alone invites DNS spoofing attacks.
> The four places in the Cassandra source code where getByAddress() is used:
> MutationVerbHandler.java Line 58
> CompactEndpointSerializationHelper.java Line 38
> InetAddressSerializer.java Line 38, 58
> MutationVerbHandler.java, lines 49-59:
> {code:java}
> 49 if (from == null)
> 50 {
> 51 replyTo = message.from;
> 52 byte[] forwardBytes = message.parameters.get(Mutation.FORWARD_TO);
> 53 if (forwardBytes != null)
> 54 forwardToLocalNodes(message.payload, message.verb, forwardBytes, 
> message.from);
> 55 }
> 56 else
> 57 {
> 58 replyTo = InetAddress.getByAddress(from);
> 59 }
> {code}



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

[jira] [Updated] (CASSANDRA-12327) Use of getAllByName() to retrieve IP addresses

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga updated CASSANDRA-12327:
-
Reproduced In: 3.0.5
Fix Version/s: (was: 3.0.5)

> Use of getAllByName() to retrieve IP addresses
> --
>
> Key: CASSANDRA-12327
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12327
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Use of getAllByName() to retrieve an IP addresses is not trustworthy. 
> Attackers can spoof DNS entries.
> The file LimitedLocalNodeFirstLocalBalancingPolicy.java calls getAllByName() 
> on line 66.
> LimitedLocalNodeFirstLocalBalancingPolicy.java, lines 64-72:
> {code:java}
> 64 try
> 65 {
> 66 InetAddress[] addresses = InetAddress.getAllByName(replica);
> 67 Collections.addAll(replicaAddresses, addresses);
> 68 }
> 69 catch (UnknownHostException e)
> 70 {
> 71 logger.warn("Invalid replica host name: {}, skipping it", replica);
> 72 }
> {code}



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

[jira] [Updated] (CASSANDRA-12329) Unreleased Resource: Sockets

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga updated CASSANDRA-12329:
-
Reproduced In: 3.0.5
Fix Version/s: (was: 3.0.5)

> Unreleased Resource: Sockets
> 
>
> Key: CASSANDRA-12329
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12329
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Sockets are low level resources that must be explicitly released so 
> subsequent callers will have access to previously used sockets. In the file 
> SSLFactory.java on line 62 a SSL server socket is acquired and eventually 
> returned to the caller on line 69.
> If an exception is thrown by any of the code between lines 62 and 69 the 
> socket acquired on line 62 will not be released for subsequent reuse..
> {code:java}
> SSLFactory.java, lines 59-70:
> 59 public static SSLServerSocket getServerSocket(EncryptionOptions options, 
> InetAddress address, int port) throws IOException
> 60 {
> 61 SSLContext ctx = createSSLContext(options, true);
> 62 SSLServerSocket serverSocket = 
> (SSLServerSocket)ctx.getServerSocketFactory().createServerSocket();
> 63 serverSocket.setReuseAddress(true);
> 64 String[] suites = 
> filterCipherSuites(serverSocket.getSupportedCipherSuites(), 
> options.cipher_suites);
> 65 serverSocket.setEnabledCipherSuites(suites);
> 66 serverSocket.setNeedClientAuth(options.require_client_auth);
> 67 serverSocket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
> 68 serverSocket.bind(new InetSocketAddress(address, port), 500);
> 69 return serverSocket;
> 70 }
> {code}



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

[jira] [Updated] (CASSANDRA-12328) Path Manipulation

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga updated CASSANDRA-12328:
-
Reproduced In: 3.0.5
Fix Version/s: (was: 3.0.5)

> Path Manipulation
> -
>
> Key: CASSANDRA-12328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12328
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> There are several places in the Cassandra source code where a string that 
> determines the path of a file is not examined prior to use. Path traversal 
> vulnerabilities are common software security problems and failure to validate 
> the path prior to open/creating a file may result in operating in a directory 
> that is outside the intended control sphere.
> Path manipulation issues were found in the following locations:
> CompactionManager.java Line 637
> Descriptor.java Line 224
> MetadataSerializer.java Line 83
> The following snippet is from CompactionManager.java where unvalidated input 
> is parsed and used to create a new File object on line 637:
> {code:java}
> CompactionManager.java, lines 621-638:
> 621 public void forceUserDefinedCompaction(String dataFiles)
> 622 {
> 623 String[] filenames = dataFiles.split(",");
> 624 Multimap descriptors = 
> ArrayListMultimap.create();
> 625 
> 626 for (String filename : filenames)
> 627 {
> 628 // extract keyspace and columnfamily name from filename
> 629 Descriptor desc = Descriptor.fromFilename(filename.trim());
> 630 if (Schema.instance.getCFMetaData(desc) == null)
> 631 {
> 632 logger.warn("Schema does not exist for file {}. Skipping.", 
> filename);
> 633 continue;
> 634 }
> 635 // group by keyspace/columnfamily
> 636 ColumnFamilyStore cfs = 
> Keyspace.open(desc.ksname).getColumnFamilyStore(desc.cfname);
> 637 descriptors.put(cfs, cfs.getDirectories().find(new 
> File(filename.trim()).getName()));
> 638 }
> {code}



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

[jira] [Updated] (CASSANDRA-12330) Unreleased Resource: Sockets

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga updated CASSANDRA-12330:
-
Reproduced In: 3.0.5
Fix Version/s: (was: 3.0.5)

> Unreleased Resource: Sockets
> 
>
> Key: CASSANDRA-12330
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12330
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Sockets are low level resources that must be explicitly released so 
> subsequent callers will have access to previously used sockets. In the file 
> DefaultConnectionFactory.java on line 52 a socket is acquired and eventually 
> returned to the caller on line 55.
> If an exception is thrown by any of the code between lines 52 and 55 the 
> socket acquired on line 52 will not be released for subsequent reuse.
> DefaultConnectionFactory.java, lines 50-73:
> {code:java}
> 50 try
> 51 {
> 52 Socket socket = OutboundTcpConnectionPool.newSocket(peer);
> 53 
> socket.setSoTimeout(DatabaseDescriptor.getStreamingSocketTimeout());
> 54 socket.setKeepAlive(true);
> 55 return socket;
> 56 }
> 57 catch (IOException e)
> 58 {
> 59 if (++attempts >= MAX_CONNECT_ATTEMPTS)
> 60 throw e;
> 61 
> 62 long waitms = DatabaseDescriptor.getRpcTimeout() * 
> (long)Math.pow(2, attempts);
> 63 logger.warn("Failed attempt {} to connect to {}. Retrying in {} 
> ms. ({})", attempts, peer, waitms, e);
> 64 try
> 65 {
> 66 Thread.sleep(waitms);
> 67 }
> 68 catch (InterruptedException wtf)
> 69 {
> 70 throw new IOException("interrupted", wtf);
> 71 }
> 72 }
> 73 }
> {code}



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

[jira] [Updated] (CASSANDRA-12332) Weak SecurityManager Check: Overridable Method

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga updated CASSANDRA-12332:
-
Reproduced In: 3.0.5
Fix Version/s: (was: 3.0.5)

> Weak SecurityManager Check: Overridable Method
> --
>
> Key: CASSANDRA-12332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12332
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Non-final methods that perform security checks may be overridden in ways that 
> bypass security checks.
> {code:java}
> CassandraDaemon.java, lines 155-165:
> 155 protected void setup()
> 156 {
> 157 // Delete any failed snapshot deletions on Windows - see 
> CASSANDRA-9658
> 158 if (FBUtilities.isWindows())
> 159 WindowsFailedSnapshotTracker.deleteOldSnapshots();
> 160 
> 161 ThreadAwareSecurityManager.install();
> 162 
> 163 logSystemInfo();
> 164 
> 165 CLibrary.tryMlockall();
> {code}



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

[jira] [Updated] (CASSANDRA-12331) Unreleased Resource: Sockets

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga updated CASSANDRA-12331:
-
Reproduced In: 3.0.5
Fix Version/s: (was: 3.0.5)

> Unreleased Resource: Sockets
> 
>
> Key: CASSANDRA-12331
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12331
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Sockets are low level resources that must be explicitly released so 
> subsequent callers will have access to previously used sockets. In the file 
> RMIServerSocketFactoryImpl.java on lines 15-16 a socket is acquired and 
> eventually returned to the caller on line 18.
> If an exception is thrown by the code on line 17 the socket acquired on lines 
> 15-16 will not be released for subsequent reuse.
> RMIServerSocketFactoryImpl.java, lines 13-19:
> {code:java}
> 13 public ServerSocket createServerSocket(final int pPort) throws IOException
> 14 {
> 15 ServerSocket socket = ServerSocketFactory.getDefault()
> 16  .createServerSocket(pPort, 0, 
> InetAddress.getLoopbackAddress());
> 17 socket.setReuseAddress(true);
> 18 return socket;
> 19 }
> {code}



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

[jira] [Updated] (CASSANDRA-12333) Password Management: Hardcoded Password

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga updated CASSANDRA-12333:
-
Reproduced In: 3.0.5
Fix Version/s: (was: 3.0.5)

> Password Management: Hardcoded Password
> ---
>
> Key: CASSANDRA-12333
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12333
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> Hardcoded passwords may compromise system security in a way that cannot be 
> easily remedied. In CassandraRoleManager.java on line 77 the default 
> superuser password is set to "cassandra".
> CassandraRoleManager.java, lines 72-77:
> {code:java}
> 72 public class CassandraRoleManager implements IRoleManager
> 73 {
> 74 private static final Logger logger = 
> LoggerFactory.getLogger(CassandraRoleManager.class);
> 75 
> 76 static final String DEFAULT_SUPERUSER_NAME = "cassandra";
> 77 static final String DEFAULT_SUPERUSER_PASSWORD = "cassandra";
> CassandraRoleManager.java, lines 326-338:
> 326 private static void setupDefaultRole()
> 327 {
> 328 try
> 329 {
> 330 if (!hasExistingRoles())
> 331 {
> 332 QueryProcessor.process(String.format("INSERT INTO %s.%s 
> (role, is_superuser, can_login, salted_hash) " +
> 333  "VALUES ('%s', true, 
> true, '%s')",
> 334  AuthKeyspace.NAME,
> 335  AuthKeyspace.ROLES,
> 336  DEFAULT_SUPERUSER_NAME,
> 337  
> escape(hashpw(DEFAULT_SUPERUSER_PASSWORD))),
> 338
> consistencyForRole(DEFAULT_SUPERUSER_NAME));
> {code}



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

[jira] [Created] (CASSANDRA-12333) Password Management: Hardcoded Password

[Eduardo Aguinaga (JIRA)]

Eduardo Aguinaga created CASSANDRA-12333:


 Summary: Password Management: Hardcoded Password
 Key: CASSANDRA-12333
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12333
 Project: Cassandra
  Issue Type: Bug
Reporter: Eduardo Aguinaga
 Fix For: 3.0.5


Overview:
In May through June of 2016 a static analysis was performed on version 3.0.5 of 
the Cassandra source code. The analysis included an automated analysis using HP 
Fortify v4.21 SCA and a manual analysis utilizing SciTools Understand v4. The 
results of that analysis includes the issue below.

Issue:
Hardcoded passwords may compromise system security in a way that cannot be 
easily remedied. In CassandraRoleManager.java on line 77 the default superuser 
password is set to "cassandra".

CassandraRoleManager.java, lines 72-77:
{code:java}
72 public class CassandraRoleManager implements IRoleManager
73 {
74 private static final Logger logger = 
LoggerFactory.getLogger(CassandraRoleManager.class);
75 
76 static final String DEFAULT_SUPERUSER_NAME = "cassandra";
77 static final String DEFAULT_SUPERUSER_PASSWORD = "cassandra";

CassandraRoleManager.java, lines 326-338:
326 private static void setupDefaultRole()
327 {
328 try
329 {
330 if (!hasExistingRoles())
331 {
332 QueryProcessor.process(String.format("INSERT INTO %s.%s (role, 
is_superuser, can_login, salted_hash) " +
333  "VALUES ('%s', true, true, 
'%s')",
334  AuthKeyspace.NAME,
335  AuthKeyspace.ROLES,
336  DEFAULT_SUPERUSER_NAME,
337  
escape(hashpw(DEFAULT_SUPERUSER_PASSWORD))),
338
consistencyForRole(DEFAULT_SUPERUSER_NAME));
{code}



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

[jira] [Created] (CASSANDRA-12331) Unreleased Resource: Sockets

[Eduardo Aguinaga (JIRA)]

Eduardo Aguinaga created CASSANDRA-12331:


 Summary: Unreleased Resource: Sockets
 Key: CASSANDRA-12331
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12331
 Project: Cassandra
  Issue Type: Bug
Reporter: Eduardo Aguinaga
 Fix For: 3.0.5


Overview:
In May through June of 2016 a static analysis was performed on version 3.0.5 of 
the Cassandra source code. The analysis included an automated analysis using HP 
Fortify v4.21 SCA and a manual analysis utilizing SciTools Understand v4. The 
results of that analysis includes the issue below.

Issue:
Sockets are low level resources that must be explicitly released so subsequent 
callers will have access to previously used sockets. In the file 
RMIServerSocketFactoryImpl.java on lines 15-16 a socket is acquired and 
eventually returned to the caller on line 18.

If an exception is thrown by the code on line 17 the socket acquired on lines 
15-16 will not be released for subsequent reuse.

RMIServerSocketFactoryImpl.java, lines 13-19:
{code:java}
13 public ServerSocket createServerSocket(final int pPort) throws IOException
14 {
15 ServerSocket socket = ServerSocketFactory.getDefault()
16  .createServerSocket(pPort, 0, 
InetAddress.getLoopbackAddress());
17 socket.setReuseAddress(true);
18 return socket;
19 }
{code}



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

[jira] [Created] (CASSANDRA-12332) Weak SecurityManager Check: Overridable Method

[Eduardo Aguinaga (JIRA)]

Eduardo Aguinaga created CASSANDRA-12332:


 Summary: Weak SecurityManager Check: Overridable Method
 Key: CASSANDRA-12332
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12332
 Project: Cassandra
  Issue Type: Bug
Reporter: Eduardo Aguinaga
 Fix For: 3.0.5


Overview:
In May through June of 2016 a static analysis was performed on version 3.0.5 of 
the Cassandra source code. The analysis included an automated analysis using HP 
Fortify v4.21 SCA and a manual analysis utilizing SciTools Understand v4. The 
results of that analysis includes the issue below.

Issue:
Non-final methods that perform security checks may be overridden in ways that 
bypass security checks.

{code:java}
CassandraDaemon.java, lines 155-165:
155 protected void setup()
156 {
157 // Delete any failed snapshot deletions on Windows - see CASSANDRA-9658
158 if (FBUtilities.isWindows())
159 WindowsFailedSnapshotTracker.deleteOldSnapshots();
160 
161 ThreadAwareSecurityManager.install();
162 
163 logSystemInfo();
164 
165 CLibrary.tryMlockall();
{code}



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

[jira] [Commented] (CASSANDRA-12294) LDAP Authentication

[Daniel Kleviansky (JIRA)]

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

Daniel Kleviansky commented on CASSANDRA-12294:
---

I absolutely understand those concerns, especially those around sharing 
specifics in a public forum, however, if you consider other large scale 
database systems in enterprise, I believe many in production rely on 
third-party authentication. Introducing this feature into vanilla C* may open 
up more possibilities for the future of the project.

Also, bear in mind that one need not necessarily need to share protected 
information to diagnose particular issues, and it is in fact at the companies 
discretion as to whether or not they choose to, based on their policies. It is 
also very common to have only specific LDAP systems supported (AD for example), 
thereby limiting the overhead of support required.

In addition, these said enterprises may not feel comfortable relying on a 
third-party plugin which is not part of the main C* project, and may turn them 
off integrating applications which rely on a C* database. One may argue that 
they should implement DSE, but if they have not developed the software 
themselves, they may not have any other choice, or may not be able to for any 
number of reasons.

Having said all this, I'd be happy to spin this off into a plugin if that's 
what's decided, and I feel we both genuinely appreciate just how useful it 
would be, but just wanted to address these points, and felt they should be at 
least brought to light.

> LDAP Authentication
> ---
>
> Key: CASSANDRA-12294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12294
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Distributed Metadata
>Reporter: Daniel Kleviansky
>Assignee: Daniel Kleviansky
>Priority: Minor
>  Labels: security
> Fix For: 2.2.x, 3.x
>
>
> Addition of an LDAP authentication plugin, in tree, along side the default 
> authenticator, so that Cassandra can leverage existing LDAP-speaking servers 
> to manage user logins.
> DSE offers this: [Enabling LDAP authentication | 
> https://docs.datastax.com/en/datastax_enterprise/4.6/datastax_enterprise/sec/secLdapEnabling.html],
>  but does not exist in vanilla C* as far as I can tell.
> Ideally would like to introduce this as part of the 2.2.x branch, as this is 
> what is currently running in client production environment, and where it is 
> needed at the moment.
> Would aim for support of at least Microsoft Active Directory running on 
> Windows Server 2012.
> Work in progress: https://github.com/lqid/cassandra — Branch 12294-22



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

[jira] [Created] (CASSANDRA-12330) Unreleased Resource: Sockets

[Eduardo Aguinaga (JIRA)]

Eduardo Aguinaga created CASSANDRA-12330:


 Summary: Unreleased Resource: Sockets
 Key: CASSANDRA-12330
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12330
 Project: Cassandra
  Issue Type: Bug
Reporter: Eduardo Aguinaga
 Fix For: 3.0.5


Overview:
In May through June of 2016 a static analysis was performed on version 3.0.5 of 
the Cassandra source code. The analysis included an automated analysis using HP 
Fortify v4.21 SCA and a manual analysis utilizing SciTools Understand v4. The 
results of that analysis includes the issue below.

Issue:
Sockets are low level resources that must be explicitly released so subsequent 
callers will have access to previously used sockets. In the file 
DefaultConnectionFactory.java on line 52 a socket is acquired and eventually 
returned to the caller on line 55.

If an exception is thrown by any of the code between lines 52 and 55 the socket 
acquired on line 52 will not be released for subsequent reuse.

DefaultConnectionFactory.java, lines 50-73:
{code:java}
50 try
51 {
52 Socket socket = OutboundTcpConnectionPool.newSocket(peer);
53 socket.setSoTimeout(DatabaseDescriptor.getStreamingSocketTimeout());
54 socket.setKeepAlive(true);
55 return socket;
56 }
57 catch (IOException e)
58 {
59 if (++attempts >= MAX_CONNECT_ATTEMPTS)
60 throw e;
61 
62 long waitms = DatabaseDescriptor.getRpcTimeout() * (long)Math.pow(2, 
attempts);
63 logger.warn("Failed attempt {} to connect to {}. Retrying in {} ms. 
({})", attempts, peer, waitms, e);
64 try
65 {
66 Thread.sleep(waitms);
67 }
68 catch (InterruptedException wtf)
69 {
70 throw new IOException("interrupted", wtf);
71 }
72 }
73 }
{code}




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

[jira] [Created] (CASSANDRA-12329) Unreleased Resource: Sockets

[Eduardo Aguinaga (JIRA)]

Eduardo Aguinaga created CASSANDRA-12329:


 Summary: Unreleased Resource: Sockets
 Key: CASSANDRA-12329
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12329
 Project: Cassandra
  Issue Type: Bug
Reporter: Eduardo Aguinaga
 Fix For: 3.0.5


Overview:
In May through June of 2016 a static analysis was performed on version 3.0.5 of 
the Cassandra source code. The analysis included an automated analysis using HP 
Fortify v4.21 SCA and a manual analysis utilizing SciTools Understand v4. The 
results of that analysis includes the issue below.

Issue:
Sockets are low level resources that must be explicitly released so subsequent 
callers will have access to previously used sockets. In the file 
SSLFactory.java on line 62 a SSL server socket is acquired and eventually 
returned to the caller on line 69.

If an exception is thrown by any of the code between lines 62 and 69 the socket 
acquired on line 62 will not be released for subsequent reuse..

{code:java}
SSLFactory.java, lines 59-70:
59 public static SSLServerSocket getServerSocket(EncryptionOptions options, 
InetAddress address, int port) throws IOException
60 {
61 SSLContext ctx = createSSLContext(options, true);
62 SSLServerSocket serverSocket = 
(SSLServerSocket)ctx.getServerSocketFactory().createServerSocket();
63 serverSocket.setReuseAddress(true);
64 String[] suites = 
filterCipherSuites(serverSocket.getSupportedCipherSuites(), 
options.cipher_suites);
65 serverSocket.setEnabledCipherSuites(suites);
66 serverSocket.setNeedClientAuth(options.require_client_auth);
67 serverSocket.setEnabledProtocols(ACCEPTED_PROTOCOLS);
68 serverSocket.bind(new InetSocketAddress(address, port), 500);
69 return serverSocket;
70 }
{code}



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

[jira] [Created] (CASSANDRA-12328) Path Manipulation

[Eduardo Aguinaga (JIRA)]

Eduardo Aguinaga created CASSANDRA-12328:


 Summary: Path Manipulation
 Key: CASSANDRA-12328
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12328
 Project: Cassandra
  Issue Type: Bug
Reporter: Eduardo Aguinaga
 Fix For: 3.0.5


Overview:
In May through June of 2016 a static analysis was performed on version 3.0.5 of 
the Cassandra source code. The analysis included an automated analysis using HP 
Fortify v4.21 SCA and a manual analysis utilizing SciTools Understand v4. The 
results of that analysis includes the issue below.

Issue:
There are several places in the Cassandra source code where a string that 
determines the path of a file is not examined prior to use. Path traversal 
vulnerabilities are common software security problems and failure to validate 
the path prior to open/creating a file may result in operating in a directory 
that is outside the intended control sphere.

Path manipulation issues were found in the following locations:
CompactionManager.java Line 637
Descriptor.java Line 224
MetadataSerializer.java Line 83

The following snippet is from CompactionManager.java where unvalidated input is 
parsed and used to create a new File object on line 637:
{code:java}
CompactionManager.java, lines 621-638:
621 public void forceUserDefinedCompaction(String dataFiles)
622 {
623 String[] filenames = dataFiles.split(",");
624 Multimap descriptors = 
ArrayListMultimap.create();
625 
626 for (String filename : filenames)
627 {
628 // extract keyspace and columnfamily name from filename
629 Descriptor desc = Descriptor.fromFilename(filename.trim());
630 if (Schema.instance.getCFMetaData(desc) == null)
631 {
632 logger.warn("Schema does not exist for file {}. Skipping.", 
filename);
633 continue;
634 }
635 // group by keyspace/columnfamily
636 ColumnFamilyStore cfs = 
Keyspace.open(desc.ksname).getColumnFamilyStore(desc.cfname);
637 descriptors.put(cfs, cfs.getDirectories().find(new 
File(filename.trim()).getName()));
638 }
{code}



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

[jira] [Updated] (CASSANDRA-12315) dtest failure in cqlsh_tests.cqlsh_tests.TestCqlsh.test_client_warnings

[Philip Thompson (JIRA)]

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

Philip Thompson updated CASSANDRA-12315:

Labels: cqlsh dtest  (was: dtest)

> dtest failure in cqlsh_tests.cqlsh_tests.TestCqlsh.test_client_warnings
> ---
>
> Key: CASSANDRA-12315
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12315
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: DS Test Eng
>  Labels: cqlsh, dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1317/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_client_warnings
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools.py", line 290, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_tests.py", line 
> 1424, in test_client_warnings
> self.assertEqual(len(stderr), 0, "Failed to execute cqlsh: 
> {}".format(stderr))
>   File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
> assertion_func(first, second, msg=msg)
>   File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual
> raise self.failureException(msg)
> 'Failed to execute cqlsh: :3:OperationTimedOut: errors={\'127.0.0.1\': 
> \'Client request timeout. See Session.execute[_async](timeout)\'}, 
> last_host=127.0.0.1\n:5:InvalidRequest: Error from server: code=2200 
> [Invalid query] message="Keyspace \'client_warnings\' does not 
> exist"\n:7:InvalidRequest: Error from server: code=2200 [Invalid 
> query] message="No keyspace has been specified. USE a keyspace, or explicitly 
> specify keyspace.tablename"
> {code}



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

[jira] [Updated] (CASSANDRA-12315) dtest failure in cqlsh_tests.cqlsh_tests.TestCqlsh.test_client_warnings

[Philip Thompson (JIRA)]

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

Philip Thompson updated CASSANDRA-12315:

Assignee: (was: DS Test Eng)

> dtest failure in cqlsh_tests.cqlsh_tests.TestCqlsh.test_client_warnings
> ---
>
> Key: CASSANDRA-12315
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12315
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>  Labels: cqlsh, dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1317/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_client_warnings
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools.py", line 290, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_tests.py", line 
> 1424, in test_client_warnings
> self.assertEqual(len(stderr), 0, "Failed to execute cqlsh: 
> {}".format(stderr))
>   File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
> assertion_func(first, second, msg=msg)
>   File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual
> raise self.failureException(msg)
> 'Failed to execute cqlsh: :3:OperationTimedOut: errors={\'127.0.0.1\': 
> \'Client request timeout. See Session.execute[_async](timeout)\'}, 
> last_host=127.0.0.1\n:5:InvalidRequest: Error from server: code=2200 
> [Invalid query] message="Keyspace \'client_warnings\' does not 
> exist"\n:7:InvalidRequest: Error from server: code=2200 [Invalid 
> query] message="No keyspace has been specified. USE a keyspace, or explicitly 
> specify keyspace.tablename"
> {code}



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

[jira] [Updated] (CASSANDRA-10848) Upgrade paging dtests involving deletion flap on CassCI

[Russ Hatch (JIRA)]

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

Russ Hatch updated CASSANDRA-10848:
---
Assignee: DS Test Eng  (was: Sylvain Lebresne)

> Upgrade paging dtests involving deletion flap on CassCI
> ---
>
> Key: CASSANDRA-10848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10848
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Jim Witschey
>Assignee: DS Test Eng
>  Labels: dtest
> Fix For: 3.0.x, 3.x
>
>
> A number of dtests in the {{upgrade_tests.paging_tests}} that involve 
> deletion flap with the following error:
> {code}
> Requested pages were not delivered before timeout.
> {code}
> This may just be an effect of CASSANDRA-10730, but it's worth having a look 
> at separately. Here are some examples of tests flapping in this way:



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

[jira] [Commented] (CASSANDRA-12315) dtest failure in cqlsh_tests.cqlsh_tests.TestCqlsh.test_client_warnings

[Philip Thompson (JIRA)]

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

Philip Thompson commented on CASSANDRA-12315:
-

{code}
CREATE KEYSPACE client_warnings WITH replication = {'class': 'SimpleStrategy', 
'replication_factor': 1};
USE client_warnings;
{code}

is what is failing on cqlsh, on a three node cluster, with the above error. Is 
this something we want to consider fixing in cqlsh?

> dtest failure in cqlsh_tests.cqlsh_tests.TestCqlsh.test_client_warnings
> ---
>
> Key: CASSANDRA-12315
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12315
> Project: Cassandra
>  Issue Type: Test
>Reporter: Sean McCarthy
>Assignee: DS Test Eng
>  Labels: cqlsh, dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1317/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_client_warnings
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools.py", line 290, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_tests.py", line 
> 1424, in test_client_warnings
> self.assertEqual(len(stderr), 0, "Failed to execute cqlsh: 
> {}".format(stderr))
>   File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
> assertion_func(first, second, msg=msg)
>   File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual
> raise self.failureException(msg)
> 'Failed to execute cqlsh: :3:OperationTimedOut: errors={\'127.0.0.1\': 
> \'Client request timeout. See Session.execute[_async](timeout)\'}, 
> last_host=127.0.0.1\n:5:InvalidRequest: Error from server: code=2200 
> [Invalid query] message="Keyspace \'client_warnings\' does not 
> exist"\n:7:InvalidRequest: Error from server: code=2200 [Invalid 
> query] message="No keyspace has been specified. USE a keyspace, or explicitly 
> specify keyspace.tablename"
> {code}



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

[jira] [Created] (CASSANDRA-12327) Use of getAllByName() to retrieve IP addresses

[Eduardo Aguinaga (JIRA)]

Eduardo Aguinaga created CASSANDRA-12327:


 Summary: Use of getAllByName() to retrieve IP addresses
 Key: CASSANDRA-12327
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12327
 Project: Cassandra
  Issue Type: Bug
Reporter: Eduardo Aguinaga
 Fix For: 3.0.5


Overview:
In May through June of 2016 a static analysis was performed on version 3.0.5 of 
the Cassandra source code. The analysis included an automated analysis using HP 
Fortify v4.21 SCA and a manual analysis utilizing SciTools Understand v4. The 
results of that analysis includes the issue below.

Issue:
Use of getAllByName() to retrieve an IP addresses is not trustworthy. Attackers 
can spoof DNS entries.

The file LimitedLocalNodeFirstLocalBalancingPolicy.java calls getAllByName() on 
line 66.

LimitedLocalNodeFirstLocalBalancingPolicy.java, lines 64-72:
{code:java}
64 try
65 {
66 InetAddress[] addresses = InetAddress.getAllByName(replica);
67 Collections.addAll(replicaAddresses, addresses);
68 }
69 catch (UnknownHostException e)
70 {
71 logger.warn("Invalid replica host name: {}, skipping it", replica);
72 }
{code}



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

[jira] [Updated] (CASSANDRA-12315) dtest failure in cqlsh_tests.cqlsh_tests.TestCqlsh.test_client_warnings

[Philip Thompson (JIRA)]

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

Philip Thompson updated CASSANDRA-12315:

Issue Type: Bug  (was: Test)

> dtest failure in cqlsh_tests.cqlsh_tests.TestCqlsh.test_client_warnings
> ---
>
> Key: CASSANDRA-12315
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12315
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Sean McCarthy
>Assignee: DS Test Eng
>  Labels: cqlsh, dtest
> Attachments: node1.log, node1_debug.log, node1_gc.log, node2.log, 
> node2_debug.log, node2_gc.log, node3.log, node3_debug.log, node3_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_dtest/1317/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_client_warnings
> {code}
> Stacktrace
>   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
>   File "/home/automaton/cassandra-dtest/tools.py", line 290, in wrapped
> f(obj)
>   File "/home/automaton/cassandra-dtest/cqlsh_tests/cqlsh_tests.py", line 
> 1424, in test_client_warnings
> self.assertEqual(len(stderr), 0, "Failed to execute cqlsh: 
> {}".format(stderr))
>   File "/usr/lib/python2.7/unittest/case.py", line 513, in assertEqual
> assertion_func(first, second, msg=msg)
>   File "/usr/lib/python2.7/unittest/case.py", line 506, in _baseAssertEqual
> raise self.failureException(msg)
> 'Failed to execute cqlsh: :3:OperationTimedOut: errors={\'127.0.0.1\': 
> \'Client request timeout. See Session.execute[_async](timeout)\'}, 
> last_host=127.0.0.1\n:5:InvalidRequest: Error from server: code=2200 
> [Invalid query] message="Keyspace \'client_warnings\' does not 
> exist"\n:7:InvalidRequest: Error from server: code=2200 [Invalid 
> query] message="No keyspace has been specified. USE a keyspace, or explicitly 
> specify keyspace.tablename"
> {code}



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

[jira] [Created] (CASSANDRA-12326) Use of getByAddress() to retrieve InetAddress object

[Eduardo Aguinaga (JIRA)]

Eduardo Aguinaga created CASSANDRA-12326:


 Summary: Use of getByAddress() to retrieve InetAddress object
 Key: CASSANDRA-12326
 URL: https://issues.apache.org/jira/browse/CASSANDRA-12326
 Project: Cassandra
  Issue Type: Bug
Reporter: Eduardo Aguinaga
 Fix For: 3.0.5


Overview:
In May through June of 2016 a static analysis was performed on version 3.0.5 of 
the Cassandra source code. The analysis included an automated analysis using HP 
Fortify v4.21 SCA and a manual analysis utilizing SciTools Understand v4. The 
results of that analysis includes the issue below.

Issue:
There are four places in the Cassandra source code that rely upon a call to 
getByAddress() to retrieve an InetAddress object. The information returned by 
getByAddress() is not trustworthy. Attackers can spoof DNS entries and 
depending on getByAddress alone invites DNS spoofing attacks.

The four places in the Cassandra source code where getByAddress() is used:
MutationVerbHandler.java Line 58
CompactEndpointSerializationHelper.java Line 38
InetAddressSerializer.java Line 38, 58

MutationVerbHandler.java, lines 49-59:
{code:java}
49 if (from == null)
50 {
51 replyTo = message.from;
52 byte[] forwardBytes = message.parameters.get(Mutation.FORWARD_TO);
53 if (forwardBytes != null)
54 forwardToLocalNodes(message.payload, message.verb, forwardBytes, 
message.from);
55 }
56 else
57 {
58 replyTo = InetAddress.getByAddress(from);
59 }
{code}



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

[jira] [Updated] (CASSANDRA-12310) Use of getByName() to retrieve IP address

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga updated CASSANDRA-12310:
-
Description: 
Overview:
In May through June of 2016 a static analysis was performed on version 3.0.5 of 
the Cassandra source code. The analysis included an automated analysis using HP 
Fortify v4.21 SCA and a manual analysis utilizing SciTools Understand v4. The 
results of that analysis includes the issue below.

Issue:
There are many places in the Cassandra source code that rely upon a call to 
getByName() to retrieve an IP address. The information returned by getByName() 
is not trustworthy. Attackers can spoof DNS entries and depending on getByName 
alone invites DNS spoofing attacks.

getByName() is used in multiple locations within the CASSANDRA source code:
DatabaseDescriptor.java Line 193, 213, 233, 254, 947, 949
RingCache.java Line 82
InetAddressType.java Line 52
FailureDetector.java Line 186
Gossiper.java Line 228, 571, 1517, 1522
CqlBulkRecordWriter.java Line 142, 301
HintsService.java Line 265
DynamicEndpointSnitch.java Line 320
Ec2MultiRegionSnitch.java Line 49
EndpointSnitchInfo.java Line 46, 51
PropertyFileSnitch.java Line 175
ReconnectableSnitchHelper.java Line 52
SimpleSeedProvider.java Line 55
MessagingService.java Line 943
StorageService.java Line 1766, 1835, 2526
ProgressInfoCompositeData.java Line 96
SessionInfoCompositeData.java Line 126, 127
BulkLoader.java Line 399, 422
SetHostStat.java Line 50

This is an example from the file DatabaseDescriptor.java where there are 
examples of the use of getByName() on line 193, 213, 233, 254, 947 and 949.

DatabaseDescriptor.java, lines 231-238:
{code:java}
231 try
232 {
233 rpcAddress = InetAddress.getByName(config.rpc_address);
234 }
235 catch (UnknownHostException e)
236 {
237 throw new ConfigurationException("Unknown host in rpc_address " + 
config.rpc_address, false);
238 }
{code}

  was:
Overview:
In May through June of 2016 a static analysis was performed on version 3.0.5 of 
the Cassandra source code. The analysis included an automated analysis using HP 
Fortify v4.21 SCA and a manual analysis utilizing SciTools Understand v4. The 
results of that analysis includes the issue below.

Issue:
There are many places in the Cassandra source code that rely upon a call to 
getByName() to retrieve an IP address. The information returned by getByName() 
is not trustworthy. Attackers can spoof DNS entries and depending on getByName 
alone invites DNS spoofing attacks.

getByName() is used in multiple locations within the CASSANDRA source code:
DatabaseDescriptor.java Line 193, 213, 233, 254, 947, 949
RingCache.java Line 82
InetAddressType.java Line 52
MutationVerbHandler.java Line 58
FailureDetector.java Line 186
Gossiper.java Line 228, 571, 1517, 1522
CqlBulkRecordWriter.java Line 142, 301
CqlRecordWriter.java Line 351
LimitedLocalNodeFirstLocalBalancingPolicy.java Line 66
HintsService.java Line 265
DynamicEndpointSnitch.java Line 320
Ec2MultiRegionSnitch.java Line 49
EndpointSnitchInfo.java Line 46, 51
PropertyFileSnitch.java Line 175
ReconnectableSnitchHelper.java Line 52
SimpleSeedProvider.java Line 55
CompactEndpointSerializationHelper.java Line 38
MessagingService.java Line 943
InetAddressSerializer.java Line 38, 58
StorageService.java Line 1766, 1835, 2526
ProgressInfoCompositeData.java Line 96
SessionInfoCompositeData.java Line 126, 127
BulkLoader.java Line 399, 422
SetHostStat.java Line 50

This is an example from the file DatabaseDescriptor.java where there are 
examples of the use of getByName() on line 193, 213, 233, 254, 947 and 949.

DatabaseDescriptor.java, lines 231-238:
{code:java}
231 try
232 {
233 rpcAddress = InetAddress.getByName(config.rpc_address);
234 }
235 catch (UnknownHostException e)
236 {
237 throw new ConfigurationException("Unknown host in rpc_address " + 
config.rpc_address, false);
238 }
{code}


> Use of getByName() to retrieve IP address
> -
>
> Key: CASSANDRA-12310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12310
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> There are many places in the Cassandra source code that rely upon a call to 
> getByName() to retrieve an IP address. The information returned by 
> getByName() is not trustworthy. Attackers can spoof DNS entries and depending 
> on getByName alone invites DNS spoofing attacks.
> getByName() is used in multiple locations within the CASSANDRA source code:
> 

[jira] [Updated] (CASSANDRA-12310) Use of getByName() to retrieve IP address

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga updated CASSANDRA-12310:
-
Description: 
Overview:
In May through June of 2016 a static analysis was performed on version 3.0.5 of 
the Cassandra source code. The analysis included an automated analysis using HP 
Fortify v4.21 SCA and a manual analysis utilizing SciTools Understand v4. The 
results of that analysis includes the issue below.

Issue:
There are many places in the Cassandra source code that rely upon a call to 
getByName() to retrieve an IP address. The information returned by getByName() 
is not trustworthy. Attackers can spoof DNS entries and depending on getByName 
alone invites DNS spoofing attacks.

getByName() is used in multiple locations within the CASSANDRA source code:
DatabaseDescriptor.java Line 193, 213, 233, 254, 947, 949
RingCache.java Line 82
InetAddressType.java Line 52
MutationVerbHandler.java Line 58
FailureDetector.java Line 186
Gossiper.java Line 228, 571, 1517, 1522
CqlBulkRecordWriter.java Line 142, 301
CqlRecordWriter.java Line 351
LimitedLocalNodeFirstLocalBalancingPolicy.java Line 66
HintsService.java Line 265
DynamicEndpointSnitch.java Line 320
Ec2MultiRegionSnitch.java Line 49
EndpointSnitchInfo.java Line 46, 51
PropertyFileSnitch.java Line 175
ReconnectableSnitchHelper.java Line 52
SimpleSeedProvider.java Line 55
CompactEndpointSerializationHelper.java Line 38
MessagingService.java Line 943
InetAddressSerializer.java Line 38, 58
StorageService.java Line 1766, 1835, 2526
ProgressInfoCompositeData.java Line 96
SessionInfoCompositeData.java Line 126, 127
BulkLoader.java Line 399, 422
SetHostStat.java Line 50

This is an example from the file DatabaseDescriptor.java where there are 
examples of the use of getByName() on line 193, 213, 233, 254, 947 and 949.

DatabaseDescriptor.java, lines 231-238:
{code:java}
231 try
232 {
233 rpcAddress = InetAddress.getByName(config.rpc_address);
234 }
235 catch (UnknownHostException e)
236 {
237 throw new ConfigurationException("Unknown host in rpc_address " + 
config.rpc_address, false);
238 }
{code}

  was:
Overview:
In May through June of 2016 a static analysis was performed on version 3.0.5 of 
the Cassandra source code. The analysis included an automated analysis using HP 
Fortify v4.21 SCA and a manual analysis utilizing SciTools Understand v4. The 
results of that analysis includes the issue below.

Issue:
There are many places in the Cassandra source code that rely upon a call to 
getByName() to retrieve an IP address. The information returned by getByName() 
is not trustworthy. Attackers can spoof DNS entries and depending on getByName 
alone invites DNS spoofing attacks.

getByName() is used in multiple locations within the CASSANDRA source code:
DatabaseDescriptor.java Line 193, 213, 233, 254, 947, 949
RingCache.java Line 82
InetAddressType.java Line 52
MutationVerbHandler.java Line 58
FailureDetector.java Line 186
Gossiper.java Line 228, 571, 1517, 1522
CqlBulkRecordWriter.java Line 142, 301
CqlRecordWriter.java Line 351
LimitedLocalNodeFirstLocalBalancingPolicy.java Line 66
HintsService.java Line 265
DynamicEndpointSnitch.java Line 320
Ec2MultiRegionSnitch.java Line 49
EndpointSnitchInfo.java Line 46, 51
PropertyFileSnitch.java Line 175
ReconnectableSnitchHelper.java Line 52
SimpleSeedProvider.java Line 55
CompactEndpointSerializationHelper.java Line 38
MessagingService.java Line 943
InetAddressSerializer.java Line 38, 58
StorageService.java Line 1766, 1835, 2526
ProgressInfoCompositeData.java Line 96
SessionInfoCompositeData.java Line 126, 127
BulkLoader.java Line 399, 422
SetHostStat.java Line 50

This is an example from the file DatabaseDescriptor.java where there are 
examples of the use of getByName() on line 193, 213, 233, 254, 947 and 949.

{code:java}
DatabaseDescriptor.java, lines 231-238:
231 try
232 {
233 rpcAddress = InetAddress.getByName(config.rpc_address);
234 }
235 catch (UnknownHostException e)
236 {
237 throw new ConfigurationException("Unknown host in rpc_address " + 
config.rpc_address, false);
238 }
{code}


> Use of getByName() to retrieve IP address
> -
>
> Key: CASSANDRA-12310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12310
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> There are many places in the Cassandra source code that rely upon a call to 
> getByName() to retrieve an IP address. The information returned by 
> getByName() is not 

[jira] [Commented] (CASSANDRA-12219) Cluster + Compact Storage loses counter writes

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-12219:
---

LGTM

> Cluster + Compact Storage loses counter writes
> --
>
> Key: CASSANDRA-12219
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12219
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Brian Wawok
>Assignee: Sylvain Lebresne
> Fix For: 3.0.x, 3.x
>
> Attachments: 0001-add-failing-counter-dtest.patch
>
>
> When we have both multiple nodes, a counter column, and compact storage - 
> some writes are lost.
> Example given in dtest below.
> In Cassandra 3.0 does not work. Before 3.0 they seem to have.



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

[jira] [Updated] (CASSANDRA-12310) Use of getByName() to retrieve IP address

[Eduardo Aguinaga (JIRA)]

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

Eduardo Aguinaga updated CASSANDRA-12310:
-
Description: 
Overview:
In May through June of 2016 a static analysis was performed on version 3.0.5 of 
the Cassandra source code. The analysis included an automated analysis using HP 
Fortify v4.21 SCA and a manual analysis utilizing SciTools Understand v4. The 
results of that analysis includes the issue below.

Issue:
There are many places in the Cassandra source code that rely upon a call to 
getByName() to retrieve an IP address. The information returned by getByName() 
is not trustworthy. Attackers can spoof DNS entries and depending on getByName 
alone invites DNS spoofing attacks.

getByName() is used in multiple locations within the CASSANDRA source code:
DatabaseDescriptor.java Line 193, 213, 233, 254, 947, 949
RingCache.java Line 82
InetAddressType.java Line 52
MutationVerbHandler.java Line 58
FailureDetector.java Line 186
Gossiper.java Line 228, 571, 1517, 1522
CqlBulkRecordWriter.java Line 142, 301
CqlRecordWriter.java Line 351
LimitedLocalNodeFirstLocalBalancingPolicy.java Line 66
HintsService.java Line 265
DynamicEndpointSnitch.java Line 320
Ec2MultiRegionSnitch.java Line 49
EndpointSnitchInfo.java Line 46, 51
PropertyFileSnitch.java Line 175
ReconnectableSnitchHelper.java Line 52
SimpleSeedProvider.java Line 55
CompactEndpointSerializationHelper.java Line 38
MessagingService.java Line 943
InetAddressSerializer.java Line 38, 58
StorageService.java Line 1766, 1835, 2526
ProgressInfoCompositeData.java Line 96
SessionInfoCompositeData.java Line 126, 127
BulkLoader.java Line 399, 422
SetHostStat.java Line 50

This is an example from the file DatabaseDescriptor.java where there are 
examples of the use of getByName() on line 193, 213, 233, 254, 947 and 949.

{code:java}
DatabaseDescriptor.java, lines 231-238:
231 try
232 {
233 rpcAddress = InetAddress.getByName(config.rpc_address);
234 }
235 catch (UnknownHostException e)
236 {
237 throw new ConfigurationException("Unknown host in rpc_address " + 
config.rpc_address, false);
238 }
{code}

  was:
Overview:
In May through June of 2016 a static analysis was performed on version 3.0.5 of 
the Cassandra source code. The analysis included an automated analysis using HP 
Fortify v4.21 SCA and a manual analysis utilizing SciTools Understand v4. The 
results of that analysis includes the issue below.

Issue:
There are many places in the Cassandra source code that rely upon a call to 
getByName() to retrieve an IP address. The information returned by getByName() 
is not trustworthy. Attackers can spoof DNS entries and depending on getByName 
alone invites DNS spoofing attacks.

This is an example from the file DatabaseDescriptor.java where there are 
examples of the use of getByName() on line 193, 213, 233, 254, 947 and 949.

{code:java}
DatabaseDescriptor.java, lines 231-238:
231 try
232 {
233 rpcAddress = InetAddress.getByName(config.rpc_address);
234 }
235 catch (UnknownHostException e)
236 {
237 throw new ConfigurationException("Unknown host in rpc_address " + 
config.rpc_address, false);
238 }
{code}


> Use of getByName() to retrieve IP address
> -
>
> Key: CASSANDRA-12310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12310
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 
> of the Cassandra source code. The analysis included an automated analysis 
> using HP Fortify v4.21 SCA and a manual analysis utilizing SciTools 
> Understand v4. The results of that analysis includes the issue below.
> Issue:
> There are many places in the Cassandra source code that rely upon a call to 
> getByName() to retrieve an IP address. The information returned by 
> getByName() is not trustworthy. Attackers can spoof DNS entries and depending 
> on getByName alone invites DNS spoofing attacks.
> getByName() is used in multiple locations within the CASSANDRA source code:
> DatabaseDescriptor.java Line 193, 213, 233, 254, 947, 949
> RingCache.java Line 82
> InetAddressType.java Line 52
> MutationVerbHandler.java Line 58
> FailureDetector.java Line 186
> Gossiper.java Line 228, 571, 1517, 1522
> CqlBulkRecordWriter.java Line 142, 301
> CqlRecordWriter.java Line 351
> LimitedLocalNodeFirstLocalBalancingPolicy.java Line 66
> HintsService.java Line 265
> DynamicEndpointSnitch.java Line 320
> Ec2MultiRegionSnitch.java Line 49
> EndpointSnitchInfo.java Line 46, 51
> PropertyFileSnitch.java Line 175
> ReconnectableSnitchHelper.java Line 52
> SimpleSeedProvider.java Line 55
> CompactEndpointSerializationHelper.java Line 38
> MessagingService.java Line 943
> InetAddressSerializer.java Line 38, 58
> StorageService.java Line