[jira] [Commented] (CASSANDRA-18037) Use snake case for the names of CQL native functions
[ https://issues.apache.org/jira/browse/CASSANDRA-18037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724764#comment-17724764 ] Berenguer Blasi commented on CASSANDRA-18037: - Surely it looks related. But what versions and branches are you testing? is everything rebased? It's strange bc as you can see CI was green for this ticket. > Use snake case for the names of CQL native functions > > > Key: CASSANDRA-18037 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18037 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Syntax >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 5.0 > > Time Spent: 2h > Remaining Estimate: 0h > > Most native functions are named all lower case, without underscore nor hyphen > to separate words. That's the case, for example, of "intasblob" or > "blobasint". > We also have some functions using camel case, as in "castAsInt" or > "castAsTimestamp". Note that the came cased names require quoting due to > CQL's case insensitivity. > Differently to CQL native functions, system keyspaces, tables and columns > consistently use snake case. For example, we have "system_schema", > "dropped_columns", "default_time_to_live". > As discussed in [this > thread|https://lists.apache.org/thread/k9ml1k4fg6o7mfby1nr3y0mnq9r90dym], we > should adopt snake_case for CQL native function names. Also we should provide > aliases for the current function names, so we don't break compatibility. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14227) Extend maximum expiration date
[
https://issues.apache.org/jira/browse/CASSANDRA-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724760#comment-17724760
]
Berenguer Blasi commented on CASSANDRA-14227:
-
Hi [~benedict] we're a bit blocked here, if you could find a gap it should be a
quick review for the FF having been moved to yaml and it would be highly
appreciated. Thx.
> Extend maximum expiration date
> --
>
> Key: CASSANDRA-14227
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14227
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Paulo Motta (Deprecated)
>Assignee: Berenguer Blasi
>Priority: Urgent
> Fix For: 5.x
>
> Attachments: C14227 Perf check 2023.03.21.pdf, screenshot-1.png,
> screenshot-2.png, screenshot-3.png, screenshot-4.png, unnamed-1.png
>
>
> The maximum expiration timestamp that can be represented by the storage
> engine is
> 2038-01-19T03:14:06+00:00 due to the encoding of {{localExpirationTime}} as
> an int32.
> On CASSANDRA-14092 we added an overflow policy which rejects requests with
> expiration above the maximum date as a temporary measure, but we should
> remove this limitation by updating the storage engine to support at least the
> maximum allowed TTL of 20 years.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724741#comment-17724741 ] Brad Schoening commented on CASSANDRA-15046: Odd that it worked, but it was wrong. Fixed. > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18541) AUTH requests use too much resources
[ https://issues.apache.org/jira/browse/CASSANDRA-18541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724628#comment-17724628 ] Stefan Miklosovic commented on CASSANDRA-18541: --- The provided graphs do not make sense to me but maybe I am interpreting them wrong. When authsuccess rps is compared to cpu usage, it seems like more auth success (more auth requests) are causing more stress on cpu which I would say makes sense in general as some work has to be done right? These options you set (..._validity_in_ms) caches the credentials so it does not go to the disk to read them from the table. That does not mean that the work will not be done. One potential bottleneck might be PasswordAuthenticator.authenticate which calls checkpw method which uses BCrypt which compares a hash from table (hashed password) with a password a client provided to log in. What BCrypt does is that it takes the hash from the table (cached), it parses the number of rounds and other details and it will hash the plaintext password with so and so many rounds. Then it will compare the hash in db with just hashed password. If "cassandra" role has e.g. this hash in system_auth.roles "$2a$10$8XhBMxLGA3px/U0nHOczFOXxUNDcVOrD4czN6zRJHgpaUympsemgW" "2a" in "$2a" is salt version, "10" in "$10" is number of salting round. This can be a number from 4 to 30. Check CassandraRoleManager.getGensaltRounds method. More salting rounds you do, more CPU intensive it will be. I am afraid the complexity of this raises exponentially. If you do like 25 rounds it will start to eat too much CPU and requests may timeout. 10 is sweet spot between complexity and security but if you throw 150 requests on it all of a sudden it may look like what you see. > AUTH requests use too much resources > > > Key: CASSANDRA-18541 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18541 > Project: Cassandra > Issue Type: Bug >Reporter: Yury Vidineev >Priority: Normal > Attachments: Screenshot_20230520_000633.png, > Screenshot_20230520_000654.png > > > Hello. I see unexpected CPU usage in a rare situation that may be worth > digging into. > We have C* 4.0.9 on Debian running on Java 11.0.18. > It's a small cluster of 3 nodes on commodity hardware (6 cores CPU, 32 Gb > RAM, 2 x 512 Gb SSD NVME). > This ring has about 35 clients using Datastax Java Driver for Apache > Cassandra. > In the driver connection settings, we use the following: > CONNECTION_POOL_LOCAL_SIZE = 400 > CONNECTION_POOL_REMOTE_SIZE = 100 > > And for some reason, from time to time, it causes hundreds of AUTH requests > per second that leads to an enormous CPU usage. > And yes, it's easy not to use these settings in the driver, leaving defaults > that don't produce such an amount of AUTHs. But isn't it weird that ~150 AUTH > rps consume ~1200% CPU? > Please see attached graphs. > I have the following in the settings: > authenticator: PasswordAuthenticator > authorizer: CassandraAuthorizer > roles_validity_in_ms: 60 > permissions_validity_in_ms: 60 > credentials_validity_in_ms: 60 > Please let me know if I can provide any other necessary information. > Thanks for your work. Cassandra is amazing :) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18512) nodetool describecluster command is not showing correct Down count.
[ https://issues.apache.org/jira/browse/CASSANDRA-18512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ranju updated CASSANDRA-18512: -- Attachment: 0001-Fix-Down-nodes-counter-in-nodetool-describeCluster-c.patch > nodetool describecluster command is not showing correct Down count. > - > > Key: CASSANDRA-18512 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18512 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Ranju >Assignee: Ranju >Priority: Normal > Attachments: > 0001-Fix-Down-nodes-counter-in-nodetool-describeCluster-c.patch > > > There are some nodes down in the cluster of Cassandra Version 4.x > # nodetool describecluster command output shows these ips as unreachable. > UNREACHABLE: [, , ] > Stats for all nodes: > Live: 3 > Joining: 0 > Moving: 0 > Leaving: 0 > Unreachable: 3 > But under data center , count of down pod is always shown as 0. > Data Centers: > dc1 #Nodes: 3 #Down: 0 > dc2 #Nodes: 3 #Down: 0 > > Steps to reproduce: > # Setup two Data centers dc1,dc2, each datacenter was having 3 nodes - > dc1:3,dc2:3 > # mark down any 3 nodes of two data centers. > # Run nodetool describecluster command from the live node and check the > Unreachable count , which is 3 and Down Count is 0 , both are not matched. > > Expected Output: Unreachable and Down count should have the same value. > Data Centers: > dc1 #Nodes: 3 #Down: 1 > dc2 #Nodes: 3 #Down: 2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18541) AUTH requests use too much resources
[ https://issues.apache.org/jira/browse/CASSANDRA-18541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724622#comment-17724622 ] Brandon Williams commented on CASSANDRA-18541: -- If the high cpu is on the server then I don't think it's a driver problem, but it's not clear. The next step I would take in either case is introspecting the JVM to find out which threads are using all this cpu so I can figure out what they are doing. > AUTH requests use too much resources > > > Key: CASSANDRA-18541 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18541 > Project: Cassandra > Issue Type: Bug >Reporter: Yury Vidineev >Priority: Normal > Attachments: Screenshot_20230520_000633.png, > Screenshot_20230520_000654.png > > > Hello. I see unexpected CPU usage in a rare situation that may be worth > digging into. > We have C* 4.0.9 on Debian running on Java 11.0.18. > It's a small cluster of 3 nodes on commodity hardware (6 cores CPU, 32 Gb > RAM, 2 x 512 Gb SSD NVME). > This ring has about 35 clients using Datastax Java Driver for Apache > Cassandra. > In the driver connection settings, we use the following: > CONNECTION_POOL_LOCAL_SIZE = 400 > CONNECTION_POOL_REMOTE_SIZE = 100 > > And for some reason, from time to time, it causes hundreds of AUTH requests > per second that leads to an enormous CPU usage. > And yes, it's easy not to use these settings in the driver, leaving defaults > that don't produce such an amount of AUTHs. But isn't it weird that ~150 AUTH > rps consume ~1200% CPU? > Please see attached graphs. > I have the following in the settings: > authenticator: PasswordAuthenticator > authorizer: CassandraAuthorizer > roles_validity_in_ms: 60 > permissions_validity_in_ms: 60 > credentials_validity_in_ms: 60 > Please let me know if I can provide any other necessary information. > Thanks for your work. Cassandra is amazing :) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18541) AUTH requests use too much resources
[ https://issues.apache.org/jira/browse/CASSANDRA-18541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724612#comment-17724612 ] Stefan Miklosovic commented on CASSANDRA-18541: --- I think this is a question more for Datastax Java driver Jira rather than for Cassandra itself. Have you read all of this here? https://docs.datastax.com/en/developer/java-driver/4.4/manual/core/pooling/ https://docs.datastax.com/en/developer/java-driver/4.4/manual/core/pooling/#heartbeat > AUTH requests use too much resources > > > Key: CASSANDRA-18541 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18541 > Project: Cassandra > Issue Type: Bug >Reporter: Yury Vidineev >Priority: Normal > Attachments: Screenshot_20230520_000633.png, > Screenshot_20230520_000654.png > > > Hello. I see unexpected CPU usage in a rare situation that may be worth > digging into. > We have C* 4.0.9 on Debian running on Java 11.0.18. > It's a small cluster of 3 nodes on commodity hardware (6 cores CPU, 32 Gb > RAM, 2 x 512 Gb SSD NVME). > This ring has about 35 clients using Datastax Java Driver for Apache > Cassandra. > In the driver connection settings, we use the following: > CONNECTION_POOL_LOCAL_SIZE = 400 > CONNECTION_POOL_REMOTE_SIZE = 100 > > And for some reason, from time to time, it causes hundreds of AUTH requests > per second that leads to an enormous CPU usage. > And yes, it's easy not to use these settings in the driver, leaving defaults > that don't produce such an amount of AUTHs. But isn't it weird that ~150 AUTH > rps consume ~1200% CPU? > Please see attached graphs. > I have the following in the settings: > authenticator: PasswordAuthenticator > authorizer: CassandraAuthorizer > roles_validity_in_ms: 60 > permissions_validity_in_ms: 60 > credentials_validity_in_ms: 60 > Please let me know if I can provide any other necessary information. > Thanks for your work. Cassandra is amazing :) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724610#comment-17724610
]
Stefan Miklosovic edited comment on CASSANDRA-18508 at 5/21/23 10:24 AM:
-
There is also CASSANDRA-11695 we can be inspired of.
was (Author: smiklosovic):
There is also CASSANDRA-11695 we can be inspirated of.
> Sensitive JMX SSL configuration options can be easily exposed
> -
>
> Key: CASSANDRA-18508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18508
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Anthony Grasso
>Assignee: Anthony Grasso
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
>
> We need a way to specify sensitive JMX SSL configuration options to avoid
> them being easily exposed.
> When encrypting the JMX connection the passwords for the key and trust stores
> must be specified using the {{javax.net.ssl.keyStorePassword}} and
> {{javax.net.ssl.trustStorePassword}} options respectively in the
> _cassandra-env.sh_ file. After Cassandra is started it is possible to see the
> passwords by looking the running process ({{ps aux | grep "cassandra"}}).
> Java 8 has the ability to specify a configuration file that can contain these
> security sensitive settings using the {{com.sun.management.config.file}}
> argument. However, despite what the documentation
> ([https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html#gdevf])
> says, both the {{com.sun.management.jmxremote}} and
> {{com.sun.management.jmxremote.port}} arguments need to be defined in the
> _cassandra-env.sh_ for the JVM to read the contents of the file.
> The problem with defining the {{com.sun.management.jmxremote.port}} argument
> is it conflicts with the {{cassandra.jmx.remote.port}} argument. Even if the
> port numbers are different, attempting an encrypted JMX connection using
> {{nodetool}} fails and we see a {{ConnectException: 'Connection refused
> (Connection refused)'}} error.
> One possible way to fix this is to introduce a new option that would allow a
> file to be passed containing the JMX encryption options.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724610#comment-17724610
]
Stefan Miklosovic commented on CASSANDRA-18508:
---
There is also CASSANDRA-11695 we can be inspirated of.
> Sensitive JMX SSL configuration options can be easily exposed
> -
>
> Key: CASSANDRA-18508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18508
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Anthony Grasso
>Assignee: Anthony Grasso
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
>
> We need a way to specify sensitive JMX SSL configuration options to avoid
> them being easily exposed.
> When encrypting the JMX connection the passwords for the key and trust stores
> must be specified using the {{javax.net.ssl.keyStorePassword}} and
> {{javax.net.ssl.trustStorePassword}} options respectively in the
> _cassandra-env.sh_ file. After Cassandra is started it is possible to see the
> passwords by looking the running process ({{ps aux | grep "cassandra"}}).
> Java 8 has the ability to specify a configuration file that can contain these
> security sensitive settings using the {{com.sun.management.config.file}}
> argument. However, despite what the documentation
> ([https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html#gdevf])
> says, both the {{com.sun.management.jmxremote}} and
> {{com.sun.management.jmxremote.port}} arguments need to be defined in the
> _cassandra-env.sh_ for the JVM to read the contents of the file.
> The problem with defining the {{com.sun.management.jmxremote.port}} argument
> is it conflicts with the {{cassandra.jmx.remote.port}} argument. Even if the
> port numbers are different, attempting an encrypted JMX connection using
> {{nodetool}} fails and we see a {{ConnectException: 'Connection refused
> (Connection refused)'}} error.
> One possible way to fix this is to introduce a new option that would allow a
> file to be passed containing the JMX encryption options.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-15046: -- Status: Review In Progress (was: Patch Available) > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-15046: -- Status: Changes Suggested (was: Review In Progress) > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15046) Add a "history" command to cqlsh. Perhaps "show history"?
[ https://issues.apache.org/jira/browse/CASSANDRA-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724607#comment-17724607 ] Stefan Miklosovic commented on CASSANDRA-15046: --- It fails here https://app.circleci.com/pipelines/github/instaclustr/cassandra/2268/workflows/4b0eecc6-9d3a-406f-a9fd-2f20fa4e6b91/jobs/36381/tests#failed-test-0 > Add a "history" command to cqlsh. Perhaps "show history"? > -- > > Key: CASSANDRA-15046 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15046 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Wes Peters >Assignee: Brad Schoening >Priority: Low > Labels: lhf > Fix For: 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > I was trying to capture some create key space and create table commands from > a running cqlsh, and found there was no equivalent to the '\s' history > command in Postgres' psql shell. It's a great tool for figuring out what you > were doing yesterday. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
