[jira] [Created] (CASSANDRA-15091) How to access indexed list of user defined data type as a frozen on a table column "foos" is defined as "list>"?

[Rajeshwar (JIRA)]

Rajeshwar created CASSANDRA-15091:
-

 Summary: How to access indexed list of user defined data type as a 
frozen on a table column "foos" is defined as  "list>"?
 Key: CASSANDRA-15091
 URL: https://issues.apache.org/jira/browse/CASSANDRA-15091
 Project: Cassandra
  Issue Type: Bug
Reporter: Rajeshwar


{{Let foo is defined as foo in below}}
{code:java}
 CREATE TYPE api.foo ( arrival_date_time text, carrier_iata text, carrier_id 
text, carrier_name text, class_code text, departure_date_time text, 
flight_duration int, "from" text, "to" text, via text ); {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-15083) Apache NetBeans "Run", "Debug", "Profile" IDE actions

[mck (JIRA)]

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

mck edited comment on CASSANDRA-15083 at 4/18/19 2:12 AM:
--

Thanks [~djoshi3] for pushing for these extra features in the nb project, and 
for reviewing it.

bq. Could you please update ide.rst to include instructions to set JAVA8_HOME 
and also mention that build, run, debug and profile actions work OOTB.

Done.

Committed as ed2d32612a39188d7ed561cf1a7036cdb147e3f6


was (Author: michaelsembwever):
Thanks [~djoshi3] for pushing for these extra features in the nb project, and 
for reviewing it.

Committed as ed2d32612a39188d7ed561cf1a7036cdb147e3f6

> Apache NetBeans "Run", "Debug", "Profile" IDE actions
> -
>
> Key: CASSANDRA-15083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15083
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: mck
>Assignee: mck
>Priority: Low
> Fix For: 4.0
>
> Attachments: nb-e1.png, nb-e2.png
>
>
> Add to the NetBeans project configuration the action to run Cassandra from 
> the IDE.
> This should be an ant task that executes the {{`bin/cassandra`}} script.
> The ant task should be written into {{ide/nbproject/nbjdk.xml}} (which should 
> probably be renamed to something as it no longer relates to nb's jdk).
> This follows on from the discussion in the original ticket for the NetBeans 
> project configuration in 
> https://issues.apache.org/jira/browse/CASSANDRA-15073?focusedCommentId=16815843&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16815843
> It should be easy to attach either the debugger or profiler to this then 
> running Cassandra.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15083) Apache NetBeans "Run", "Debug", "Profile" IDE actions

[mck (JIRA)]

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

mck updated CASSANDRA-15083:

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

Thanks [~djoshi3] for pushing for these extra features in the nb project, and 
for reviewing it.

Committed as ed2d32612a39188d7ed561cf1a7036cdb147e3f6

> Apache NetBeans "Run", "Debug", "Profile" IDE actions
> -
>
> Key: CASSANDRA-15083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15083
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: mck
>Assignee: mck
>Priority: Low
> Fix For: 4.0
>
> Attachments: nb-e1.png, nb-e2.png
>
>
> Add to the NetBeans project configuration the action to run Cassandra from 
> the IDE.
> This should be an ant task that executes the {{`bin/cassandra`}} script.
> The ant task should be written into {{ide/nbproject/nbjdk.xml}} (which should 
> probably be renamed to something as it no longer relates to nb's jdk).
> This follows on from the discussion in the original ticket for the NetBeans 
> project configuration in 
> https://issues.apache.org/jira/browse/CASSANDRA-15073?focusedCommentId=16815843&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16815843
> It should be easy to attach either the debugger or profiler to this then 
> running Cassandra.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] branch trunk updated: Apache NetBeans "Run", "Debug", "Profile" IDE actions

[mck]

This is an automated email from the ASF dual-hosted git repository.

mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/trunk by this push:
 new ed2d326  Apache NetBeans "Run", "Debug", "Profile" IDE actions
ed2d326 is described below

commit ed2d32612a39188d7ed561cf1a7036cdb147e3f6
Author: Mick Semb Wever 
AuthorDate: Fri Apr 12 21:39:46 2019 +1000

Apache NetBeans "Run", "Debug", "Profile" IDE actions

 patch by Mick Semb Wever ; reviewed by Dinesh Joshi for CASSANDRA-15083
---
 build.xml  | 19 +++--
 doc/source/development/ide.rst | 15 ++-
 ide/nbproject/ide-actions.xml  | 60 ++
 ide/nbproject/nbjdk.xml| 12 -
 ide/nbproject/project.xml  | 42 +++--
 5 files changed, 113 insertions(+), 35 deletions(-)

diff --git a/build.xml b/build.xml
index 6d79aca..3a8dd6c 100644
--- a/build.xml
+++ b/build.xml
@@ -297,7 +297,7 @@
 
 
 
-
+
 
 
 
@@ -1045,10 +1045,7 @@
   
 
 
-
-
+
   
   
   
@@ -1060,17 +1057,17 @@
   
 
   
-  
+  
 
   
-  
+  
 
   
   
   
 
   
-  
+  
 
 
   
@@ -1106,6 +1103,12 @@
   
   
+
+
+
+
   
 
diff --git a/doc/source/development/ide.rst b/doc/source/development/ide.rst
index b6da753..97c73ae 100644
--- a/doc/source/development/ide.rst
+++ b/doc/source/development/ide.rst
@@ -42,6 +42,8 @@ This may take a significant amount of time depending on 
whether artifacts have t
 
You can setup multiple working trees for different Cassandra versions from 
the same repository using `git-worktree 
`_.
 
+|
+
 Setting up Cassandra in IntelliJ IDEA
 =
 
@@ -72,6 +74,8 @@ The project generated by the ant task ``generate-idea-files`` 
contains nearly ev
  * Cassandra code style
  * Inspections
 
+|
+
 Opening Cassandra in Apache NetBeans
 ===
 
@@ -84,8 +88,17 @@ Please clone and build Cassandra as described above and 
execute the following st
 
 1. Start Apache NetBeans
 
-2. Open the NetBeans project from the ``ide\` folder in the checked out (and 
built) Cassandra directory using the menu item "Open Project…" in NetBeans's 
File menu
+2. Open the NetBeans project from the `ide/` folder of the checked out 
Cassandra directory using the menu item "Open Project…" in NetBeans' File menu
+
+The project opened supports building, running, debugging, and profiling 
Cassandra from within the IDE. These actions delegate to the ant `build.xml` 
script.
+
+ * Build/Run/Debug Project is available via the Run/Debug menus, or the 
project context menu.
+ * Profile Project is available via the Profile menu. In the opened Profiler 
tab, click the green "Profile" button.
+ * Cassandra's code style is honored in `ide/nbproject/project.properties`
+
+The `JAVA8_HOME` system variable must be set in the environment that NetBeans 
starts in for the Run/Debug/Profile ant targets to execute.
 
+|
 
 Setting up Cassandra in Eclipse
 ===
diff --git a/ide/nbproject/ide-actions.xml b/ide/nbproject/ide-actions.xml
new file mode 100644
index 000..7a02dcc
--- /dev/null
+++ b/ide/nbproject/ide-actions.xml
@@ -0,0 +1,60 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/ide/nbproject/nbjdk.xml b/ide/nbproject/nbjdk.xml
deleted file mode 100644
index 87439c5..000
--- a/ide/nbproject/nbjdk.xml
+++ /dev/null
@@ -1,12 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/ide/nbproject/project.xml b/ide/nbproject/project.xml
index d00f942..9ca0910 100644
--- a/ide/nbproject/project.xml
+++ b/ide/nbproject/project.xml
@@ -84,54 +84,66 @@
 
 
 
-nbproject/nbjdk.xml
+nbproject/ide-actions.xml
 build
 
 
-nbproject/nbjdk.xml
+nbproject/ide-actions.xml
 clean
 
 
-nbproject/nbjdk.xml
+nbproject/ide-actions.xml
  

[jira] [Updated] (CASSANDRA-15083) Apache NetBeans "Run", "Debug", "Profile" IDE actions

[mck (JIRA)]

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

mck updated CASSANDRA-15083:

Status: Ready to Commit  (was: Review In Progress)

> Apache NetBeans "Run", "Debug", "Profile" IDE actions
> -
>
> Key: CASSANDRA-15083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15083
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: mck
>Assignee: mck
>Priority: Low
> Fix For: 4.x
>
> Attachments: nb-e1.png, nb-e2.png
>
>
> Add to the NetBeans project configuration the action to run Cassandra from 
> the IDE.
> This should be an ant task that executes the {{`bin/cassandra`}} script.
> The ant task should be written into {{ide/nbproject/nbjdk.xml}} (which should 
> probably be renamed to something as it no longer relates to nb's jdk).
> This follows on from the discussion in the original ticket for the NetBeans 
> project configuration in 
> https://issues.apache.org/jira/browse/CASSANDRA-15073?focusedCommentId=16815843&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16815843
> It should be easy to attach either the debugger or profiler to this then 
> running Cassandra.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15083) Apache NetBeans "Run", "Debug", "Profile" IDE actions

[mck (JIRA)]

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

mck updated CASSANDRA-15083:

Test and Documentation Plan: 
Manual testing during the review process.

Documentation will be at 
http://cassandra.apache.org/doc/latest/development/ide.html
 Status: Patch Available  (was: In Progress)

> Apache NetBeans "Run", "Debug", "Profile" IDE actions
> -
>
> Key: CASSANDRA-15083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15083
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: mck
>Assignee: mck
>Priority: Low
> Fix For: 4.x
>
> Attachments: nb-e1.png, nb-e2.png
>
>
> Add to the NetBeans project configuration the action to run Cassandra from 
> the IDE.
> This should be an ant task that executes the {{`bin/cassandra`}} script.
> The ant task should be written into {{ide/nbproject/nbjdk.xml}} (which should 
> probably be renamed to something as it no longer relates to nb's jdk).
> This follows on from the discussion in the original ticket for the NetBeans 
> project configuration in 
> https://issues.apache.org/jira/browse/CASSANDRA-15073?focusedCommentId=16815843&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16815843
> It should be easy to attach either the debugger or profiler to this then 
> running Cassandra.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15083) Apache NetBeans "Run", "Debug", "Profile" IDE actions

[mck (JIRA)]

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

mck updated CASSANDRA-15083:

Status: Review In Progress  (was: Patch Available)

> Apache NetBeans "Run", "Debug", "Profile" IDE actions
> -
>
> Key: CASSANDRA-15083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15083
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: mck
>Assignee: mck
>Priority: Low
> Fix For: 4.x
>
> Attachments: nb-e1.png, nb-e2.png
>
>
> Add to the NetBeans project configuration the action to run Cassandra from 
> the IDE.
> This should be an ant task that executes the {{`bin/cassandra`}} script.
> The ant task should be written into {{ide/nbproject/nbjdk.xml}} (which should 
> probably be renamed to something as it no longer relates to nb's jdk).
> This follows on from the discussion in the original ticket for the NetBeans 
> project configuration in 
> https://issues.apache.org/jira/browse/CASSANDRA-15073?focusedCommentId=16815843&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16815843
> It should be easy to attach either the debugger or profiler to this then 
> running Cassandra.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15089) CassandraNetworkAuthorizer::authorize should get role details from Roles, not directly from IRoleManager

[Blake Eggleston (JIRA)]

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

Blake Eggleston updated CASSANDRA-15089:

Status: Ready to Commit  (was: Review In Progress)

> CassandraNetworkAuthorizer::authorize should get role details from Roles, not 
> directly from IRoleManager
> 
>
> Key: CASSANDRA-15089
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15089
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Authorization
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0
>
>
> If the network permissions cache doesn't contain any entry for a role, the 
> authorize method is invoked on the configured INetworkAuthorizer. In the case 
> of CassandraNetworkAuthorizer, this immediately checks whether the role in 
> question has the LOGIN privilege set. It does this using the configured 
> IRoleManager directly, which causes a read from the underlying table in 
> system_auth. It should fetch the flag from Roles::canLogin, which uses the 
> RolesCache, falling back to the IRoleManager if necessary.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15089) CassandraNetworkAuthorizer::authorize should get role details from Roles, not directly from IRoleManager

[Blake Eggleston (JIRA)]

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

Blake Eggleston updated CASSANDRA-15089:

Status: Review In Progress  (was: Patch Available)

> CassandraNetworkAuthorizer::authorize should get role details from Roles, not 
> directly from IRoleManager
> 
>
> Key: CASSANDRA-15089
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15089
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Authorization
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0
>
>
> If the network permissions cache doesn't contain any entry for a role, the 
> authorize method is invoked on the configured INetworkAuthorizer. In the case 
> of CassandraNetworkAuthorizer, this immediately checks whether the role in 
> question has the LOGIN privilege set. It does this using the configured 
> IRoleManager directly, which causes a read from the underlying table in 
> system_auth. It should fetch the flag from Roles::canLogin, which uses the 
> RolesCache, falling back to the IRoleManager if necessary.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-15089) CassandraNetworkAuthorizer::authorize should get role details from Roles, not directly from IRoleManager

[Blake Eggleston (JIRA)]

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

Blake Eggleston commented on CASSANDRA-15089:
-

+1

> CassandraNetworkAuthorizer::authorize should get role details from Roles, not 
> directly from IRoleManager
> 
>
> Key: CASSANDRA-15089
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15089
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Authorization
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0
>
>
> If the network permissions cache doesn't contain any entry for a role, the 
> authorize method is invoked on the configured INetworkAuthorizer. In the case 
> of CassandraNetworkAuthorizer, this immediately checks whether the role in 
> question has the LOGIN privilege set. It does this using the configured 
> IRoleManager directly, which causes a read from the underlying table in 
> system_auth. It should fetch the flag from Roles::canLogin, which uses the 
> RolesCache, falling back to the IRoleManager if necessary.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-15083) Apache NetBeans "Run", "Debug", "Profile" IDE actions

[Dinesh Joshi (JIRA)]

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

Dinesh Joshi commented on CASSANDRA-15083:
--

hi [~michaelsembwever], this looks very good! I was able to run and debug the 
project OOTB. Could you please update {{ide.rst}} to include instructions to 
set {{JAVA8_HOME}} and also mention that build, run, debug and profile actions 
work OOTB. Please feel free to do it on commit. +1.

> Apache NetBeans "Run", "Debug", "Profile" IDE actions
> -
>
> Key: CASSANDRA-15083
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15083
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: mck
>Assignee: mck
>Priority: Low
> Fix For: 4.x
>
> Attachments: nb-e1.png, nb-e2.png
>
>
> Add to the NetBeans project configuration the action to run Cassandra from 
> the IDE.
> This should be an ant task that executes the {{`bin/cassandra`}} script.
> The ant task should be written into {{ide/nbproject/nbjdk.xml}} (which should 
> probably be renamed to something as it no longer relates to nb's jdk).
> This follows on from the discussion in the original ticket for the NetBeans 
> project configuration in 
> https://issues.apache.org/jira/browse/CASSANDRA-15073?focusedCommentId=16815843&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16815843
> It should be easy to attach either the debugger or profiler to this then 
> running Cassandra.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-14412) Restore automatic snapshot of system keyspace during upgrade

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe updated CASSANDRA-14412:

Since Version: 4.0
   Status: Resolved  (was: Ready to Commit)
   Resolution: Fixed

Thanks [~tommy_s], [~iamaleksey] - committed to trunk in 
{{372a6cfa7b0c5cf52b2db84edf210fa3d5c7f78e}}

> Restore automatic snapshot of system keyspace during upgrade
> 
>
> Key: CASSANDRA-14412
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14412
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0
>
>
> Since 2.2, the installed version is compared with the version persisted in 
> system.local (if any) at startup. If these versions differ, the system 
> keyspace is snapshotted before proceeding in order to enable a rollback if 
> any other issue prevents startup from completing. Although the method to 
> perform this check & snapshot is still present in {{SystemKeyspace}}, its 
> only callsite was mistakenly removed from {{CassandraDaemon}} in 
> CASSANDRA-12716.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[cassandra] branch trunk updated: Restore snapshotting of system ks on version change

[samt]

This is an automated email from the ASF dual-hosted git repository.

samt pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/trunk by this push:
 new 372a6cf  Restore snapshotting of system ks on version change
372a6cf is described below

commit 372a6cfa7b0c5cf52b2db84edf210fa3d5c7f78e
Author: Sam Tunnicliffe 
AuthorDate: Thu Apr 19 11:51:35 2018 +0100

Restore snapshotting of system ks on version change

Patch by Sam Tunnicliffe; reviewed by Tommy Stendahl and Aleksey Yeschenko 
for CASSANDRA-14412
---
 CHANGES.txt |  1 +
 src/java/org/apache/cassandra/db/SystemKeyspace.java| 17 +++--
 .../org/apache/cassandra/service/CassandraDaemon.java   |  9 +
 .../org/apache/cassandra/db/SystemKeyspaceTest.java | 13 +
 4 files changed, 26 insertions(+), 14 deletions(-)

diff --git a/CHANGES.txt b/CHANGES.txt
index 50152aa..b1a43e4 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
 4.0
+ * Restore snapshotting of system keyspaces on version change (CASSANDRA-14412)
  * Fix AbstractBTreePartition locking in java 11 (CASSANDRA-14607)
  * SimpleClient should pass connection properties as options (CASSANDRA-15056)
  * Set repaired data tracking flag on range reads if enabled (CASSANDRA-15019)
diff --git a/src/java/org/apache/cassandra/db/SystemKeyspace.java 
b/src/java/org/apache/cassandra/db/SystemKeyspace.java
index ddf6475..d48f84f 100644
--- a/src/java/org/apache/cassandra/db/SystemKeyspace.java
+++ b/src/java/org/apache/cassandra/db/SystemKeyspace.java
@@ -1389,30 +1389,27 @@ public final class SystemKeyspace
 
 /**
  * Compare the release version in the system.local table with the one 
included in the distro.
- * If they don't match, snapshot all tables in the system keyspace. This 
is intended to be
- * called at startup to create a backup of the system tables during an 
upgrade
+ * If they don't match, snapshot all tables in the system and schema 
keyspaces. This is intended
+ * to be called at startup to create a backup of the system tables during 
an upgrade
  *
  * @throws IOException
  */
-public static boolean snapshotOnVersionChange() throws IOException
+public static void snapshotOnVersionChange() throws IOException
 {
 String previous = getPreviousVersionString();
 String next = FBUtilities.getReleaseVersionString();
 
-// if we're restarting after an upgrade, snapshot the system keyspace
+// if we're restarting after an upgrade, snapshot the system and 
schema keyspaces
 if (!previous.equals(NULL_VERSION.toString()) && 
!previous.equals(next))
 
 {
-logger.info("Detected version upgrade from {} to {}, snapshotting 
system keyspace", previous, next);
+logger.info("Detected version upgrade from {} to {}, snapshotting 
system keyspaces", previous, next);
 String snapshotName = 
Keyspace.getTimestampedSnapshotName(format("upgrade-%s-%s",
  
previous,
  
next));
-Keyspace systemKs = 
Keyspace.open(SchemaConstants.SYSTEM_KEYSPACE_NAME);
-systemKs.snapshot(snapshotName, null);
-return true;
+for (String keyspace : SchemaConstants.LOCAL_SYSTEM_KEYSPACE_NAMES)
+Keyspace.open(keyspace).snapshot(snapshotName, null);
 }
-
-return false;
 }
 
 /**
diff --git a/src/java/org/apache/cassandra/service/CassandraDaemon.java 
b/src/java/org/apache/cassandra/service/CassandraDaemon.java
index af781d5..b8f06f6 100644
--- a/src/java/org/apache/cassandra/service/CassandraDaemon.java
+++ b/src/java/org/apache/cassandra/service/CassandraDaemon.java
@@ -204,6 +204,15 @@ public class CassandraDaemon
 exitOrFail(e.returnCode, e.getMessage(), e.getCause());
 }
 
+try
+{
+SystemKeyspace.snapshotOnVersionChange();
+}
+catch (IOException e)
+{
+exitOrFail(3, e.getMessage(), e.getCause());
+}
+
 // We need to persist this as soon as possible after startup checks.
 // This should be the first write to SystemKeyspace (CASSANDRA-11742)
 SystemKeyspace.persistLocalMetadata();
diff --git a/test/unit/org/apache/cassandra/db/SystemKeyspaceTest.java 
b/test/unit/org/apache/cassandra/db/SystemKeyspaceTest.java
index 3bc04c1..aca13b3 100644
--- a/test/unit/org/apache/cassandra/db/SystemKeyspaceTest.java
+++ b/test/unit/org/apache/cassandra/db/SystemKeyspaceTest.java
@@ -31,6 +31,7 @@ import org.apache.cassandra.cql3.QueryProcessor;
 import org.apache.cassandra.cql3.UntypedResultSet;
 import org.apache.cassandra.dht.ByteOrderedPartitioner.BytesToken;
 import org.apache.

[jira] [Commented] (CASSANDRA-14983) Local reads potentially blocking remote reads

[Marcus Olsson (JIRA)]

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

Marcus Olsson commented on CASSANDRA-14983:
---

I don't necessarily think we should remove the fast path, I might have phrased 
my previous comment a bit ambiguous on that point. For me it depends on what 
expectations and guarantees we want to have for the requests (wrt. 
timeouts/speculative retries). In any case I think it would be really hard to 
have guarantees for both speculative retries and timeouts as there are multiple 
things affecting us here (gc pauses being a major one).

I think your suggestion makes sense, but there is still a problematic situation 
with cluster imbalance. If one node has a slow disk, more sstables or similar 
issues, should it act mostly as a proxy to other nodes or do we accept slow 
requests? If we accept that requests could be slow in those situations then I 
don't think there is any reason to remove the fast path. I'm not sure which 
behavior would be best here as there are arguments for both.

I also want to mention that if we do want to have a feature that waits for 
local requests before doing speculative retries I think we should keep it 
separate from the fast path. The requests can and will go through the normal 
path still and I guess we want to have a similar behavior when that happens.

> Local reads potentially blocking remote reads
> -
>
> Key: CASSANDRA-14983
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14983
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Coordination
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
>Priority: Low
> Attachments: graph_local_read.html, graph_local_read_trunk.html, 
> local_read_trace.log
>
>
> Since CASSANDRA-4718 there is a fast path allowing local requests to continue 
> to [work in the same 
> thread|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/reads/AbstractReadExecutor.java#L157]
>  rather than being sent over to the read stage.
> Based on the comment
> {code:java}
> // We delay the local (potentially blocking) read till the end to avoid 
> stalling remote requests.
> {code}
> it seems like this should be performed last in the chain to avoid blocking 
> remote requests but that does not seem to be the case when the local request 
> is a data request. The digest request(s) are sent after the data requests are 
> sent (and now the transient replica requests as well). When the fast path is 
> used for local data/transient data requests this will block the next type of 
> request from being sent away until the local read is finished and add 
> additional latency to the request.
> In addition to this it seems like local requests are *always* data requests 
> (might not be a problem), but the log message can say either ["digest" or 
> "data"|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/reads/AbstractReadExecutor.java#L156]
>  as the type of request.
> I have tried to run performance measurements to see the impact of this in 3.0 
> (by moving local requests to the end of ARE#executeAsync()) but I haven't 
> seen any big difference yet. I'll continue to run some more tests to see if I 
> can find a use case affected by this.
> Attaching a trace (3.0) where this happens. Reproduction:
>  # Create a three node CCM cluster
>  # Provision data with stress (rf=3)
>  # In parallel:
>  ## Start stress read run
>  ## Run multiple manual read queries in cqlsh with tracing on and 
> local_quorum (as this does not always happen)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15090) Customize cassandra log directory

[Zephyr Guo (JIRA)]

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

Zephyr Guo updated CASSANDRA-15090:
---
Attachment: CASSANDRA-15090-v1.patch

> Customize cassandra log directory
> -
>
> Key: CASSANDRA-15090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15090
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Zephyr Guo
>Assignee: Zephyr Guo
>Priority: Normal
> Attachments: CASSANDRA-15090-v1.patch
>
>
> Add a new variable CASSANDRA_LOG_DIR (default: $CASSANDRA_HOME/logs) so that 
> we could customize log directory such as ‘/var/log/cassandra’ .
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-15090) Customize cassandra log directory

[Zephyr Guo (JIRA)]

Zephyr Guo created CASSANDRA-15090:
--

 Summary: Customize cassandra log directory
 Key: CASSANDRA-15090
 URL: https://issues.apache.org/jira/browse/CASSANDRA-15090
 Project: Cassandra
  Issue Type: New Feature
Reporter: Zephyr Guo
Assignee: Zephyr Guo


Add a new variable CASSANDRA_LOG_DIR (default: $CASSANDRA_HOME/logs) so that we 
could customize log directory such as ‘/var/log/cassandra’ .

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14412) Restore automatic snapshot of system keyspace during upgrade

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko commented on CASSANDRA-14412:
---

LGTM as well.

> Restore automatic snapshot of system keyspace during upgrade
> 
>
> Key: CASSANDRA-14412
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14412
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0
>
>
> Since 2.2, the installed version is compared with the version persisted in 
> system.local (if any) at startup. If these versions differ, the system 
> keyspace is snapshotted before proceeding in order to enable a rollback if 
> any other issue prevents startup from completing. Although the method to 
> perform this check & snapshot is still present in {{SystemKeyspace}}, its 
> only callsite was mistakenly removed from {{CassandraDaemon}} in 
> CASSANDRA-12716.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-14412) Restore automatic snapshot of system keyspace during upgrade

[Aleksey Yeschenko (JIRA)]

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

Aleksey Yeschenko updated CASSANDRA-14412:
--
Status: Ready to Commit  (was: Review In Progress)

> Restore automatic snapshot of system keyspace during upgrade
> 
>
> Key: CASSANDRA-14412
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14412
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0
>
>
> Since 2.2, the installed version is compared with the version persisted in 
> system.local (if any) at startup. If these versions differ, the system 
> keyspace is snapshotted before proceeding in order to enable a rollback if 
> any other issue prevents startup from completing. Although the method to 
> perform this check & snapshot is still present in {{SystemKeyspace}}, its 
> only callsite was mistakenly removed from {{CassandraDaemon}} in 
> CASSANDRA-12716.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-15089) CassandraNetworkAuthorizer::authorize should get role details from Roles, not directly from IRoleManager

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe commented on CASSANDRA-15089:
-

The patch breaks a dtest which was relying on the LOGIN privilege not being 
cached.

||dtest PR||CI||
|[15089|https://github.com/apache/cassandra-dtest/pull/50]|[circle|https://circleci.com/gh/beobal/workflows/cassandra/tree/cci%2F15089-trunk]

> CassandraNetworkAuthorizer::authorize should get role details from Roles, not 
> directly from IRoleManager
> 
>
> Key: CASSANDRA-15089
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15089
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Authorization
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0
>
>
> If the network permissions cache doesn't contain any entry for a role, the 
> authorize method is invoked on the configured INetworkAuthorizer. In the case 
> of CassandraNetworkAuthorizer, this immediately checks whether the role in 
> question has the LOGIN privilege set. It does this using the configured 
> IRoleManager directly, which causes a read from the underlying table in 
> system_auth. It should fetch the flag from Roles::canLogin, which uses the 
> RolesCache, falling back to the IRoleManager if necessary.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-9509) Streams throughput control

[Alain RODRIGUEZ (JIRA)]

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

Alain RODRIGUEZ updated CASSANDRA-9509:
---
Change Category: Operability
 Labels: Stream  (was: )

> Streams throughput control
> --
>
> Key: CASSANDRA-9509
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9509
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Alain RODRIGUEZ
>Priority: Low
>  Labels: Stream
>
> Currently, I have to keep tuning stream throughput all the time manually 
> (through nodetool setstreamthroughput) since the same value stands for 
> example for a decommission or a removenode. The point is in first case data 
> goes from 1 to N nodes (and is obviously limited by the node sending), in the 
> second it goes from ALL to N nodes (N being number of nodes - 1). While 
> removing a node with 'nodetool removenode', throughput limit will not be 
> reached in most cases, and all the nodes will be under heavy load. So with 
> the same value of stream throughput, we send N times faster on a removenode 
> than using decommission to the nodes receiving the data. 
> An other example is running repair. We have 20 nodes, taking 2+ days to 
> repair data, and repair have to run within 10 days, can't be one at the time, 
> and stream throughput needs to be adjusted accordingly.
> Is there a way to:
> - limit incoming streaming throughput on a node ?
> - limit outgoing streaming speed, make sure all the nodes never send more 
> than x Mbps per second to any other node?
> - make streaming processes a background task (using remaining resources only, 
> handle priority) ?
> If none of those ideas are doable, can we imagine to dissociate stream 
> throughputs depending on the operation '1 to many' and 'many to 1' 
> (decommission, rebuild, bootstrap) AND 'N to N' (repairs, removenode), to 
> configure them individually in cassandra.yaml ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15089) CassandraNetworkAuthorizer::authorize should get role details from Roles, not directly from IRoleManager

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe updated CASSANDRA-15089:

Fix Version/s: 4.0

> CassandraNetworkAuthorizer::authorize should get role details from Roles, not 
> directly from IRoleManager
> 
>
> Key: CASSANDRA-15089
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15089
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Authorization
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0
>
>
> If the network permissions cache doesn't contain any entry for a role, the 
> authorize method is invoked on the configured INetworkAuthorizer. In the case 
> of CassandraNetworkAuthorizer, this immediately checks whether the role in 
> question has the LOGIN privilege set. It does this using the configured 
> IRoleManager directly, which causes a read from the underlying table in 
> system_auth. It should fetch the flag from Roles::canLogin, which uses the 
> RolesCache, falling back to the IRoleManager if necessary.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-9509) Streams throughput control

[mck (JIRA)]

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

mck updated CASSANDRA-9509:
---
Labels: Strea  (was: )

> Streams throughput control
> --
>
> Key: CASSANDRA-9509
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9509
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Alain RODRIGUEZ
>Priority: Low
>  Labels: Strea
>
> Currently, I have to keep tuning stream throughput all the time manually 
> (through nodetool setstreamthroughput) since the same value stands for 
> example for a decommission or a removenode. The point is in first case data 
> goes from 1 to N nodes (and is obviously limited by the node sending), in the 
> second it goes from ALL to N nodes (N being number of nodes - 1). While 
> removing a node with 'nodetool removenode', throughput limit will not be 
> reached in most cases, and all the nodes will be under heavy load. So with 
> the same value of stream throughput, we send N times faster on a removenode 
> than using decommission to the nodes receiving the data. 
> An other example is running repair. We have 20 nodes, taking 2+ days to 
> repair data, and repair have to run within 10 days, can't be one at the time, 
> and stream throughput needs to be adjusted accordingly.
> Is there a way to:
> - limit incoming streaming throughput on a node ?
> - limit outgoing streaming speed, make sure all the nodes never send more 
> than x Mbps per second to any other node?
> - make streaming processes a background task (using remaining resources only, 
> handle priority) ?
> If none of those ideas are doable, can we imagine to dissociate stream 
> throughputs depending on the operation '1 to many' and 'many to 1' 
> (decommission, rebuild, bootstrap) AND 'N to N' (repairs, removenode), to 
> configure them individually in cassandra.yaml ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-9509) Streams throughput control

[mck (JIRA)]

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

mck updated CASSANDRA-9509:
---
Labels:   (was: Strea)

> Streams throughput control
> --
>
> Key: CASSANDRA-9509
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9509
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Alain RODRIGUEZ
>Priority: Low
>
> Currently, I have to keep tuning stream throughput all the time manually 
> (through nodetool setstreamthroughput) since the same value stands for 
> example for a decommission or a removenode. The point is in first case data 
> goes from 1 to N nodes (and is obviously limited by the node sending), in the 
> second it goes from ALL to N nodes (N being number of nodes - 1). While 
> removing a node with 'nodetool removenode', throughput limit will not be 
> reached in most cases, and all the nodes will be under heavy load. So with 
> the same value of stream throughput, we send N times faster on a removenode 
> than using decommission to the nodes receiving the data. 
> An other example is running repair. We have 20 nodes, taking 2+ days to 
> repair data, and repair have to run within 10 days, can't be one at the time, 
> and stream throughput needs to be adjusted accordingly.
> Is there a way to:
> - limit incoming streaming throughput on a node ?
> - limit outgoing streaming speed, make sure all the nodes never send more 
> than x Mbps per second to any other node?
> - make streaming processes a background task (using remaining resources only, 
> handle priority) ?
> If none of those ideas are doable, can we imagine to dissociate stream 
> throughputs depending on the operation '1 to many' and 'many to 1' 
> (decommission, rebuild, bootstrap) AND 'N to N' (repairs, removenode), to 
> configure them individually in cassandra.yaml ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15089) CassandraNetworkAuthorizer::authorize should get role details from Roles, not directly from IRoleManager

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe updated CASSANDRA-15089:

Test and Documentation Plan: Additional unit test added.
 Status: Patch Available  (was: Open)

||branch||CI||
|[15089-trunk|https://github.com/beobal/cassandra/tree/15089-trunk]|[circle|https://circleci.com/gh/beobal/workflows/cassandra/tree/cci%2F15089-trunk]|

> CassandraNetworkAuthorizer::authorize should get role details from Roles, not 
> directly from IRoleManager
> 
>
> Key: CASSANDRA-15089
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15089
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Authorization
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
>
> If the network permissions cache doesn't contain any entry for a role, the 
> authorize method is invoked on the configured INetworkAuthorizer. In the case 
> of CassandraNetworkAuthorizer, this immediately checks whether the role in 
> question has the LOGIN privilege set. It does this using the configured 
> IRoleManager directly, which causes a read from the underlying table in 
> system_auth. It should fetch the flag from Roles::canLogin, which uses the 
> RolesCache, falling back to the IRoleManager if necessary.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15089) CassandraNetworkAuthorizer::authorize should get role details from Roles, not directly from IRoleManager

[Sam Tunnicliffe (JIRA)]

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

Sam Tunnicliffe updated CASSANDRA-15089:

 Severity: Low
   Complexity: Low Hanging Fruit
Discovered By: Code Inspection
 Bug Category: Parent values: Degradation(12984)Level 1 values: Performance 
Bug/Regression(12997)
Reviewers: Blake Eggleston
   Status: Open  (was: Triage Needed)

> CassandraNetworkAuthorizer::authorize should get role details from Roles, not 
> directly from IRoleManager
> 
>
> Key: CASSANDRA-15089
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15089
> Project: Cassandra
>  Issue Type: Bug
>  Components: Feature/Authorization
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
>
> If the network permissions cache doesn't contain any entry for a role, the 
> authorize method is invoked on the configured INetworkAuthorizer. In the case 
> of CassandraNetworkAuthorizer, this immediately checks whether the role in 
> question has the LOGIN privilege set. It does this using the configured 
> IRoleManager directly, which causes a read from the underlying table in 
> system_auth. It should fetch the flag from Roles::canLogin, which uses the 
> RolesCache, falling back to the IRoleManager if necessary.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-15089) CassandraNetworkAuthorizer::authorize should get role details from Roles, not directly from IRoleManager

[Sam Tunnicliffe (JIRA)]

Sam Tunnicliffe created CASSANDRA-15089:
---

 Summary: CassandraNetworkAuthorizer::authorize should get role 
details from Roles, not directly from IRoleManager
 Key: CASSANDRA-15089
 URL: https://issues.apache.org/jira/browse/CASSANDRA-15089
 Project: Cassandra
  Issue Type: Bug
  Components: Feature/Authorization
Reporter: Sam Tunnicliffe
Assignee: Sam Tunnicliffe


If the network permissions cache doesn't contain any entry for a role, the 
authorize method is invoked on the configured INetworkAuthorizer. In the case 
of CassandraNetworkAuthorizer, this immediately checks whether the role in 
question has the LOGIN privilege set. It does this using the configured 
IRoleManager directly, which causes a read from the underlying table in 
system_auth. It should fetch the flag from Roles::canLogin, which uses the 
RolesCache, falling back to the IRoleManager if necessary.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-14412) Restore automatic snapshot of system keyspace during upgrade

[Tommy Stendahl (JIRA)]

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

Tommy Stendahl commented on CASSANDRA-14412:


I looked at the changes to the test case and it looks fine.

> Restore automatic snapshot of system keyspace during upgrade
> 
>
> Key: CASSANDRA-14412
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14412
> Project: Cassandra
>  Issue Type: Bug
>  Components: Local/Startup and Shutdown
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0
>
>
> Since 2.2, the installed version is compared with the version persisted in 
> system.local (if any) at startup. If these versions differ, the system 
> keyspace is snapshotted before proceeding in order to enable a rollback if 
> any other issue prevents startup from completing. Although the method to 
> perform this check & snapshot is still present in {{SystemKeyspace}}, its 
> only callsite was mistakenly removed from {{CassandraDaemon}} in 
> CASSANDRA-12716.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-15088) PagingTest failure on trunk

[Marcus Olsson (JIRA)]

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

Marcus Olsson commented on CASSANDRA-15088:
---

Attached a patch for trunk that adds the seed port back in 
cassandra-murmur.yaml that fixes the test case. It seems like it could have 
been missed during a merge from 3.11.

> PagingTest failure on trunk
> ---
>
> Key: CASSANDRA-15088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15088
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
>Priority: Normal
> Attachments: 15088-trunk.txt
>
>
> [Example failure|https://circleci.com/gh/emolsson/cassandra/19]
> {noformat}
> java.lang.RuntimeException: Unable to gossip with any peers
>   at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1546)
>   at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:553)
>   at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:841)
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:650)
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:379)
>   at 
> org.apache.cassandra.service.CassandraDaemon.init(CassandraDaemon.java:501)
>   at 
> org.apache.cassandra.service.EmbeddedCassandraService.start(EmbeddedCassandraService.java:50)
>   at org.apache.cassandra.cql3.PagingTest.setup(PagingTest.java:63)
> {noformat}
> Running the test case by itself won't reproduce the issue:
> {noformat}
> ant test -Dtest.name=PagingTest
> {noformat}
> But running it in parallel with other tests will:
> {noformat}
> ant test -Dtest.name=cql3/*
> {noformat}
> From the logs the following can be observed:
> {noformat}
> INFO  [main] 2019-04-11 15:32:29,916 Node 
> configuration:[...seed_provider=org.apache.cassandra.locator.SimpleSeedProvider{seeds=127.0.0.1:7017};
>  storage_port=7027]
> ...
> DEBUG [main] 2019-04-17 10:11:55,418 connection attempt 0 to 127.0.0.1:7044 
> (GOSSIP)
> DEBUG [main] 2019-04-17 10:11:55,420 creating outbound bootstrap to peer 
> 127.0.0.1:7044, compression: false, encryption: disabled, coalesce: DISABLED, 
> protocolVersion: 12
> DEBUG [ScheduledFastTasks:1] 2019-04-17 10:11:55,538 connection attempt 1 to 
> 127.0.0.1:7044 (GOSSIP)
> DEBUG [ScheduledFastTasks:1] 2019-04-17 10:11:55,538 creating outbound 
> bootstrap to peer 127.0.0.1:7044, compression: false, encryption: disabled, 
> coalesce: DISABLED, protocolVersion: 12
> {noformat}
> It seems like we have an offset issue of 10 between seed/storage_port.
> The port 7044 does not seem to be defined anywhere though.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-15088) PagingTest failure on trunk

[Marcus Olsson (JIRA)]

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

Marcus Olsson updated CASSANDRA-15088:
--
Attachment: 15088-trunk.txt

> PagingTest failure on trunk
> ---
>
> Key: CASSANDRA-15088
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15088
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
>Priority: Normal
> Attachments: 15088-trunk.txt
>
>
> [Example failure|https://circleci.com/gh/emolsson/cassandra/19]
> {noformat}
> java.lang.RuntimeException: Unable to gossip with any peers
>   at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1546)
>   at 
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:553)
>   at 
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:841)
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
>   at 
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:650)
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:379)
>   at 
> org.apache.cassandra.service.CassandraDaemon.init(CassandraDaemon.java:501)
>   at 
> org.apache.cassandra.service.EmbeddedCassandraService.start(EmbeddedCassandraService.java:50)
>   at org.apache.cassandra.cql3.PagingTest.setup(PagingTest.java:63)
> {noformat}
> Running the test case by itself won't reproduce the issue:
> {noformat}
> ant test -Dtest.name=PagingTest
> {noformat}
> But running it in parallel with other tests will:
> {noformat}
> ant test -Dtest.name=cql3/*
> {noformat}
> From the logs the following can be observed:
> {noformat}
> INFO  [main] 2019-04-11 15:32:29,916 Node 
> configuration:[...seed_provider=org.apache.cassandra.locator.SimpleSeedProvider{seeds=127.0.0.1:7017};
>  storage_port=7027]
> ...
> DEBUG [main] 2019-04-17 10:11:55,418 connection attempt 0 to 127.0.0.1:7044 
> (GOSSIP)
> DEBUG [main] 2019-04-17 10:11:55,420 creating outbound bootstrap to peer 
> 127.0.0.1:7044, compression: false, encryption: disabled, coalesce: DISABLED, 
> protocolVersion: 12
> DEBUG [ScheduledFastTasks:1] 2019-04-17 10:11:55,538 connection attempt 1 to 
> 127.0.0.1:7044 (GOSSIP)
> DEBUG [ScheduledFastTasks:1] 2019-04-17 10:11:55,538 creating outbound 
> bootstrap to peer 127.0.0.1:7044, compression: false, encryption: disabled, 
> coalesce: DISABLED, protocolVersion: 12
> {noformat}
> It seems like we have an offset issue of 10 between seed/storage_port.
> The port 7044 does not seem to be defined anywhere though.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-15088) PagingTest failure on trunk

[Marcus Olsson (JIRA)]

Marcus Olsson created CASSANDRA-15088:
-

 Summary: PagingTest failure on trunk
 Key: CASSANDRA-15088
 URL: https://issues.apache.org/jira/browse/CASSANDRA-15088
 Project: Cassandra
  Issue Type: Bug
  Components: Test/unit
Reporter: Marcus Olsson
Assignee: Marcus Olsson


[Example failure|https://circleci.com/gh/emolsson/cassandra/19]
{noformat}
java.lang.RuntimeException: Unable to gossip with any peers
at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1546)
at 
org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:553)
at 
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:841)
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
at 
org.apache.cassandra.service.StorageService.initServer(StorageService.java:650)
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:379)
at 
org.apache.cassandra.service.CassandraDaemon.init(CassandraDaemon.java:501)
at 
org.apache.cassandra.service.EmbeddedCassandraService.start(EmbeddedCassandraService.java:50)
at org.apache.cassandra.cql3.PagingTest.setup(PagingTest.java:63)
{noformat}

Running the test case by itself won't reproduce the issue:
{noformat}
ant test -Dtest.name=PagingTest
{noformat}

But running it in parallel with other tests will:
{noformat}
ant test -Dtest.name=cql3/*
{noformat}

>From the logs the following can be observed:
{noformat}
INFO  [main] 2019-04-11 15:32:29,916 Node 
configuration:[...seed_provider=org.apache.cassandra.locator.SimpleSeedProvider{seeds=127.0.0.1:7017};
 storage_port=7027]

...

DEBUG [main] 2019-04-17 10:11:55,418 connection attempt 0 to 127.0.0.1:7044 
(GOSSIP)
DEBUG [main] 2019-04-17 10:11:55,420 creating outbound bootstrap to peer 
127.0.0.1:7044, compression: false, encryption: disabled, coalesce: DISABLED, 
protocolVersion: 12
DEBUG [ScheduledFastTasks:1] 2019-04-17 10:11:55,538 connection attempt 1 to 
127.0.0.1:7044 (GOSSIP)
DEBUG [ScheduledFastTasks:1] 2019-04-17 10:11:55,538 creating outbound 
bootstrap to peer 127.0.0.1:7044, compression: false, encryption: disabled, 
coalesce: DISABLED, protocolVersion: 12
{noformat}

It seems like we have an offset issue of 10 between seed/storage_port.
The port 7044 does not seem to be defined anywhere though.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-15076) Align record header of FQL and audit binary log

[Vinay Chella (JIRA)]

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

Vinay Chella commented on CASSANDRA-15076:
--

Sure. Happy to help you with the review on this.

> Align record header of FQL and audit binary log
> ---
>
> Key: CASSANDRA-15076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15076
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Tools, Tool/fql
>Reporter: Per Otterström
>Priority: Normal
> Fix For: 4.0
>
>
> The new full query logger and the audit logger support logging into binary 
> Chronicle logs. Both create records with a small header to indicate what 
> follows, but the two features have adopted different header formats. Let's 
> align the record header format with this ticket.
>  * Both features should use the same header layout. This makes it possible to 
> give more user friendly error messages in the {{fqltool}} and 
> {{auditlogviewr}} commands.
>  * The record header should have a distinct {{type}} to indicate the type of 
> record.
>  * The record header should have a {{version}} so that the record format can 
> evolve.
> Current record header format of the FQL is:
> {noformat}
> version:0(int16)
> type:(text)
> {noformat}
> where {{}} can be either {{batch}} or {{single-query}}.
> Current record header format of the binary audit log is:
> {noformat}
> type:AuditLog(text)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org