[jira] [Updated] (CASSANDRA-18076) BLOG - BigDATAwire Open Source Projects to Watch Award
[ https://issues.apache.org/jira/browse/CASSANDRA-18076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18076: --- Reviewers: Michael Semb Wever Status: Review In Progress (was: Patch Available) > BLOG - BigDATAwire Open Source Projects to Watch Award > -- > > Key: CASSANDRA-18076 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18076 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Fix For: NA > > Attachments: BigDATAwire-2022-award.jpg, c18076-01-blog-index.png, > c18076-02-blog-post.png > > > [~Calico]: "We've discovered that Apache Cassandra has won an Open Source > Project to Watch award from BigDATAwire (formerly Datanami)! I've put > together a quick post to go on the blog tomorrow." > https://docs.google.com/document/d/1RzKm8HaD0jVZRIK8IZkFfmr9MgPVi0DK3E8Oz8c2M4Q/edit > !BigDATAwire-2022-award.jpg|width=300! -- 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-18076) BLOG - BigDATAwire Open Source Projects to Watch Award
[ https://issues.apache.org/jira/browse/CASSANDRA-18076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18076: --- Status: Ready to Commit (was: Review In Progress) +1 > BLOG - BigDATAwire Open Source Projects to Watch Award > -- > > Key: CASSANDRA-18076 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18076 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Fix For: NA > > Attachments: BigDATAwire-2022-award.jpg, c18076-01-blog-index.png, > c18076-02-blog-post.png > > > [~Calico]: "We've discovered that Apache Cassandra has won an Open Source > Project to Watch award from BigDATAwire (formerly Datanami)! I've put > together a quick post to go on the blog tomorrow." > https://docs.google.com/document/d/1RzKm8HaD0jVZRIK8IZkFfmr9MgPVi0DK3E8Oz8c2M4Q/edit > !BigDATAwire-2022-award.jpg|width=300! -- 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-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640577#comment-17640577 ] Stefan Miklosovic commented on CASSANDRA-18042: --- Incorporated renaming of properties as suggested above here: https://github.com/apache/cassandra/pull/2027/files > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 2h 20m > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640654#comment-17640654
]
Andres de la Peña commented on CASSANDRA-18042:
---
I agree that the names of the guardrail properties should start by the
guardrail name to keep consistency.
I like the `warn/fail` naming because it's easy to understand and it aligns
well with the naming used for thresholds:
{code:java}
zero_default_ttl_on_twcs_warn: true
zero_default_ttl_on_twcs_fail: false
{code}
However, the downside of this approach is that it breaks the {{*_disabled}}
convention that we are using on other enable flags. So if we wanted to add a
warning to one of the existing enable flags, we would need to change the naming
of the old property,
For example, lets take the currently existing guardrail to disable secondary
indexes:
{code:java}
secondary_indexes_enabled: true
{code}
If at some point we wanted to also add a warning discouraging the use of
secondary indexes, the naming with new convention would be:
{code:java}
secondary_indexes_warn: false
secondary_indexes_fail: false
{code}
But we can't replace the old property because of backward compatibility. That
won't happen if the conventions for warn/fail boolean guardrails were:
{code:java}
secondary_indexes_warned: false
secondary_indexes_enabled: true
{code}
That's why I would consider using:
{code:java}
zero_ttl_on_twcs_warned: true
zero_ttl_on_twcs_enabled: true
{code}
So we have a naming convention that allows to easily transform fail-only
boolean guardrails into warn-or-fail boolean guardrails.
wdyt?
Besides the naming discussion, I have left a few minor suggestion on the PR,
which mostly looks good to me.
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
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-18075) Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4) nodes during upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640664#comment-17640664
]
Brandon Williams commented on CASSANDRA-18075:
--
Your yaml is so stripped down it is missing basic definitions like storage_port
and ssl_storage_port so it's not clear which ports are being used. I would
suggest reproducing the problem with the minimal amount of changes needed to
do, so that everything is still explicitly defined.
> Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4)
> nodes during upgrade
> -
>
> Key: CASSANDRA-18075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18075
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Priority: Normal
> Attachments: cassandra-env.sh_3114, cassandra-env.sh_404,
> cassandra.yaml_3114, cassandra.yaml_404, system.log_10.110.44.207
>
>
> We are testing upgrade from Cassandra 3.11.4 to 4.0.4 on our test cluster
> which is SSL enabled and facing an issue.
> Our cluster size is 3x3.
> {noformat}
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 94.27 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8104.43 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 104.23 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 99.33 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-de-393671-v001-yqlvf:~# nodetool describecluster
> Cluster Information:
> Name: abssl_dev
> Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
> DynamicEndPointSnitch: enabled
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> f68fbc0c-c9d6-3709-8075-c5a0d74192f2: [10.110.4.110,
> 10.110.44.220, 10.109.6.153, 10.109.45.8, 10.109.66.149, 10.110.49.242]
> {noformat}
> During the upgrade, we re-run the pipeline in which we get new server (with
> different IP) that will have Cassandra 4.0.4 binary.
> Disk '/data' (contains data files, commitlogs etc.) will get detached from
> the old server and get attached to the new server.
> This process works fine on non-SSL cluster but when we perform this on SSL
> cluster, new node stops communicating with the rest of the nodes.
> In this example, after upgrade, node 10.110.4.110 got replaced with new
> server with new IP 10.110.44.207.
> *Output from 3.11.4 node:*
> {noformat}
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# hostname -i
> 10.109.6.153
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# java -version
> openjdk version "1.8.0_322"
> OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06)
> OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# nodetool status
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 135.24 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8135.35 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 135.25 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> DN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 104.44 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
>
[jira] [Comment Edited] (CASSANDRA-18075) Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4) nodes during upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640664#comment-17640664
]
Brandon Williams edited comment on CASSANDRA-18075 at 11/29/22 12:34 PM:
-
Your yaml is so stripped down it is missing basic definitions like storage_port
and ssl_storage_port so it's not clear which ports are being used. I would
suggest reproducing the problem with the minimal amount of changes needed, so
that everything is still explicitly defined.
was (Author: brandon.williams):
Your yaml is so stripped down it is missing basic definitions like storage_port
and ssl_storage_port so it's not clear which ports are being used. I would
suggest reproducing the problem with the minimal amount of changes needed to
do, so that everything is still explicitly defined.
> Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4)
> nodes during upgrade
> -
>
> Key: CASSANDRA-18075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18075
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Priority: Normal
> Attachments: cassandra-env.sh_3114, cassandra-env.sh_404,
> cassandra.yaml_3114, cassandra.yaml_404, system.log_10.110.44.207
>
>
> We are testing upgrade from Cassandra 3.11.4 to 4.0.4 on our test cluster
> which is SSL enabled and facing an issue.
> Our cluster size is 3x3.
> {noformat}
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 94.27 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8104.43 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 104.23 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 99.33 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-de-393671-v001-yqlvf:~# nodetool describecluster
> Cluster Information:
> Name: abssl_dev
> Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
> DynamicEndPointSnitch: enabled
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> f68fbc0c-c9d6-3709-8075-c5a0d74192f2: [10.110.4.110,
> 10.110.44.220, 10.109.6.153, 10.109.45.8, 10.109.66.149, 10.110.49.242]
> {noformat}
> During the upgrade, we re-run the pipeline in which we get new server (with
> different IP) that will have Cassandra 4.0.4 binary.
> Disk '/data' (contains data files, commitlogs etc.) will get detached from
> the old server and get attached to the new server.
> This process works fine on non-SSL cluster but when we perform this on SSL
> cluster, new node stops communicating with the rest of the nodes.
> In this example, after upgrade, node 10.110.4.110 got replaced with new
> server with new IP 10.110.44.207.
> *Output from 3.11.4 node:*
> {noformat}
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# hostname -i
> 10.109.6.153
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# java -version
> openjdk version "1.8.0_322"
> OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06)
> OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# nodetool status
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 135.24 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8135.35 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 135.25 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
[jira] [Commented] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640671#comment-17640671 ] Stefan Miklosovic commented on CASSANDRA-18042: --- Naming looks good to me. So it means I need to rename it all yet again and we need to "invert" the logic on that enabled flag. I am on it ... > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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] [Created] (CASSANDRA-18078) Consider removing MAXWRITETIME function
Andres de la Peña created CASSANDRA-18078:
-
Summary: Consider removing MAXWRITETIME function
Key: CASSANDRA-18078
URL: https://issues.apache.org/jira/browse/CASSANDRA-18078
Project: Cassandra
Issue Type: Improvement
Components: CQL/Syntax
Reporter: Andres de la Peña
CASSANDRA-17456 added a new {{MAXWRITETIME}} function that allows to retrieve
the maximum timestamp of a multi-cell column. For example:
{code:java}
> CREATE TABLE t (k int PRIMARY KEY, v set);
> INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> SELECT maxwritetime(v) FROM t;
maxwritetime(v)
-
200
{code}
Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of
each of the cells in a multi-cell column:
{code:java}
> SELECT writetime(v) FROM t;
writetime(v)
-
[100, 100, 200]
> SELECT writetime(v[1]) FROM t;
writetime(v[1])
-
100
{code}
Quite recently, CASSANDRA-18060 has added generic CQL functions to get the min
and max items in a collection. Those functions can be used in combination with
the classic {{writetime}} function to get the same results as the new
{{maxwritetime}} function:
{code:java}
> SELECT collection_max(writetime(v)) FROM t;
system.collection_max(writetime(v))
-
200
{code}
Those new functions can also be used to get the min timestamp, or the min/max
TTL, for which there isn't a specific function:
{code:java}
SELECT collection_min(writetime(v)) FROM t;
SELECT collection_min(writetime(v)) FROM t;
SELECT collection_avg(writetime(v)) FROM t;
SELECT collection_min(ttl(v)) FROM t;
SELECT collection_min(ttl(v)) FROM t;
SELECT collection_avg(ttl(v)) FROM t;
{code}
I think this makes the new {{maxwritetime}} mostly redundant, since the new
functions can achieve the same results in a more generic way. Since the new
{{maxwritetime}} function is only on trunk, we should consider whether we want
to remove it in favour of the generic functions.
--
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-18078) Consider removing MAXWRITETIME function
[
https://issues.apache.org/jira/browse/CASSANDRA-18078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640679#comment-17640679
]
Andres de la Peña commented on CASSANDRA-18078:
---
Here is a patch showing how the removal of {{maxwritetime}} would look like:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2032]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2520/workflows/96c76fe9-95d4-4d4d-9a28-2fa8651b7abe]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2520/workflows/e19c0258-cd3c-4864-a103-187a2d0a81de]|
I have preserved the original test cases, even when they are also a bit
redundant since we have separate tests for {{writetime}} and {{collection_max}}.
> Consider removing MAXWRITETIME function
> ---
>
> Key: CASSANDRA-18078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18078
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-17456 added a new {{MAXWRITETIME}} function that allows to retrieve
> the maximum timestamp of a multi-cell column. For example:
> {code:java}
> > CREATE TABLE t (k int PRIMARY KEY, v set);
> > INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> > UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> > SELECT maxwritetime(v) FROM t;
> maxwritetime(v)
> -
> 200
> {code}
> Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of
> each of the cells in a multi-cell column:
> {code:java}
> > SELECT writetime(v) FROM t;
> writetime(v)
> -
> [100, 100, 200]
> > SELECT writetime(v[1]) FROM t;
> writetime(v[1])
> -
> 100
> {code}
> Quite recently, CASSANDRA-18060 has added generic CQL functions to get the
> min and max items in a collection. Those functions can be used in combination
> with the classic {{writetime}} function to get the same results as the new
> {{maxwritetime}} function:
> {code:java}
> > SELECT collection_max(writetime(v)) FROM t;
> system.collection_max(writetime(v))
> -
> 200
> {code}
> Those new functions can also be used to get the min timestamp, or the min/max
> TTL, for which there isn't a specific function:
> {code:java}
> SELECT collection_min(writetime(v)) FROM t;
> SELECT collection_min(writetime(v)) FROM t;
> SELECT collection_avg(writetime(v)) FROM t;
> SELECT collection_min(ttl(v)) FROM t;
> SELECT collection_min(ttl(v)) FROM t;
> SELECT collection_avg(ttl(v)) FROM t;
> {code}
> I think this makes the new {{maxwritetime}} mostly redundant, since the new
> functions can achieve the same results in a more generic way. Since the new
> {{maxwritetime}} function is only on trunk, we should consider whether we
> want to remove it in favour of the generic functions.
--
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-18078) Consider removing MAXWRITETIME function
[
https://issues.apache.org/jira/browse/CASSANDRA-18078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18078:
-
Description:
CASSANDRA-17425 added a new {{MAXWRITETIME}} function that allows to retrieve
the maximum timestamp of a multi-cell column. For example:
{code:java}
> CREATE TABLE t (k int PRIMARY KEY, v set);
> INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> SELECT maxwritetime(v) FROM t;
maxwritetime(v)
-
200
{code}
Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of
each of the cells in a multi-cell column:
{code:java}
> SELECT writetime(v) FROM t;
writetime(v)
-
[100, 100, 200]
> SELECT writetime(v[1]) FROM t;
writetime(v[1])
-
100
{code}
Quite recently, CASSANDRA-18060 has added generic CQL functions to get the min
and max items in a collection. Those functions can be used in combination with
the classic {{writetime}} function to get the same results as the new
{{maxwritetime}} function:
{code:java}
> SELECT collection_max(writetime(v)) FROM t;
system.collection_max(writetime(v))
-
200
{code}
Those new functions can also be used to get the min timestamp, or the min/max
TTL, for which there isn't a specific function:
{code:java}
SELECT collection_min(writetime(v)) FROM t;
SELECT collection_min(writetime(v)) FROM t;
SELECT collection_avg(writetime(v)) FROM t;
SELECT collection_min(ttl(v)) FROM t;
SELECT collection_min(ttl(v)) FROM t;
SELECT collection_avg(ttl(v)) FROM t;
{code}
I think this makes the new {{maxwritetime}} mostly redundant, since the new
functions can achieve the same results in a more generic way. Since the new
{{maxwritetime}} function is only on trunk, we should consider whether we want
to remove it in favour of the generic functions.
was:
CASSANDRA-17456 added a new {{MAXWRITETIME}} function that allows to retrieve
the maximum timestamp of a multi-cell column. For example:
{code:java}
> CREATE TABLE t (k int PRIMARY KEY, v set);
> INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> SELECT maxwritetime(v) FROM t;
maxwritetime(v)
-
200
{code}
Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of
each of the cells in a multi-cell column:
{code:java}
> SELECT writetime(v) FROM t;
writetime(v)
-
[100, 100, 200]
> SELECT writetime(v[1]) FROM t;
writetime(v[1])
-
100
{code}
Quite recently, CASSANDRA-18060 has added generic CQL functions to get the min
and max items in a collection. Those functions can be used in combination with
the classic {{writetime}} function to get the same results as the new
{{maxwritetime}} function:
{code:java}
> SELECT collection_max(writetime(v)) FROM t;
system.collection_max(writetime(v))
-
200
{code}
Those new functions can also be used to get the min timestamp, or the min/max
TTL, for which there isn't a specific function:
{code:java}
SELECT collection_min(writetime(v)) FROM t;
SELECT collection_min(writetime(v)) FROM t;
SELECT collection_avg(writetime(v)) FROM t;
SELECT collection_min(ttl(v)) FROM t;
SELECT collection_min(ttl(v)) FROM t;
SELECT collection_avg(ttl(v)) FROM t;
{code}
I think this makes the new {{maxwritetime}} mostly redundant, since the new
functions can achieve the same results in a more generic way. Since the new
{{maxwritetime}} function is only on trunk, we should consider whether we want
to remove it in favour of the generic functions.
> Consider removing MAXWRITETIME function
> ---
>
> Key: CASSANDRA-18078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18078
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-17425 added a new {{MAXWRITETIME}} function that allows to retrieve
> the maximum timestamp of a multi-cell column. For example:
> {code:java}
> > CREATE TABLE t (k int PRIMARY KEY, v set);
> > INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> > UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> > SELECT maxwritetime(v) FROM t;
> maxwritetime(v)
> -
> 200
> {code}
> Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of
> each of the cells in a multi-cell column:
> {code:java}
> > SELECT writetime(v) FROM t;
> writetime(v)
> -
> [100, 100, 200]
> > SELECT writetime(v
[jira] [Commented] (CASSANDRA-18078) Consider removing MAXWRITETIME function
[
https://issues.apache.org/jira/browse/CASSANDRA-18078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640688#comment-17640688
]
Andres de la Peña commented on CASSANDRA-18078:
---
CC [~yifanc] [~ frankgh] [~blerer]
> Consider removing MAXWRITETIME function
> ---
>
> Key: CASSANDRA-18078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18078
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-17425 added a new {{MAXWRITETIME}} function that allows to retrieve
> the maximum timestamp of a multi-cell column. For example:
> {code:java}
> > CREATE TABLE t (k int PRIMARY KEY, v set);
> > INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> > UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> > SELECT maxwritetime(v) FROM t;
> maxwritetime(v)
> -
> 200
> {code}
> Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of
> each of the cells in a multi-cell column:
> {code:java}
> > SELECT writetime(v) FROM t;
> writetime(v)
> -
> [100, 100, 200]
> > SELECT writetime(v[1]) FROM t;
> writetime(v[1])
> -
> 100
> {code}
> Quite recently, CASSANDRA-18060 has added generic CQL functions to get the
> min and max items in a collection. Those functions can be used in combination
> with the classic {{writetime}} function to get the same results as the new
> {{maxwritetime}} function:
> {code:java}
> > SELECT collection_max(writetime(v)) FROM t;
> system.collection_max(writetime(v))
> -
> 200
> {code}
> Those new functions can also be used to get the min timestamp, or the min/max
> TTL, for which there isn't a specific function:
> {code:java}
> SELECT collection_min(writetime(v)) FROM t;
> SELECT collection_min(writetime(v)) FROM t;
> SELECT collection_avg(writetime(v)) FROM t;
> SELECT collection_min(ttl(v)) FROM t;
> SELECT collection_min(ttl(v)) FROM t;
> SELECT collection_avg(ttl(v)) FROM t;
> {code}
> I think this makes the new {{maxwritetime}} mostly redundant, since the new
> functions can achieve the same results in a more generic way. Since the new
> {{maxwritetime}} function is only on trunk, we should consider whether we
> want to remove it in favour of the generic functions.
--
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-18076) BLOG - BigDATAwire Open Source Projects to Watch Award
[ https://issues.apache.org/jira/browse/CASSANDRA-18076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640690#comment-17640690 ] Erick Ramirez commented on CASSANDRA-18076: --- Thanks for the review, [~mck] ! 🍻 > BLOG - BigDATAwire Open Source Projects to Watch Award > -- > > Key: CASSANDRA-18076 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18076 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Fix For: NA > > Attachments: BigDATAwire-2022-award.jpg, c18076-01-blog-index.png, > c18076-02-blog-post.png > > > [~Calico]: "We've discovered that Apache Cassandra has won an Open Source > Project to Watch award from BigDATAwire (formerly Datanami)! I've put > together a quick post to go on the blog tomorrow." > https://docs.google.com/document/d/1RzKm8HaD0jVZRIK8IZkFfmr9MgPVi0DK3E8Oz8c2M4Q/edit > !BigDATAwire-2022-award.jpg|width=300! -- 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-18078) Consider removing MAXWRITETIME function
[
https://issues.apache.org/jira/browse/CASSANDRA-18078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640688#comment-17640688
]
Andres de la Peña edited comment on CASSANDRA-18078 at 11/29/22 1:03 PM:
-
CC [~yifanc] [~frankgh] [~blerer]
was (Author: adelapena):
CC [~yifanc] [~ frankgh] [~blerer]
> Consider removing MAXWRITETIME function
> ---
>
> Key: CASSANDRA-18078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18078
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-17425 added a new {{MAXWRITETIME}} function that allows to retrieve
> the maximum timestamp of a multi-cell column. For example:
> {code:java}
> > CREATE TABLE t (k int PRIMARY KEY, v set);
> > INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> > UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> > SELECT maxwritetime(v) FROM t;
> maxwritetime(v)
> -
> 200
> {code}
> Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of
> each of the cells in a multi-cell column:
> {code:java}
> > SELECT writetime(v) FROM t;
> writetime(v)
> -
> [100, 100, 200]
> > SELECT writetime(v[1]) FROM t;
> writetime(v[1])
> -
> 100
> {code}
> Quite recently, CASSANDRA-18060 has added generic CQL functions to get the
> min and max items in a collection. Those functions can be used in combination
> with the classic {{writetime}} function to get the same results as the new
> {{maxwritetime}} function:
> {code:java}
> > SELECT collection_max(writetime(v)) FROM t;
> system.collection_max(writetime(v))
> -
> 200
> {code}
> Those new functions can also be used to get the min timestamp, or the min/max
> TTL, for which there isn't a specific function:
> {code:java}
> SELECT collection_min(writetime(v)) FROM t;
> SELECT collection_min(writetime(v)) FROM t;
> SELECT collection_avg(writetime(v)) FROM t;
> SELECT collection_min(ttl(v)) FROM t;
> SELECT collection_min(ttl(v)) FROM t;
> SELECT collection_avg(ttl(v)) FROM t;
> {code}
> I think this makes the new {{maxwritetime}} mostly redundant, since the new
> functions can achieve the same results in a more generic way. Since the new
> {{maxwritetime}} function is only on trunk, we should consider whether we
> want to remove it in favour of the generic functions.
--
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-18078) Consider removing MAXWRITETIME function
[
https://issues.apache.org/jira/browse/CASSANDRA-18078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18078:
--
Change Category: Semantic
Complexity: Low Hanging Fruit
Fix Version/s: 4.2
Status: Open (was: Triage Needed)
> Consider removing MAXWRITETIME function
> ---
>
> Key: CASSANDRA-18078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18078
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-17425 added a new {{MAXWRITETIME}} function that allows to retrieve
> the maximum timestamp of a multi-cell column. For example:
> {code:java}
> > CREATE TABLE t (k int PRIMARY KEY, v set);
> > INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> > UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> > SELECT maxwritetime(v) FROM t;
> maxwritetime(v)
> -
> 200
> {code}
> Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of
> each of the cells in a multi-cell column:
> {code:java}
> > SELECT writetime(v) FROM t;
> writetime(v)
> -
> [100, 100, 200]
> > SELECT writetime(v[1]) FROM t;
> writetime(v[1])
> -
> 100
> {code}
> Quite recently, CASSANDRA-18060 has added generic CQL functions to get the
> min and max items in a collection. Those functions can be used in combination
> with the classic {{writetime}} function to get the same results as the new
> {{maxwritetime}} function:
> {code:java}
> > SELECT collection_max(writetime(v)) FROM t;
> system.collection_max(writetime(v))
> -
> 200
> {code}
> Those new functions can also be used to get the min timestamp, or the min/max
> TTL, for which there isn't a specific function:
> {code:java}
> SELECT collection_min(writetime(v)) FROM t;
> SELECT collection_min(writetime(v)) FROM t;
> SELECT collection_avg(writetime(v)) FROM t;
> SELECT collection_min(ttl(v)) FROM t;
> SELECT collection_min(ttl(v)) FROM t;
> SELECT collection_avg(ttl(v)) FROM t;
> {code}
> I think this makes the new {{maxwritetime}} mostly redundant, since the new
> functions can achieve the same results in a more generic way. Since the new
> {{maxwritetime}} function is only on trunk, we should consider whether we
> want to remove it in favour of the generic functions.
--
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
[cassandra-website] branch trunk updated: BLOG - Cassandra wins BigDATAwire Projects to Watch Award
This is an automated email from the ASF dual-hosted git repository. erickramirezau pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new 0834e145 BLOG - Cassandra wins BigDATAwire Projects to Watch Award 0834e145 is described below commit 0834e145e5f3bf7b32f2d901b78786ce786ad11c Author: Erick Ramirez AuthorDate: Tue Nov 29 14:26:02 2022 +1100 BLOG - Cassandra wins BigDATAwire Projects to Watch Award --- .../ROOT/images/blog/BigDATAwire-2022-award.jpg| Bin 0 -> 100718 bytes site-content/source/modules/ROOT/pages/blog.adoc | 24 + .../blog/BigDATAWire-Projects-to-Watch-Award.adoc | 22 +++ 3 files changed, 46 insertions(+) diff --git a/site-content/source/modules/ROOT/images/blog/BigDATAwire-2022-award.jpg b/site-content/source/modules/ROOT/images/blog/BigDATAwire-2022-award.jpg new file mode 100644 index ..b9daef9e Binary files /dev/null and b/site-content/source/modules/ROOT/images/blog/BigDATAwire-2022-award.jpg differ diff --git a/site-content/source/modules/ROOT/pages/blog.adoc b/site-content/source/modules/ROOT/pages/blog.adoc index 7e87f1e8..78fa7373 100644 --- a/site-content/source/modules/ROOT/pages/blog.adoc +++ b/site-content/source/modules/ROOT/pages/blog.adoc @@ -8,6 +8,30 @@ NOTES FOR CONTENT CREATORS - Replace post tile, date, description and link to you post. +//start card +[openblock,card shadow relative test] + +[openblock,card-header] +-- +[discrete] +=== Apache Cassandra wins BigDATAwire Open Source Projects to Watch Award +[discrete] + November 29, 2022 +-- +[openblock,card-content] +-- +Apache Cassandra wins the BigDATAwire Open Source Projects to Watch Award for its exciting new features due in the next and future releases. + +[openblock,card-btn card-btn--blog] + +[.btn.btn--alt] +xref:blog/BigDATAWire-Projects-to-Watch-Award.adoc[Read More] + + +-- + +//end card + //start card [openblock,card shadow relative test] diff --git a/site-content/source/modules/ROOT/pages/blog/BigDATAWire-Projects-to-Watch-Award.adoc b/site-content/source/modules/ROOT/pages/blog/BigDATAWire-Projects-to-Watch-Award.adoc new file mode 100644 index ..7587edaf --- /dev/null +++ b/site-content/source/modules/ROOT/pages/blog/BigDATAWire-Projects-to-Watch-Award.adoc @@ -0,0 +1,22 @@ += Apache Cassandra wins BigDATAwire Open Source Projects to Watch Award +:page-layout: single-post +:page-role: blog-post +:page-post-date: Nov 29, 2022 +:page-post-author: Cassandra Community +:description: Apache Cassandra wins award + +image::blog/BigDATAwire-2022-award.jpg[Top 3 Data and AI Open Source Projects to Watch - Apache Cassandra] + +We are pleased to announce that Apache Cassandra has been recognized in the seventh annual BigDATAwire Readers’ and Editors’ Choice Awards. + +Apache Cassandra was recognized with the following honor: + +=== Readers’/Editors’ Choice: Top 3 Data and AI Open Source Projects To Watch + +The BigDATAwire awards recognize companies and products that have made a difference in the big data community this year and provide insight into the state of the industry. The Apache Cassandra community was congratulated by the Managing Editor, Alex Woodie: “Congratulations to all of the winners of the 2022 Readers’ Choice Awards. Companies have a lot of product choices in the big data space today, but thanks to our dedicated readers, we know which ones have gained traction in the real world.” + +This coveted award is a ringing endorsement of the collective and ongoing work of the Cassandra community and comes at an auspicious time as we expect to announce the General Availability (GA) of Apache Cassandra 4.1, the next major release from the project, very soon! + +The eagerly awaited release of Cassandra 4.1 will offer exciting pluggability alongside features focused on better control, improved ease of use, and flexibility that benefits both developers and operators significantly. + +The coveted annual BigDATAwire Readers’ and Editors’ Choice Awards are determined through a nomination and voting process with the global BigDATAwire community, as well as selections from the BigDATAwire editors. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18078) Consider removing MAXWRITETIME function
[
https://issues.apache.org/jira/browse/CASSANDRA-18078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18078:
--
Test and Documentation Plan: The tests for {{maxwritetime}} are updated to
use {{collection_max(writetime)}} instead
Status: Patch Available (was: Open)
> Consider removing MAXWRITETIME function
> ---
>
> Key: CASSANDRA-18078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18078
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-17425 added a new {{MAXWRITETIME}} function that allows to retrieve
> the maximum timestamp of a multi-cell column. For example:
> {code:java}
> > CREATE TABLE t (k int PRIMARY KEY, v set);
> > INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> > UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> > SELECT maxwritetime(v) FROM t;
> maxwritetime(v)
> -
> 200
> {code}
> Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of
> each of the cells in a multi-cell column:
> {code:java}
> > SELECT writetime(v) FROM t;
> writetime(v)
> -
> [100, 100, 200]
> > SELECT writetime(v[1]) FROM t;
> writetime(v[1])
> -
> 100
> {code}
> Quite recently, CASSANDRA-18060 has added generic CQL functions to get the
> min and max items in a collection. Those functions can be used in combination
> with the classic {{writetime}} function to get the same results as the new
> {{maxwritetime}} function:
> {code:java}
> > SELECT collection_max(writetime(v)) FROM t;
> system.collection_max(writetime(v))
> -
> 200
> {code}
> Those new functions can also be used to get the min timestamp, or the min/max
> TTL, for which there isn't a specific function:
> {code:java}
> SELECT collection_min(writetime(v)) FROM t;
> SELECT collection_min(writetime(v)) FROM t;
> SELECT collection_avg(writetime(v)) FROM t;
> SELECT collection_min(ttl(v)) FROM t;
> SELECT collection_min(ttl(v)) FROM t;
> SELECT collection_avg(ttl(v)) FROM t;
> {code}
> I think this makes the new {{maxwritetime}} mostly redundant, since the new
> functions can achieve the same results in a more generic way. Since the new
> {{maxwritetime}} function is only on trunk, we should consider whether we
> want to remove it in favour of the generic functions.
--
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-18078) Consider removing MAXWRITETIME function
[
https://issues.apache.org/jira/browse/CASSANDRA-18078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18078:
--
Description:
CASSANDRA-17425 added a new {{MAXWRITETIME}} function that allows to retrieve
the maximum timestamp of a multi-cell column. For example:
{code:java}
> CREATE TABLE t (k int PRIMARY KEY, v set);
> INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> SELECT maxwritetime(v) FROM t;
maxwritetime(v)
-
200
{code}
Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of
each of the cells in a multi-cell column:
{code:java}
> SELECT writetime(v) FROM t;
writetime(v)
-
[100, 100, 200]
> SELECT writetime(v[1]) FROM t;
writetime(v[1])
-
100
{code}
Quite recently, CASSANDRA-18060 has added generic CQL functions to get the min
and max items in a collection. Those functions can be used in combination with
the classic {{writetime}} function to get the same results as the new
{{maxwritetime}} function:
{code:java}
> SELECT collection_max(writetime(v)) FROM t;
system.collection_max(writetime(v))
-
200
{code}
Those new functions can also be used to get the min timestamp, or the min/max
TTL, for which there isn't a specific function:
{code:java}
SELECT collection_min(writetime(v)) FROM t;
SELECT collection_max(writetime(v)) FROM t;
SELECT collection_avg(writetime(v)) FROM t;
SELECT collection_min(ttl(v)) FROM t;
SELECT collection_max(ttl(v)) FROM t;
SELECT collection_avg(ttl(v)) FROM t;
{code}
I think this makes the new {{maxwritetime}} mostly redundant, since the new
functions can achieve the same results in a more generic way. Since the new
{{maxwritetime}} function is only on trunk, we should consider whether we want
to remove it in favour of the generic functions.
was:
CASSANDRA-17425 added a new {{MAXWRITETIME}} function that allows to retrieve
the maximum timestamp of a multi-cell column. For example:
{code:java}
> CREATE TABLE t (k int PRIMARY KEY, v set);
> INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> SELECT maxwritetime(v) FROM t;
maxwritetime(v)
-
200
{code}
Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of
each of the cells in a multi-cell column:
{code:java}
> SELECT writetime(v) FROM t;
writetime(v)
-
[100, 100, 200]
> SELECT writetime(v[1]) FROM t;
writetime(v[1])
-
100
{code}
Quite recently, CASSANDRA-18060 has added generic CQL functions to get the min
and max items in a collection. Those functions can be used in combination with
the classic {{writetime}} function to get the same results as the new
{{maxwritetime}} function:
{code:java}
> SELECT collection_max(writetime(v)) FROM t;
system.collection_max(writetime(v))
-
200
{code}
Those new functions can also be used to get the min timestamp, or the min/max
TTL, for which there isn't a specific function:
{code:java}
SELECT collection_min(writetime(v)) FROM t;
SELECT collection_min(writetime(v)) FROM t;
SELECT collection_avg(writetime(v)) FROM t;
SELECT collection_min(ttl(v)) FROM t;
SELECT collection_min(ttl(v)) FROM t;
SELECT collection_avg(ttl(v)) FROM t;
{code}
I think this makes the new {{maxwritetime}} mostly redundant, since the new
functions can achieve the same results in a more generic way. Since the new
{{maxwritetime}} function is only on trunk, we should consider whether we want
to remove it in favour of the generic functions.
> Consider removing MAXWRITETIME function
> ---
>
> Key: CASSANDRA-18078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18078
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-17425 added a new {{MAXWRITETIME}} function that allows to retrieve
> the maximum timestamp of a multi-cell column. For example:
> {code:java}
> > CREATE TABLE t (k int PRIMARY KEY, v set);
> > INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> > UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> > SELECT maxwritetime(v) FROM t;
> maxwritetime(v)
> -
> 200
> {code}
> Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of
> each of the cells in a multi-cell column:
> {code:java}
> > SELECT writetime(v) FROM t;
> writetime(v)
> -
> [100, 1
[jira] [Updated] (CASSANDRA-18076) BLOG - BigDATAwire Open Source Projects to Watch Award
[
https://issues.apache.org/jira/browse/CASSANDRA-18076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18076:
--
Source Control Link:
https://github.com/apache/cassandra-website/commit/0834e145e5f3bf7b32f2d901b78786ce786ad11c
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed:
||Branch||PR||Commit||
|{{trunk}}|[#197|https://github.com/apache/cassandra-website/pull/197]|[0834e14|https://github.com/apache/cassandra-website/commit/0834e145e5f3bf7b32f2d901b78786ce786ad11c]|
> BLOG - BigDATAwire Open Source Projects to Watch Award
> --
>
> Key: CASSANDRA-18076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18076
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: BigDATAwire-2022-award.jpg, c18076-01-blog-index.png,
> c18076-02-blog-post.png
>
>
> [~Calico]: "We've discovered that Apache Cassandra has won an Open Source
> Project to Watch award from BigDATAwire (formerly Datanami)! I've put
> together a quick post to go on the blog tomorrow."
> https://docs.google.com/document/d/1RzKm8HaD0jVZRIK8IZkFfmr9MgPVi0DK3E8Oz8c2M4Q/edit
> !BigDATAwire-2022-award.jpg|width=300!
--
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-18076) BLOG - BigDATAwire Open Source Projects to Watch Award
[
https://issues.apache.org/jira/browse/CASSANDRA-18076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640697#comment-17640697
]
Erick Ramirez commented on CASSANDRA-18076:
---
The website content is getting built in staging:
||Branch||PR||Commit||Build||
|{{trunk}}|[#197|https://github.com/apache/cassandra-website/pull/197]|[0834e14|https://github.com/apache/cassandra-website/commit/0834e145e5f3bf7b32f2d901b78786ce786ad11c]|[#787|https://ci-cassandra.apache.org/job/cassandra-website/787/]|
> BLOG - BigDATAwire Open Source Projects to Watch Award
> --
>
> Key: CASSANDRA-18076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18076
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: BigDATAwire-2022-award.jpg, c18076-01-blog-index.png,
> c18076-02-blog-post.png
>
>
> [~Calico]: "We've discovered that Apache Cassandra has won an Open Source
> Project to Watch award from BigDATAwire (formerly Datanami)! I've put
> together a quick post to go on the blog tomorrow."
> https://docs.google.com/document/d/1RzKm8HaD0jVZRIK8IZkFfmr9MgPVi0DK3E8Oz8c2M4Q/edit
> !BigDATAwire-2022-award.jpg|width=300!
--
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-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640700#comment-17640700 ] Stefan Miklosovic commented on CASSANDRA-18042: --- done here: https://github.com/apache/cassandra/pull/2027/files > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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] (CASSANDRA-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042 ] Stefan Miklosovic deleted comment on CASSANDRA-18042: --- was (Author: smiklosovic): done here: https://github.com/apache/cassandra/pull/2027/files > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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
[cassandra-website] branch asf-staging updated (6bbc42ab -> af806a6f)
This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
omit 6bbc42ab generate docs for 59cc0422
add 0834e145 BLOG - Cassandra wins BigDATAwire Projects to Watch Award
new af806a6f generate docs for 0834e145
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (6bbc42ab)
\
N -- N -- N refs/heads/asf-staging (af806a6f)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
content/_/_images/blog/BigDATAwire-2022-award.jpg | Bin 0 -> 100718 bytes
content/_/blog.html| 24 +++
...ml => BigDATAWire-Projects-to-Watch-Award.html} | 47 ++---
content/search-index.js| 2 +-
.../ROOT/images/blog/BigDATAwire-2022-award.jpg| Bin 0 -> 100718 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 24 +++
.../blog/BigDATAWire-Projects-to-Watch-Award.adoc | 22 ++
site-ui/build/ui-bundle.zip| Bin 4970139 -> 4970139
bytes
8 files changed, 93 insertions(+), 26 deletions(-)
create mode 100644 content/_/_images/blog/BigDATAwire-2022-award.jpg
copy content/_/blog/{Upgrade-Advisory2.html =>
BigDATAWire-Projects-to-Watch-Award.html} (85%)
create mode 100644
site-content/source/modules/ROOT/images/blog/BigDATAwire-2022-award.jpg
create mode 100644
site-content/source/modules/ROOT/pages/blog/BigDATAWire-Projects-to-Watch-Award.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18076) BLOG - BigDATAwire Open Source Projects to Watch Award
[ https://issues.apache.org/jira/browse/CASSANDRA-18076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640703#comment-17640703 ] Erick Ramirez commented on CASSANDRA-18076: --- The build completed in 15 minutes and the new blog post is now in staging – https://cassandra.staged.apache.org/_/blog/BigDATAWire-Projects-to-Watch-Award.html. > BLOG - BigDATAwire Open Source Projects to Watch Award > -- > > Key: CASSANDRA-18076 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18076 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Fix For: NA > > Attachments: BigDATAwire-2022-award.jpg, c18076-01-blog-index.png, > c18076-02-blog-post.png > > > [~Calico]: "We've discovered that Apache Cassandra has won an Open Source > Project to Watch award from BigDATAwire (formerly Datanami)! I've put > together a quick post to go on the blog tomorrow." > https://docs.google.com/document/d/1RzKm8HaD0jVZRIK8IZkFfmr9MgPVi0DK3E8Oz8c2M4Q/edit > !BigDATAwire-2022-award.jpg|width=300! -- 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-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640705#comment-17640705 ] Stefan Miklosovic commented on CASSANDRA-18042: --- ok done here: https://github.com/apache/cassandra/pull/2027/files j11 https://app.circleci.com/pipelines/github/instaclustr/cassandra/1625/workflows/21487fae-9fb0-4014-b499-f24893e568fc j8 https://app.circleci.com/pipelines/github/instaclustr/cassandra/1625/workflows/58e0f2e7-b796-4b32-8062-64e4798e5624 > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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
[cassandra-website] branch asf-site updated (6bbc42ab -> af806a6f)
This is an automated email from the ASF dual-hosted git repository.
erickramirezau pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
discard 6bbc42ab generate docs for 59cc0422
add 0834e145 BLOG - Cassandra wins BigDATAwire Projects to Watch Award
add af806a6f generate docs for 0834e145
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (6bbc42ab)
\
N -- N -- N refs/heads/asf-site (af806a6f)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
No new revisions were added by this update.
Summary of changes:
content/_/_images/blog/BigDATAwire-2022-award.jpg | Bin 0 -> 100718 bytes
content/_/blog.html| 24 +++
...ml => BigDATAWire-Projects-to-Watch-Award.html} | 47 ++---
content/search-index.js| 2 +-
.../ROOT/images/blog/BigDATAwire-2022-award.jpg| Bin 0 -> 100718 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 24 +++
.../blog/BigDATAWire-Projects-to-Watch-Award.adoc | 22 ++
site-ui/build/ui-bundle.zip| Bin 4970139 -> 4970139
bytes
8 files changed, 93 insertions(+), 26 deletions(-)
create mode 100644 content/_/_images/blog/BigDATAwire-2022-award.jpg
copy content/_/blog/{Upgrade-Advisory2.html =>
BigDATAWire-Projects-to-Watch-Award.html} (85%)
create mode 100644
site-content/source/modules/ROOT/images/blog/BigDATAwire-2022-award.jpg
create mode 100644
site-content/source/modules/ROOT/pages/blog/BigDATAWire-Projects-to-Watch-Award.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18076) BLOG - BigDATAwire Open Source Projects to Watch Award
[
https://issues.apache.org/jira/browse/CASSANDRA-18076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640708#comment-17640708
]
Erick Ramirez commented on CASSANDRA-18076:
---
I’ve completed final verification in staging and [published to
production|https://github.com/apache/cassandra-website#merging-asf-staging-to-asf-site]:
{noformat}
$ git branch
* trunk
$ git fetch origin
$ git checkout asf-site
Branch ‘asf-site’ set up to track remote branch ‘asf-site’ from ‘origin’.
Switched to a new branch ‘asf-site’
$ git branch
* asf-site
trunk
$ git reset --hard origin/asf-staging
HEAD is now at af806a6f generate docs for 0834e145
$ git push -f origin asf-site
Total 0 (delta 0), reused 0 (delta 0)
To [https://github.com/apache/cassandra-website.git]
+ 6bbc42ab...af806a6f asf-site -> asf-site (forced update)
{noformat}
The new blog post is now live on the site –
https://cassandra.apache.org/_/blog/BigDATAWire-Projects-to-Watch-Award.html
> BLOG - BigDATAwire Open Source Projects to Watch Award
> --
>
> Key: CASSANDRA-18076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18076
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: BigDATAwire-2022-award.jpg, c18076-01-blog-index.png,
> c18076-02-blog-post.png
>
>
> [~Calico]: "We've discovered that Apache Cassandra has won an Open Source
> Project to Watch award from BigDATAwire (formerly Datanami)! I've put
> together a quick post to go on the blog tomorrow."
> https://docs.google.com/document/d/1RzKm8HaD0jVZRIK8IZkFfmr9MgPVi0DK3E8Oz8c2M4Q/edit
> !BigDATAwire-2022-award.jpg|width=300!
--
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-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[
https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640728#comment-17640728
]
Andres de la Peña commented on CASSANDRA-18042:
---
Thanks, looks good to me, +1 if CI finishes ok.
We should also wait a bit to see if others are also happy with the naming
convention. That convention should in principle be used for other similar
future guardrails. That includes the case of adding configurable warnings to
existing enable flags, which should be very easy thanks to this patch :)
Just a nit, in the spirit of CASSANDRA-17967 we should probably add to
{{cassandra.yaml}} a brief explanation of why the guardrail exists. That
explanation would be very similar, if not identical, to the {{reason}}
attribute used in the guardrail. So, for example
{code}
# Guardrail to warn and/or enable a CREATE or ALTER TABLE statement when
default_time_to_live is set to 0
# and the table is using TimeWindowCompactionStrategy compaction or a subclass
of it.
# It is suspicious to use default_time_to_live set to 0 with
TimeWindowCompactionStrategy because the data that hasn't
# been inserted or updated with a TTL will not start to automatically expire
after they are older than a respective
# compaction window unit of a certain size.
#zero_ttl_on_twcs_warned: true
#zero_ttl_on_twcs_enabled: true
{code}
> Implement a guardrail for not having zero default ttl on tables with TWCS
> -
>
> Key: CASSANDRA-18042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18042
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails, Legacy/Core
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> A user was surprised that his data have not started to expire after 90 days
> on his TWCS, he noticed that default_time_to_live on the table was set to 0
> (by accident from his side) and inserts were using TTL = 0 too.
> It is questionable why it it possible to create a table with TWCS and enable
> a user to specify default_time_to_live to be zero.
> On the other hand, I would argue that having default_time_to_live set to 0 on
> TWCS does not necessarily mean that such combination is illegal. It is about
> people just using that with advantage very often so tables are compacted away
> nicely. However, that does not have to mean that they could not use it with
> 0. But I yet have to see a use-case where TWCS was used and default ttl was
> set to 0 on purpose. Merely looking into Cassandra codebase, there are only
> cases when this parameter is not 0.
> There are three approaches:
> 1) just reject such statements (for CreateTable and AlterTable statements)
> where default_time_to_live = 0
> 2) Implement a guardrail for 1) so it can be enabled / disabled on demand
> 3) Leave possibility to set default_time_to_live to 0 on a table but make a
> guardrail for UpdateStatement so it might reject queries for tables with
> default_time_to_live is zero and for which its TTL (on that update statement)
> is set to 0 too.
> I would be careful about making the current configuration illegal because of
> backward compatibility. For that reason 2) makes the most sense to me.
> Maybe implementing 3) would make sense as well. There might be a table which
> has default ttl set to 0 as it expects a user to supply TTL every time.
> However, as it is not currently enforced anywhere, a client might still
> insert TTLs to be set to 0 even by accident.
> POC for 2) is here
> https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579
--
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-17925) Java source code should have sorted imports as defined in the codestyle
[
https://issues.apache.org/jira/browse/CASSANDRA-17925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640746#comment-17640746
]
Maxim Muzafarov commented on CASSANDRA-17925:
-
I'm sorry for such seditious thoughts, but...
Is it possible to remove the
[ide|https://github.com/Mmuzaf/cassandra/tree/trunk/ide] directory from the VCS
at all?
It is very rarely updated (only a few commits for the last 7 years).
We can take the actual IDE configurations from the community members who
actually use these IDEs with Cassandra every day and put them in the project's
root folder (like it happened for the CI tools .jenkins, .circleci, .github
before). At the first glance, it may look weird, but it seems this is a common
practice for sharing IDE configurations as mentioned here [1]. One of the
biggest benefits of such change - community members will immediately be able to
use new updated code style profiles from the VCS once they are switched to the
trunk (no need to rebuild code style with ant). As another benefit, we can
remove the 'generate-idea-files' from the build.xml and simplify the ant file
even more.
As soon as the checkstyle configuration is filled with a large number of new
rules we will remove the IDE-specific directories (e.g. .idea) and make
checkstyle a single point for code style rules (keeping the wiki and web pages
as human-readable code style).
For the current issue it is better to split it into two commits:
1. remove star-imports from the source code in the trunk (and optional for
4.1), and add such checkstyle rule for production code as well as for tests;
2. agree on the import order with the community and add an appropriate
checkstyle rule;
The steps above will simplify solving merge conflicts if any occur.
[1]
https://www.jetbrains.com/help/objc/share-project-settings.html#share-global-settings
> Java source code should have sorted imports as defined in the codestyle
> ---
>
> Key: CASSANDRA-17925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17925
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Stefan Miklosovic
>Assignee: Maxim Muzafarov
>Priority: Normal
>
> After we cleaned all unused imports in CASSANDRA-17876, there is one more
> task remaining to be done - to add checkstyle for imports order and enforce
> this on build time.
> When the project is imported into IDEA, there is a helper target on Ant
> called "generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
> {code:java}
>
>
>
>
>
> static="false" />
> static="false" />
> static="false" />
> static="false" />
>
>
>
>
>
>
>
>
> {code}
> This code style is also mentioned in the web page here (minus some details
> which are present in above configuration snippet but not on the web page):
> [https://cassandra.apache.org/_/development/code_style.html] (at the very
> bottom).
> However, when one runs "Optimise imports" in the context menu after
> right-clicking on org.cassandra.apache package, it will refactor the imports
> and it results with hundreds of changes.
> This means that the source code, as-is, does not adhere to the self-imposed
> code style we ship for IDEA.
> If we fix this, we should add checkstyle for it like this:
> {code:java}
>
>value="/(^java\.|javax)/,/(com\.google\.common|org\.apache\.log4j|org\.apache\.commons|org\.cliffc\.high_scale_lib|org\.junit|org\.slf4j)/"/>
>
>
>
>
>
>
> {code}
> This checkstyle on import order will pass on the source code we run the
> import optimization in the context menu on.
> There is also no enforcement on "all star" imports (org.some.pkg.*).
> Checkstyle has specific module for this:
> [https://checkstyle.org/config_imports.html#AvoidStarImport]
> I propose we should stop to use all-star imports. Same argument holds as
> described there: Rationale: Importing all classes from a package or static
> members from a class leads to tight coupling between packages or classes and
> might lead to problems when a new version of a library introduces name
> clashes.
> This should be applied to test checktyle as well and the source code should
> be refactored on imports too.
> This should be done on cassandra-4.1 as well as for trunk.
--
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-18058) In-memory index and query path
[
https://issues.apache.org/jira/browse/CASSANDRA-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640749#comment-17640749
]
Andres de la Peña commented on CASSANDRA-18058:
---
Thanks for addressing the import issues. After that, there is another failure
on {{{}eclipse-warnings{}}}:
{code:java}
eclipse-warnings:
[mkdir] Created dir: /Users/adelapena/src/cassandra/trunk/build/ecj
[echo] Running Eclipse Code Analysis. Output logged to
/Users/adelapena/src/cassandra/trunk/build/ecj/eclipse_compiler_checks.txt
[java] --
[java] 1. ERROR in
/Users/adelapena/src/cassandra/trunk/src/java/org/apache/cassandra/index/sai/plan/StorageAttachedIndexSearcher.java
(at line 195)
[java] return iterator != null
[java]? iteratePartition(iterator)
[java]: endOfData();
[java]
^
[java] Potential resource leak: 'iterator' may not be closed at this
location
[java] --
[java] 1 problem (1 error)
{code}
Did you manage to build without problems or run CI? CI build job uses these Ant
targets:
{code:java}
ant clean realclean jar eclipse-warnings{code}
> In-memory index and query path
> --
>
> Key: CASSANDRA-18058
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18058
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/SAI
>Reporter: Mike Adamson
>Assignee: Mike Adamson
>Priority: Normal
> Fix For: 5.x
>
>
> An in-memory index using the in-memory trie structure introduced with
> CASSANDRA-17240 along with a query path implementation to perform index
> queries from the in-memory index.
--
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-18042) Implement a guardrail for not having zero default ttl on tables with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640797#comment-17640797 ] Stefan Miklosovic commented on CASSANDRA-18042: --- Ok, will be done on commit. Lets wait for others to have some feedback if they are OK with that as well. > Implement a guardrail for not having zero default ttl on tables with TWCS > - > > Key: CASSANDRA-18042 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18042 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails, Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 3h > Remaining Estimate: 0h > > A user was surprised that his data have not started to expire after 90 days > on his TWCS, he noticed that default_time_to_live on the table was set to 0 > (by accident from his side) and inserts were using TTL = 0 too. > It is questionable why it it possible to create a table with TWCS and enable > a user to specify default_time_to_live to be zero. > On the other hand, I would argue that having default_time_to_live set to 0 on > TWCS does not necessarily mean that such combination is illegal. It is about > people just using that with advantage very often so tables are compacted away > nicely. However, that does not have to mean that they could not use it with > 0. But I yet have to see a use-case where TWCS was used and default ttl was > set to 0 on purpose. Merely looking into Cassandra codebase, there are only > cases when this parameter is not 0. > There are three approaches: > 1) just reject such statements (for CreateTable and AlterTable statements) > where default_time_to_live = 0 > 2) Implement a guardrail for 1) so it can be enabled / disabled on demand > 3) Leave possibility to set default_time_to_live to 0 on a table but make a > guardrail for UpdateStatement so it might reject queries for tables with > default_time_to_live is zero and for which its TTL (on that update statement) > is set to 0 too. > I would be careful about making the current configuration illegal because of > backward compatibility. For that reason 2) makes the most sense to me. > Maybe implementing 3) would make sense as well. There might be a table which > has default ttl set to 0 as it expects a user to supply TTL every time. > However, as it is not currently enforced anywhere, a client might still > insert TTLs to be set to 0 even by accident. > POC for 2) is here > https://github.com/instaclustr/cassandra/commit/0b4dcc3d3deeffa393c02a3b80e27482007f9579 -- 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-18075) Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4) nodes during upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640802#comment-17640802
]
Alaykumar Barochia commented on CASSANDRA-18075:
[~brandon.williams] - Whenever we do not define {{storage_port}} and
{{ssl_storage_port}} explicitly, it takes the default value, which is {{7000}}
and {{7001}} respectively. In my setup also, on both 3.11.4 and 4.0.4 versions,
it is taking these values only.
Below is the snippet from system.log file from both version which clearly shows
{{7000}} and {{7001}} port is being used for {{storage_port}} and
{{ssl_storage_port}} respectively.
*4.0.4:*
{noformat}
47; row_cache_save_period=0; row_cache_size_in_mb=0; rpc_address=0.0.0.0;
rpc_interface=null; rpc_interface_prefer_ipv6=false; rpc_keepalive=true;
saved_caches_directory=/data/saved_caches;
seed_provider=org.apache.cassandra.locator.SimpleSeedProvider{seeds=10.109.45.8,10.109.6.153,10.110.44.207,10.110.44.220};
server_encryption_options=; slow_query_log_timeout_in_ms=500;
snapshot_before_compaction=false; snapshot_links_per_second=0;
snapshot_on_duplicate_row_detection=false;
snapshot_on_repaired_data_mismatch=false; ssl_storage_port=7001;
sstable_preemptive_open_interval_in_mb=50; start_native_transport=true;
storage_port=7000; stream_entire_sstables=true;
stream_throughput_outbound_megabits_per_sec=200;
streaming_connections_per_host=1; streaming_keep_alive_period_in_secs=300;
table_count_warn_threshold=150; tombstone_failure_threshold=10;
tombstone_warn_threshold=1000; tracetype_query_ttl=86400;
tracetype_repair_ttl=604800;
transparent_data_encryption_options=org.apache.cassandra.conf
{noformat}
*3.11.4*
{noformat}
es=null; rpc_send_buff_size_in_bytes=null; rpc_server_type=sync;
saved_caches_directory=/data/saved_caches;
seed_provider=org.apache.cassandra.locator.SimpleSeedProvider{seeds=10.109.45.8,10.109.6.153,10.110.4.110,10.110.44.220};
server_encryption_options=; slow_query_log_timeout_in_ms=500;
snapshot_before_compaction=false; ssl_storage_port=7001;
sstable_preemptive_open_interval_in_mb=50; start_native_transport=true;
start_rpc=false; storage_port=7000;
stream_throughput_outbound_megabits_per_sec=200;
streaming_keep_alive_period_in_secs=300;
streaming_socket_timeout_in_ms=8640; thrift_framed_transport_size_in_mb=15
{noformat}
> Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4)
> nodes during upgrade
> -
>
> Key: CASSANDRA-18075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18075
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Priority: Normal
> Attachments: cassandra-env.sh_3114, cassandra-env.sh_404,
> cassandra.yaml_3114, cassandra.yaml_404, system.log_10.110.44.207
>
>
> We are testing upgrade from Cassandra 3.11.4 to 4.0.4 on our test cluster
> which is SSL enabled and facing an issue.
> Our cluster size is 3x3.
> {noformat}
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 94.27 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8104.43 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 104.23 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 99.33 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-de-393671-v001-yqlvf:~# nodetool describecluster
> Cluster Information:
> Name: abssl_dev
> Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
> DynamicEndPointSnitch: enabled
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> f68fbc0c-c9d6-3709-8075-c5a0d74192f2: [10.110.4.110,
> 10.110.44.220, 10.109.6.153, 10.109.45.8, 10.109.66.149, 10.110.49.242]
> {noformat}
> During the upgrade, we re-run the pipeline in which we get new server (with
> different IP) that will have Cassandra 4.0.4 binary.
> Disk '/data' (contain
[jira] [Commented] (CASSANDRA-18078) Consider removing MAXWRITETIME function
[
https://issues.apache.org/jira/browse/CASSANDRA-18078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640803#comment-17640803
]
Francisco Guerrero commented on CASSANDRA-18078:
+1 from me. It looks good
> Consider removing MAXWRITETIME function
> ---
>
> Key: CASSANDRA-18078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18078
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CASSANDRA-17425 added a new {{MAXWRITETIME}} function that allows to retrieve
> the maximum timestamp of a multi-cell column. For example:
> {code:java}
> > CREATE TABLE t (k int PRIMARY KEY, v set);
> > INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> > UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> > SELECT maxwritetime(v) FROM t;
> maxwritetime(v)
> -
> 200
> {code}
> Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of
> each of the cells in a multi-cell column:
> {code:java}
> > SELECT writetime(v) FROM t;
> writetime(v)
> -
> [100, 100, 200]
> > SELECT writetime(v[1]) FROM t;
> writetime(v[1])
> -
> 100
> {code}
> Quite recently, CASSANDRA-18060 has added generic CQL functions to get the
> min and max items in a collection. Those functions can be used in combination
> with the classic {{writetime}} function to get the same results as the new
> {{maxwritetime}} function:
> {code:java}
> > SELECT collection_max(writetime(v)) FROM t;
> system.collection_max(writetime(v))
> -
> 200
> {code}
> Those new functions can also be used to get the min timestamp, or the min/max
> TTL, for which there isn't a specific function:
> {code:java}
> SELECT collection_min(writetime(v)) FROM t;
> SELECT collection_max(writetime(v)) FROM t;
> SELECT collection_avg(writetime(v)) FROM t;
> SELECT collection_min(ttl(v)) FROM t;
> SELECT collection_max(ttl(v)) FROM t;
> SELECT collection_avg(ttl(v)) FROM t;
> {code}
> I think this makes the new {{maxwritetime}} mostly redundant, since the new
> functions can achieve the same results in a more generic way. Since the new
> {{maxwritetime}} function is only on trunk, we should consider whether we
> want to remove it in favour of the generic functions.
--
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-18058) In-memory index and query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640806#comment-17640806 ] Mike Adamson commented on CASSANDRA-18058: -- Sorry, I was not aware of the exact CI build job and hadn't run the eclipse_warnings. I have now addressed above issue as well and have a CI job running that has passed the JDK8 build phase. > In-memory index and query path > -- > > Key: CASSANDRA-18058 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18058 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.x > > > An in-memory index using the in-memory trie structure introduced with > CASSANDRA-17240 along with a query path implementation to perform index > queries from the in-memory index. -- 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-18075) Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4) nodes during upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640808#comment-17640808
]
Brandon Williams commented on CASSANDRA-18075:
--
bq. Whenever we do not define storage_port and ssl_storage_port explicitly, it
takes the default value
I'm aware, but explicit is better than implicit, and if this is indeed a bug,
removing noise from the setup process is beneficial.
bq. Connection refused: /10.110.49.242:7000
I would focus on this node's config since clearly it is not binding 7000.
> Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4)
> nodes during upgrade
> -
>
> Key: CASSANDRA-18075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18075
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Priority: Normal
> Attachments: cassandra-env.sh_3114, cassandra-env.sh_404,
> cassandra.yaml_3114, cassandra.yaml_404, system.log_10.110.44.207
>
>
> We are testing upgrade from Cassandra 3.11.4 to 4.0.4 on our test cluster
> which is SSL enabled and facing an issue.
> Our cluster size is 3x3.
> {noformat}
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 94.27 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8104.43 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 104.23 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 99.33 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-de-393671-v001-yqlvf:~# nodetool describecluster
> Cluster Information:
> Name: abssl_dev
> Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
> DynamicEndPointSnitch: enabled
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> f68fbc0c-c9d6-3709-8075-c5a0d74192f2: [10.110.4.110,
> 10.110.44.220, 10.109.6.153, 10.109.45.8, 10.109.66.149, 10.110.49.242]
> {noformat}
> During the upgrade, we re-run the pipeline in which we get new server (with
> different IP) that will have Cassandra 4.0.4 binary.
> Disk '/data' (contains data files, commitlogs etc.) will get detached from
> the old server and get attached to the new server.
> This process works fine on non-SSL cluster but when we perform this on SSL
> cluster, new node stops communicating with the rest of the nodes.
> In this example, after upgrade, node 10.110.4.110 got replaced with new
> server with new IP 10.110.44.207.
> *Output from 3.11.4 node:*
> {noformat}
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# hostname -i
> 10.109.6.153
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# java -version
> openjdk version "1.8.0_322"
> OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06)
> OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# nodetool status
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 135.24 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8135.35 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 135.25 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> DN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 104.44 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16
[jira] [Updated] (CASSANDRA-18079) Log better message when nodetool commands can not get probe.getOwnershipWithPort()
[
https://issues.apache.org/jira/browse/CASSANDRA-18079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18079:
--
Labels: nodetool (was: )
> Log better message when nodetool commands can not get
> probe.getOwnershipWithPort()
> --
>
> Key: CASSANDRA-18079
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18079
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Stefan Miklosovic
>Priority: Normal
> Labels: nodetool
>
> When status, ring or describecluster odetool commands are executed while node
> which is queried is not fully bootstrapped / started, it can throw this
> exception:
> {code:java}
> cassandra_node_4 | error: No nodes present in the cluster. Has this node
> finished starting up?
> cassandra_node_4 | -- StackTrace --
> cassandra_node_4 | java.lang.RuntimeException: No nodes present in the
> cluster. Has this node finished starting up?
> cassandra_node_4 | at
> org.apache.cassandra.dht.Murmur3Partitioner.describeOwnership(Murmur3Partitioner.java:303)
> cassandra_node_4 | at
> org.apache.cassandra.service.StorageService.getOwnershipWithPort(StorageService.java:5751)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> cassandra_node_4 | at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> cassandra_node_4 | at
> jdk.internal.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> cassandra_node_4 | at
> java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
> cassandra_node_4 | at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:641)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
> cassandra_node_4 | at
> java.management/com.sun.jmx.remote.security.MBeanServerAccessController.getAttribute(MBeanServerAccessController.java:320)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1443)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
> cassandra_node_4 | at
> java.base/java.security.AccessController.doPrivileged(Native Method)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1406)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:637)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> cassandra_node_4 | at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
> cassandra_node_4 | at
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
> cassandra_node_4 | at
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
> cassandra_node_4 | at
> java.base/java.security.AccessController.doPrivileged(Native Method)
> cassandra_node_4 | at
> java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> cassandra_node_4 | at
> jav
[jira] [Created] (CASSANDRA-18079) Log better message when nodetool commands can not get probe.getOwnershipWithPort()
Stefan Miklosovic created CASSANDRA-18079:
-
Summary: Log better message when nodetool commands can not get
probe.getOwnershipWithPort()
Key: CASSANDRA-18079
URL: https://issues.apache.org/jira/browse/CASSANDRA-18079
Project: Cassandra
Issue Type: Improvement
Reporter: Stefan Miklosovic
When status, ring or describecluster odetool commands are executed while node
which is queried is not fully bootstrapped / started, it can throw this
exception:
{code:java}
cassandra_node_4 | error: No nodes present in the cluster. Has this node
finished starting up?
cassandra_node_4 | -- StackTrace --
cassandra_node_4 | java.lang.RuntimeException: No nodes present in the
cluster. Has this node finished starting up?
cassandra_node_4 | at
org.apache.cassandra.dht.Murmur3Partitioner.describeOwnership(Murmur3Partitioner.java:303)
cassandra_node_4 | at
org.apache.cassandra.service.StorageService.getOwnershipWithPort(StorageService.java:5751)
cassandra_node_4 | at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
cassandra_node_4 | at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
cassandra_node_4 | at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
cassandra_node_4 | at
java.base/java.lang.reflect.Method.invoke(Method.java:566)
cassandra_node_4 | at
sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
cassandra_node_4 | at
jdk.internal.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
cassandra_node_4 | at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
cassandra_node_4 | at
java.base/java.lang.reflect.Method.invoke(Method.java:566)
cassandra_node_4 | at
java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260)
cassandra_node_4 | at
java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
cassandra_node_4 | at
java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
cassandra_node_4 | at
java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
cassandra_node_4 | at
java.management/com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
cassandra_node_4 | at
java.management/com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
cassandra_node_4 | at
java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:641)
cassandra_node_4 | at
java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
cassandra_node_4 | at
java.management/com.sun.jmx.remote.security.MBeanServerAccessController.getAttribute(MBeanServerAccessController.java:320)
cassandra_node_4 | at
java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1443)
cassandra_node_4 | at
java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
cassandra_node_4 | at
java.base/java.security.AccessController.doPrivileged(Native Method)
cassandra_node_4 | at
java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1406)
cassandra_node_4 | at
java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:637)
cassandra_node_4 | at
java.base/jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
cassandra_node_4 | at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
cassandra_node_4 | at
java.base/java.lang.reflect.Method.invoke(Method.java:566)
cassandra_node_4 | at
java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
cassandra_node_4 | at
java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
cassandra_node_4 | at
java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
cassandra_node_4 | at
java.base/java.security.AccessController.doPrivileged(Native Method)
cassandra_node_4 | at
java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
cassandra_node_4 | at
java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
cassandra_node_4 | at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
cassandra_node_4 | at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
cassandra_node_4 | at
java.base/java.security.AccessController.doPrivileged(Native Metho
[jira] [Updated] (CASSANDRA-18079) Log better message when nodetool commands can not get probe.getOwnershipWithPort()
[
https://issues.apache.org/jira/browse/CASSANDRA-18079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18079:
--
Component/s: Legacy/Tools
> Log better message when nodetool commands can not get
> probe.getOwnershipWithPort()
> --
>
> Key: CASSANDRA-18079
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18079
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> When status, ring or describecluster odetool commands are executed while node
> which is queried is not fully bootstrapped / started, it can throw this
> exception:
> {code:java}
> cassandra_node_4 | error: No nodes present in the cluster. Has this node
> finished starting up?
> cassandra_node_4 | -- StackTrace --
> cassandra_node_4 | java.lang.RuntimeException: No nodes present in the
> cluster. Has this node finished starting up?
> cassandra_node_4 | at
> org.apache.cassandra.dht.Murmur3Partitioner.describeOwnership(Murmur3Partitioner.java:303)
> cassandra_node_4 | at
> org.apache.cassandra.service.StorageService.getOwnershipWithPort(StorageService.java:5751)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> cassandra_node_4 | at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> cassandra_node_4 | at
> jdk.internal.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> cassandra_node_4 | at
> java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
> cassandra_node_4 | at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:641)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
> cassandra_node_4 | at
> java.management/com.sun.jmx.remote.security.MBeanServerAccessController.getAttribute(MBeanServerAccessController.java:320)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1443)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
> cassandra_node_4 | at
> java.base/java.security.AccessController.doPrivileged(Native Method)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1406)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:637)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> cassandra_node_4 | at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
> cassandra_node_4 | at
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
> cassandra_node_4 | at
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
> cassandra_node_4 | at
> java.base/java.security.AccessController.doPrivileged(Native Method)
> cassandra_node_4 | at
> java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> cassandra_node_4 | at
> java.rmi/sun.rmi.transport.tcp.TCPT
[jira] [Updated] (CASSANDRA-18079) Log better message when nodetool commands can not get probe.getOwnershipWithPort()
[
https://issues.apache.org/jira/browse/CASSANDRA-18079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18079:
--
Description:
When status, ring or describecluster nodetool commands are executed while a
node which is queried is not fully bootstrapped / started, it can throw this
exception:
{code:java}
cassandra_node_4 | error: No nodes present in the cluster. Has this node
finished starting up?
cassandra_node_4 | -- StackTrace --
cassandra_node_4 | java.lang.RuntimeException: No nodes present in the
cluster. Has this node finished starting up?
cassandra_node_4 | at
org.apache.cassandra.dht.Murmur3Partitioner.describeOwnership(Murmur3Partitioner.java:303)
cassandra_node_4 | at
org.apache.cassandra.service.StorageService.getOwnershipWithPort(StorageService.java:5751)
cassandra_node_4 | at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
cassandra_node_4 | at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
cassandra_node_4 | at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
cassandra_node_4 | at
java.base/java.lang.reflect.Method.invoke(Method.java:566)
cassandra_node_4 | at
sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
cassandra_node_4 | at
jdk.internal.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
cassandra_node_4 | at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
cassandra_node_4 | at
java.base/java.lang.reflect.Method.invoke(Method.java:566)
cassandra_node_4 | at
java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260)
cassandra_node_4 | at
java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
cassandra_node_4 | at
java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
cassandra_node_4 | at
java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
cassandra_node_4 | at
java.management/com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
cassandra_node_4 | at
java.management/com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
cassandra_node_4 | at
java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:641)
cassandra_node_4 | at
java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
cassandra_node_4 | at
java.management/com.sun.jmx.remote.security.MBeanServerAccessController.getAttribute(MBeanServerAccessController.java:320)
cassandra_node_4 | at
java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1443)
cassandra_node_4 | at
java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
cassandra_node_4 | at
java.base/java.security.AccessController.doPrivileged(Native Method)
cassandra_node_4 | at
java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1406)
cassandra_node_4 | at
java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:637)
cassandra_node_4 | at
java.base/jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
cassandra_node_4 | at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
cassandra_node_4 | at
java.base/java.lang.reflect.Method.invoke(Method.java:566)
cassandra_node_4 | at
java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
cassandra_node_4 | at
java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
cassandra_node_4 | at
java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
cassandra_node_4 | at
java.base/java.security.AccessController.doPrivileged(Native Method)
cassandra_node_4 | at
java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
cassandra_node_4 | at
java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
cassandra_node_4 | at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
cassandra_node_4 | at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
cassandra_node_4 | at
java.base/java.security.AccessController.doPrivileged(Native Method)
cassandra_node_4 | at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:676)
cassandra_node_4 | at
java.base/java.util.concurren
[jira] [Commented] (CASSANDRA-17848) Fix incorrect resource name in LIST PERMISSION output
[
https://issues.apache.org/jira/browse/CASSANDRA-17848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640846#comment-17640846
]
Yifan Cai commented on CASSANDRA-17848:
---
[~bereng], you are right. Thank you for updating the ticket state! I will take
care of the CI runs.
> Fix incorrect resource name in LIST PERMISSION output
> -
>
> Key: CASSANDRA-17848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17848
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When producing the resource name, it seems to assume that the content in the
> `[]` is the function's input type, where it could also be part of the
> function name, as long as it is quoted. Here is an example to reproduce. In
> cqlsh,
> {code:java}
> > CREATE FUNCTION
> > test."admin_created_udf[org.apache.cassandra.db.marshal.LongType]"(input
> > int) RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE java AS 'return 42;';
> > LIST EXECUTE OF user;
> role | username | resource| permission
> ---+--+-+
> user |user | |EXECUTE
> (1 rows)
> {code}
> The input should be "int", but in the output, it says "long".
> If the content enclosed by "[]" is not a valid class, the LIST PERMISSION
> request always fails for the user with "ConfigurationException: Unable to
> find abstract-type class".
> The bug is discovered by Piotr Sarna.
--
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
[cassandra-website] branch asf-staging updated (af806a6f -> 6b9ee4b6)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git omit af806a6f generate docs for 0834e145 new 6b9ee4b6 generate docs for 0834e145 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (af806a6f) \ N -- N -- N refs/heads/asf-staging (6b9ee4b6) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4970139 -> 4970139 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18078) Consider removing MAXWRITETIME function
[
https://issues.apache.org/jira/browse/CASSANDRA-18078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640884#comment-17640884
]
Yifan Cai commented on CASSANDRA-18078:
---
Generally, I agree that we should remove the redundant function.
A nice property of 'maxwritetime' is that it works on both single cell and
multi-cell column. So client does not need to check the column type before
applying the function.
I will check out if 'collection_max' does the same.
> Consider removing MAXWRITETIME function
> ---
>
> Key: CASSANDRA-18078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18078
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CASSANDRA-17425 added a new {{MAXWRITETIME}} function that allows to retrieve
> the maximum timestamp of a multi-cell column. For example:
> {code:java}
> > CREATE TABLE t (k int PRIMARY KEY, v set);
> > INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> > UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> > SELECT maxwritetime(v) FROM t;
> maxwritetime(v)
> -
> 200
> {code}
> Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of
> each of the cells in a multi-cell column:
> {code:java}
> > SELECT writetime(v) FROM t;
> writetime(v)
> -
> [100, 100, 200]
> > SELECT writetime(v[1]) FROM t;
> writetime(v[1])
> -
> 100
> {code}
> Quite recently, CASSANDRA-18060 has added generic CQL functions to get the
> min and max items in a collection. Those functions can be used in combination
> with the classic {{writetime}} function to get the same results as the new
> {{maxwritetime}} function:
> {code:java}
> > SELECT collection_max(writetime(v)) FROM t;
> system.collection_max(writetime(v))
> -
> 200
> {code}
> Those new functions can also be used to get the min timestamp, or the min/max
> TTL, for which there isn't a specific function:
> {code:java}
> SELECT collection_min(writetime(v)) FROM t;
> SELECT collection_max(writetime(v)) FROM t;
> SELECT collection_avg(writetime(v)) FROM t;
> SELECT collection_min(ttl(v)) FROM t;
> SELECT collection_max(ttl(v)) FROM t;
> SELECT collection_avg(ttl(v)) FROM t;
> {code}
> I think this makes the new {{maxwritetime}} mostly redundant, since the new
> functions can achieve the same results in a more generic way. Since the new
> {{maxwritetime}} function is only on trunk, we should consider whether we
> want to remove it in favour of the generic functions.
--
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-17112) CEP-15: (C*) Strict Serializability verification
[ https://issues.apache.org/jira/browse/CASSANDRA-17112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17112: -- Change Category: Quality Assurance Complexity: Normal Fix Version/s: NA Status: Open (was: Triage Needed) > CEP-15: (C*) Strict Serializability verification > > > Key: CASSANDRA-17112 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17112 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: David Capwell >Priority: Normal > Fix For: NA > > -- 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] [Assigned] (CASSANDRA-17112) CEP-15: (C*) Strict Serializability verification
[ https://issues.apache.org/jira/browse/CASSANDRA-17112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell reassigned CASSANDRA-17112: - Assignee: David Capwell > CEP-15: (C*) Strict Serializability verification > > > Key: CASSANDRA-17112 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17112 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: David Capwell >Priority: Normal > -- 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-18078) Consider removing MAXWRITETIME function
[
https://issues.apache.org/jira/browse/CASSANDRA-18078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640884#comment-17640884
]
Yifan Cai edited comment on CASSANDRA-18078 at 11/29/22 6:26 PM:
-
Generally, I agree that we should remove the redundant function.
A nice property of 'maxwritetime' is that it works on both single cell and
multi-cell column. So client does not need to check the column type before
applying the function.
I will check out if 'collection_max' does the same.
---Update---
'collection _max' requires the input to be set or list as of now. See the
example below. If we can make 'collection_max' work with a single item(, which
can be considered as a singleton collection), then both functions are
equivalent and we can remove 'maxwritetime' in the favor of the generic
'collection_max'. WDYT?
{code:sql}
cqlsh> CREATE TABLE test.max_ts ( a int PRIMARY KEY, b int, c list );
cqlsh> INSERT INTO test.max_ts ( a, b, c ) VALUES ( 1, 1, [1, 2, 3] );
cqlsh> SELECT a, b, c, maxwritetime(b), maxwritetime(c),
collection_max(writetime(b)), collection_max(writetime(c)) FROM test.max_ts
WHERE a = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Function
system.collection_max requires a set or list argument, but found argument
writetime(b) of type bigint"
# Meanwhile, 'maxwritetime' works with both types.
cqlsh> SELECT a, b, c, maxwritetime(b), maxwritetime(c),
collection_max(writetime(c)) FROM test.max_ts WHERE a = 1;
a | b | c | maxwritetime(b) | maxwritetime(c) |
system.collection_max(writetime(c))
---+---+---+--+--+-
1 | 1 | [1, 2, 3] | 1669745997088534 | 1669745997088534 |
1669745997088534
(1 rows)
{code}
was (Author: yifanc):
Generally, I agree that we should remove the redundant function.
A nice property of 'maxwritetime' is that it works on both single cell and
multi-cell column. So client does not need to check the column type before
applying the function.
I will check out if 'collection_max' does the same.
> Consider removing MAXWRITETIME function
> ---
>
> Key: CASSANDRA-18078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18078
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CASSANDRA-17425 added a new {{MAXWRITETIME}} function that allows to retrieve
> the maximum timestamp of a multi-cell column. For example:
> {code:java}
> > CREATE TABLE t (k int PRIMARY KEY, v set);
> > INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> > UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> > SELECT maxwritetime(v) FROM t;
> maxwritetime(v)
> -
> 200
> {code}
> Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of
> each of the cells in a multi-cell column:
> {code:java}
> > SELECT writetime(v) FROM t;
> writetime(v)
> -
> [100, 100, 200]
> > SELECT writetime(v[1]) FROM t;
> writetime(v[1])
> -
> 100
> {code}
> Quite recently, CASSANDRA-18060 has added generic CQL functions to get the
> min and max items in a collection. Those functions can be used in combination
> with the classic {{writetime}} function to get the same results as the new
> {{maxwritetime}} function:
> {code:java}
> > SELECT collection_max(writetime(v)) FROM t;
> system.collection_max(writetime(v))
> -
> 200
> {code}
> Those new functions can also be used to get the min timestamp, or the min/max
> TTL, for which there isn't a specific function:
> {code:java}
> SELECT collection_min(writetime(v)) FROM t;
> SELECT collection_max(writetime(v)) FROM t;
> SELECT collection_avg(writetime(v)) FROM t;
> SELECT collection_min(ttl(v)) FROM t;
> SELECT collection_max(ttl(v)) FROM t;
> SELECT collection_avg(ttl(v)) FROM t;
> {code}
> I think this makes the new {{maxwritetime}} mostly redundant, since the new
> functions can achieve the same results in a more generic way. Since the new
> {{maxwritetime}} function is only on trunk, we should consider whether we
> want to remove it in favour of the generic functions.
--
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-18078) Consider removing MAXWRITETIME function
[
https://issues.apache.org/jira/browse/CASSANDRA-18078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640884#comment-17640884
]
Yifan Cai edited comment on CASSANDRA-18078 at 11/29/22 6:26 PM:
-
Generally, I agree that we should remove the redundant function.
A nice property of 'maxwritetime' is that it works on both single cell and
multi-cell column. So client does not need to check the column type before
applying the function.
I will check out if 'collection_max' does the same.
--- Update ---
'collection _max' requires the input to be set or list as of now. See the
example below. If we can make 'collection_max' work with a single item(, which
can be considered as a singleton collection), then both functions are
equivalent and we can remove 'maxwritetime' in the favor of the generic
'collection_max'. WDYT?
{code:sql}
cqlsh> CREATE TABLE test.max_ts ( a int PRIMARY KEY, b int, c list );
cqlsh> INSERT INTO test.max_ts ( a, b, c ) VALUES ( 1, 1, [1, 2, 3] );
cqlsh> SELECT a, b, c, maxwritetime(b), maxwritetime(c),
collection_max(writetime(b)), collection_max(writetime(c)) FROM test.max_ts
WHERE a = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Function
system.collection_max requires a set or list argument, but found argument
writetime(b) of type bigint"
# Meanwhile, 'maxwritetime' works with both types.
cqlsh> SELECT a, b, c, maxwritetime(b), maxwritetime(c),
collection_max(writetime(c)) FROM test.max_ts WHERE a = 1;
a | b | c | maxwritetime(b) | maxwritetime(c) |
system.collection_max(writetime(c))
---+---+---+--+--+-
1 | 1 | [1, 2, 3] | 1669745997088534 | 1669745997088534 |
1669745997088534
(1 rows)
{code}
was (Author: yifanc):
Generally, I agree that we should remove the redundant function.
A nice property of 'maxwritetime' is that it works on both single cell and
multi-cell column. So client does not need to check the column type before
applying the function.
I will check out if 'collection_max' does the same.
---Update---
'collection _max' requires the input to be set or list as of now. See the
example below. If we can make 'collection_max' work with a single item(, which
can be considered as a singleton collection), then both functions are
equivalent and we can remove 'maxwritetime' in the favor of the generic
'collection_max'. WDYT?
{code:sql}
cqlsh> CREATE TABLE test.max_ts ( a int PRIMARY KEY, b int, c list );
cqlsh> INSERT INTO test.max_ts ( a, b, c ) VALUES ( 1, 1, [1, 2, 3] );
cqlsh> SELECT a, b, c, maxwritetime(b), maxwritetime(c),
collection_max(writetime(b)), collection_max(writetime(c)) FROM test.max_ts
WHERE a = 1;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Function
system.collection_max requires a set or list argument, but found argument
writetime(b) of type bigint"
# Meanwhile, 'maxwritetime' works with both types.
cqlsh> SELECT a, b, c, maxwritetime(b), maxwritetime(c),
collection_max(writetime(c)) FROM test.max_ts WHERE a = 1;
a | b | c | maxwritetime(b) | maxwritetime(c) |
system.collection_max(writetime(c))
---+---+---+--+--+-
1 | 1 | [1, 2, 3] | 1669745997088534 | 1669745997088534 |
1669745997088534
(1 rows)
{code}
> Consider removing MAXWRITETIME function
> ---
>
> Key: CASSANDRA-18078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18078
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CASSANDRA-17425 added a new {{MAXWRITETIME}} function that allows to retrieve
> the maximum timestamp of a multi-cell column. For example:
> {code:java}
> > CREATE TABLE t (k int PRIMARY KEY, v set);
> > INSERT INTO t (k, v) VALUES (1, {1, 2}) USING TIMESTAMP 100;
> > UPDATE t USING TIMESTAMP 200 SET v += {3} WHERE k=1;
> > SELECT maxwritetime(v) FROM t;
> maxwritetime(v)
> -
> 200
> {code}
> Later, CASSANDRA-8877 added the means to retrieve the write times and TTLs of
> each of the cells in a multi-cell column:
> {code:java}
> > SELECT writetime(v) FROM t;
> writetime(v)
> -
> [100, 100, 200]
> > SELECT writetime(v[1]) FROM t;
> writetime(v[1])
> -
> 100
> {code}
> Quite recently, CASSANDRA-18060 has added generic CQL functions to get the
> min and max items in a collection. Those functions can be used in combination
> with the classic {{writetime}} function to get the same results as the new
> {{maxwritetime}} f
[jira] [Updated] (CASSANDRA-17998) Mutation Serialization Caching
[ https://issues.apache.org/jira/browse/CASSANDRA-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17998: -- Status: Changes Suggested (was: Review In Progress) > Mutation Serialization Caching > -- > > Key: CASSANDRA-17998 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17998 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: T Jake Luciani >Assignee: T Jake Luciani >Priority: Normal > Fix For: 4.x > > > A performance change that adds mutation serialization caching to avoid > re-serializing the mutation for commitlog and nodes twice. > * Cached serialization for storage proxy and local commitlog > * Cached deserialization for messaging service and local commitlog > This yields a non trivial perf gain (~7-10%) and latency drop (median) > [https://tjake.github.io/other/cached-mutations-report.html] > > The cached buffer is stored by MessagingService version to avoid being used > by differing nodes during upgrades. > Also, It avoids caching mutations larger than a threshold to avoid GC issues. > > GH PR: https://github.com/apache/cassandra/pull/1954 > -- 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-17998) Mutation Serialization Caching
[ https://issues.apache.org/jira/browse/CASSANDRA-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640934#comment-17640934 ] Josh McKenzie commented on CASSANDRA-17998: --- By "next couple of days" I meant 27. Comments left on the PR; looking solid! This is a pretty delicate section of the codebase so I'm of the opinion we should err on the side of being clear and explicit about intended usage of things as well as guardrail the objects from misuse so there's a decent chunk of that in the review + some javadoccing. Nothing major; some recommendations structurally to bring some of the class modifications and new classes into symmetry with their structure and usage paradigms. > Mutation Serialization Caching > -- > > Key: CASSANDRA-17998 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17998 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: T Jake Luciani >Assignee: T Jake Luciani >Priority: Normal > Fix For: 4.x > > > A performance change that adds mutation serialization caching to avoid > re-serializing the mutation for commitlog and nodes twice. > * Cached serialization for storage proxy and local commitlog > * Cached deserialization for messaging service and local commitlog > This yields a non trivial perf gain (~7-10%) and latency drop (median) > [https://tjake.github.io/other/cached-mutations-report.html] > > The cached buffer is stored by MessagingService version to avoid being used > by differing nodes during upgrades. > Also, It avoids caching mutations larger than a threshold to avoid GC issues. > > GH PR: https://github.com/apache/cassandra/pull/1954 > -- 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] [Assigned] (CASSANDRA-12525) When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default ca
[ https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-12525: Assignee: German Eichberger > When adding new nodes to a cluster which has authentication enabled, we end > up losing cassandra user's current crendentials and they get reverted back to > default cassandra/cassandra crendetials > - > > Key: CASSANDRA-12525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12525 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Atin Sood >Assignee: German Eichberger >Priority: Low > Time Spent: 10m > Remaining Estimate: 0h > > Made the following observation: > When adding new nodes to an existing C* cluster with authentication enabled > we end up loosing password information about `cassandra` user. > Initial Setup > - Create a 5 node cluster with system_auth having RF=5 and > NetworkTopologyStrategy > - Enable PasswordAuthenticator on this cluster and update the password for > 'cassandra' user to say 'password' via the alter query > - Make sure you run nodetool repair on all the nodes > Test case > - Now go ahead and add 5 more nodes to this cluster. > - Run nodetool repair on all the 10 nodes now > - Decommission the original 5 nodes such that only the new 5 nodes are in the > cluster now > - Run cqlsh and try to connect to this cluster using old user name and > password, cassandra/password > I was unable to connect to the nodes with the original credentials and was > only able to connect using the default cassandra/cassandra credentials > From the conversation over IIRC > `beobal: sood: that definitely shouldn't happen. The new nodes should only > create the default superuser role if there are 0 roles currently defined > (including that default one)` -- 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-12525) When adding new nodes to a cluster which has authentication enabled, we end up losing cassandra user's current crendentials and they get reverted back to default c
[ https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640951#comment-17640951 ] Brandon Williams commented on CASSANDRA-12525: -- Linking German's PR that [~mck] pointed me to, thanks! I think this approach makes sense, effectively making the automatic creation idempotent. WDYT, [~samt]? (I think we should still check the 4.0.5 bug described though.) > When adding new nodes to a cluster which has authentication enabled, we end > up losing cassandra user's current crendentials and they get reverted back to > default cassandra/cassandra crendetials > - > > Key: CASSANDRA-12525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12525 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Atin Sood >Assignee: German Eichberger >Priority: Low > Time Spent: 10m > Remaining Estimate: 0h > > Made the following observation: > When adding new nodes to an existing C* cluster with authentication enabled > we end up loosing password information about `cassandra` user. > Initial Setup > - Create a 5 node cluster with system_auth having RF=5 and > NetworkTopologyStrategy > - Enable PasswordAuthenticator on this cluster and update the password for > 'cassandra' user to say 'password' via the alter query > - Make sure you run nodetool repair on all the nodes > Test case > - Now go ahead and add 5 more nodes to this cluster. > - Run nodetool repair on all the 10 nodes now > - Decommission the original 5 nodes such that only the new 5 nodes are in the > cluster now > - Run cqlsh and try to connect to this cluster using old user name and > password, cassandra/password > I was unable to connect to the nodes with the original credentials and was > only able to connect using the default cassandra/cassandra credentials > From the conversation over IIRC > `beobal: sood: that definitely shouldn't happen. The new nodes should only > create the default superuser role if there are 0 roles currently defined > (including that default one)` -- 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-17719) CEP-15: Multi-Partition Transaction CQL Support v0.1
[
https://issues.apache.org/jira/browse/CASSANDRA-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17719:
Summary: CEP-15: Multi-Partition Transaction CQL Support v0.1 (was:
CEP-15: Multi-partition transaction CQL support)
> CEP-15: Multi-Partition Transaction CQL Support v0.1
>
>
> Key: CASSANDRA-17719
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17719
> Project: Cassandra
> Issue Type: New Feature
> Components: Accord, CQL/Syntax
>Reporter: Blake Eggleston
>Assignee: Caleb Rackliffe
>Priority: Normal
>
> The dev list thread regarding CQL transaction support seems to have converged
> on a syntax.
>
> The thread is here:
> [https://lists.apache.org/thread/5sds3968mnnk42c24pvgwphg4qvo2xk0]
>
> The message proposing the syntax ultimately agreed on is here:
> [https://lists.apache.org/thread/y289tczngj68bqpoo7gkso3bzmtf86pl]
>
> I'll describe my understanding of the agreed syntax here for, but I'd
> suggest reading through the thread.
>
> The example query is this:
> {code:sql}
> BEGIN TRANSACTION
> LET car = (SELECT miles_driven, is_running FROM cars WHERE model=’pinto’);
> LET user = (SELECT miles_driven FROM users WHERE name=’Blake’);
> SELECT car.is_running, car.miles_driven;
> IF car.is_running THEN
> UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
> UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
> END IF
> COMMIT TRANSACTION
> {code}
> Sections are described below, and we want to require the statement enforces
> an order on the different types of clauses. First, assignments, then
> select(s), then conditional updates. This may be relaxed in the future, but
> is meant to prevent users from interleaving updates and assignments and
> expecting read your own write behavior that we don't want to support in v1.
> h3. Reference assignments
> {code:sql}
> LET car = (SELECT miles_driven, is_running FROM cars WHERE
> model=’pinto’){code}
>
> The first part is basically assigning the result of a SELECT statement to a
> named reference that can be used in updates/conditions and be returned to the
> user. Tuple names belong to a global scope and must not clash with other LET
> statements or update statements (more on that in the updates section). Also,
> the select statement must either be a point read, with all primary key
> columns defined, or explicitly set a limit of 1.
> h3. Selection
> Data to returned to client. Currently, we're only supporting a single select
> statement. Either a normal select statement, or one returning values assigned
> by LET statements as shown in the example. Ultimately we'll want to support
> multiple select statements and returning the results to the client. Although
> that will require a protocol change.
> h3. Updates
> Normal inserts/updates/deletes with the following extensions:
> * Inserts and updates can reference values assigned earlier in the statement
> * Updates can reference their own columns:
> {code:java}
> miles_driven = miles_driven + 30{code}
> - or -
> {code:java}
> miles_driven += 30{code}
> These will of course need to generate any required reads behind the scenes.
> There's no precedence of table vs reference names, so if a relevant column
> name and reference name conflict, the query needs to fail to parse.
> h3. If blocks
> {code:sql}
> IF THEN
> ;
> ;
> END IF
> {code}
>
> For v1, we only need to support a single condition in the format above. In
> the future, we'd like to support multiple branches with multiple conditions
> like:
>
> {code:sql}
> IF THEN
> ;
> ;
> ELSE IF THEN
> ;
> ELSE
> ;
> END IF
> {code}
>
> h3. Conditions
> Comparisons of value references to literals or other references. IS NULL / IS
> NOT NULL also needs to be supported. Multiple comparisons need to be
> supported, but v1 only needs to support AND'ing them together.
> {code:java}
> Supported operators: =, !=, >, >=, <, <=, IS NULL, IS NOT NULL
> = 5
> IS NOT NULL
> IF car IS NOT NULL AND car.miles_driven > 30
> IF car.miles_driven = user.miles_driven{code}
> (Note that {{IS[ NOT ]NULL}} can apply to both tuple references and
> individually dereferenced columns.)
> CONTAINS and CONTAINS KEY require indexed collections, and will not be
> supported in v1.
> h3. Implementation notes
> I have a proof of concept I'd created to demo the initially proposed syntax
> here: [https://github.com/bdeggleston/cassandra/tree/accord-cql-poc], It
> could be used as a starting point, a source of ideas for approaches, or not
> used at all. The main thing to keep in mind is that value references prevent
> creating read commands and mutations until later in the transacti
[jira] [Commented] (CASSANDRA-18023) Add option to print level with getsstables output
[ https://issues.apache.org/jira/browse/CASSANDRA-18023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640967#comment-17640967 ] Jordan West commented on CASSANDRA-18023: - Pushed a fix. Test runs linked below. The failing tests are related to describe which I don't think would be affected by this patch. New test runs: [j8|https://app.circleci.com/pipelines/github/jrwest/cassandra/115/workflows/603d5ca4-8f6a-49af-9dea-f95759d31f1c] [j11|https://app.circleci.com/pipelines/github/jrwest/cassandra/115/workflows/ba9ed183-1ff0-4630-a5ef-87636f3d6b2b] > Add option to print level with getsstables output > - > > Key: CASSANDRA-18023 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18023 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > > A common operation is to pipe getsstables output to sstablemetadata to > determine the level. This adds friction to operations. Add an optional flag > to getsstables to print the level with data file path. -- 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-17918) DESCRIBE output does not quote column names using reserved keywords
[
https://issues.apache.org/jira/browse/CASSANDRA-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640986#comment-17640986
]
Yifan Cai commented on CASSANDRA-17918:
---
+1 on the patch to trunk. We will need an additional patch for cassandra-4.1
branch :|
> DESCRIBE output does not quote column names using reserved keywords
> ---
>
> Key: CASSANDRA-17918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17918
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> The DESCRIBE output of the column names that using reserved keywords are not
> quoted for UDTs. The following test reproduces. Reading the code, it looks
> like that the such columns names are not quoted in materialized view, UDF and
> user defined aggregation.
> The impact of the bug is that schema described cannot be imported due to the
> usage of reserved keywords as column names.
>
> {code:java}
> @Test
> public void testUsingReservedInCreateType() throws Throwable
> {
> String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s
> (\"token\" text, \"desc\" text);");
> assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
> row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
> KEYSPACE_PER_TEST + "." + type + " (\n" +
> " \"token\" text,\n" +
> " \"desc\" text\n" +
> ");"));
> } {code}
> +Additional information for newcomers:+
> * Unit tests for DESCRIBE statements are in {{DescribeStatementTest}}
> * The statement implementation is in {{DescribeStatement and fetch the
> create statement from the different schema element using
> SchemaElement.toCqlString}}
--
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-17848) Fix incorrect resource name in LIST PERMISSION output
[
https://issues.apache.org/jira/browse/CASSANDRA-17848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640266#comment-17640266
]
Yifan Cai edited comment on CASSANDRA-17848 at 11/30/22 12:03 AM:
--
||Branch||Source||Circle CI||
|cassandra-3.0|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17848-cassandra-3.0-CC2B132A-B8D3-4BFC-9DCC-56A4CEABCA33]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-cassandra-3.0-CC2B132A-B8D3-4BFC-9DCC-56A4CEABCA33]|
|cassandra-3.11|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17848-cassandra-3.11-CC2B132A-B8D3-4BFC-9DCC-56A4CEABCA33]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-cassandra-3.11-CC2B132A-B8D3-4BFC-9DCC-56A4CEABCA33]|
|cassandra-4.0|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17848-cassandra-4.0-CC2B132A-B8D3-4BFC-9DCC-56A4CEABCA33]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-cassandra-4.0-CC2B132A-B8D3-4BFC-9DCC-56A4CEABCA33]|
|cassandra-4.1|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17848-cassandra-4.1-CC2B132A-B8D3-4BFC-9DCC-56A4CEABCA33]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-cassandra-4.1-CC2B132A-B8D3-4BFC-9DCC-56A4CEABCA33]|
|trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17848-trunk-CC2B132A-B8D3-4BFC-9DCC-56A4CEABCA33]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-trunk-CC2B132A-B8D3-4BFC-9DCC-56A4CEABCA33]|
was (Author: yifanc):
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||
|cassandra-3.0|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17848-cassandra-3.0-0BEEE733-4B08-4382-971F-77727647709C]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-cassandra-3.0-0BEEE733-4B08-4382-971F-77727647709C]|
|cassandra-3.11|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17848-cassandra-3.11-0BEEE733-4B08-4382-971F-77727647709C]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-cassandra-3.11-0BEEE733-4B08-4382-971F-77727647709C]|
|cassandra-4.0|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17848-cassandra-4.0-0BEEE733-4B08-4382-971F-77727647709C]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-cassandra-4.0-0BEEE733-4B08-4382-971F-77727647709C]|
|cassandra-4.1|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17848-cassandra-4.1-0BEEE733-4B08-4382-971F-77727647709C]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-cassandra-4.1-0BEEE733-4B08-4382-971F-77727647709C]|
|trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17848-trunk-0BEEE733-4B08-4382-971F-77727647709C]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-trunk-0BEEE733-4B08-4382-971F-77727647709C]|
> Fix incorrect resource name in LIST PERMISSION output
> -
>
> Key: CASSANDRA-17848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17848
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When producing the resource name, it seems to assume that the content in the
> `[]` is the function's input type, where it could also be part of the
> function name, as long as it is quoted. Here is an example to reproduce. In
> cqlsh,
> {code:java}
> > CREATE FUNCTION
> > test."admin_created_udf[org.apache.cassandra.db.marshal.LongType]"(input
> > int) RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE java AS 'return 42;';
> > LIST EXECUTE OF user;
> role | username | resource| permission
> ---+--+-+
> user |user | |EXECUTE
> (1 rows)
> {code}
> The input should be "int", but in the output, it says "long".
> If the content enclosed by "[]" is not a valid class, the LIST PERMISSION
> request always fails for the user with "Configurati
[jira] [Created] (CASSANDRA-18080) BLOG - Summit 2023 registrations open
Erick Ramirez created CASSANDRA-18080: - Summary: BLOG - Summit 2023 registrations open Key: CASSANDRA-18080 URL: https://issues.apache.org/jira/browse/CASSANDRA-18080 Project: Cassandra Issue Type: Task Reporter: Erick Ramirez Assignee: Erick Ramirez Announcing registrations open for the 2023 Apache Cassandra Summit. Blog draft - https://docs.google.com/document/d/1eX_4bu0DnQ_henIxN0BRQ_2R4j5xADlAkGYGozsGB-Q/edit -- 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-18080) BLOG - Summit 2023 registrations open
[ https://issues.apache.org/jira/browse/CASSANDRA-18080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-18080: -- Change Category: Semantic Complexity: Normal Component/s: Documentation/Blog Fix Version/s: NA Status: Open (was: Triage Needed) > BLOG - Summit 2023 registrations open > - > > Key: CASSANDRA-18080 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18080 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Fix For: NA > > > Announcing registrations open for the 2023 Apache Cassandra Summit. > Blog draft - > https://docs.google.com/document/d/1eX_4bu0DnQ_henIxN0BRQ_2R4j5xADlAkGYGozsGB-Q/edit -- 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-18080) BLOG - Summit 2023 registrations open
[ https://issues.apache.org/jira/browse/CASSANDRA-18080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-18080: -- Authors: Chris Thornett, Erick Ramirez (was: Erick Ramirez) > BLOG - Summit 2023 registrations open > - > > Key: CASSANDRA-18080 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18080 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Fix For: NA > > > Announcing registrations open for the 2023 Apache Cassandra Summit. > Blog draft - > https://docs.google.com/document/d/1eX_4bu0DnQ_henIxN0BRQ_2R4j5xADlAkGYGozsGB-Q/edit -- 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-17918) DESCRIBE output does not quote column names using reserved keywords
[
https://issues.apache.org/jira/browse/CASSANDRA-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17641010#comment-17641010
]
Bernardo Botella Corbi commented on CASSANDRA-17918:
Here are the patches for the 3 branches:
||Branch||PR||
|trunk|[PR|https://github.com/apache/cassandra/pull/1907]|
|4.0|[PR|https://github.com/apache/cassandra/pull/2035]|
|4.1|[PR|https://github.com/apache/cassandra/pull/2034]|
> DESCRIBE output does not quote column names using reserved keywords
> ---
>
> Key: CASSANDRA-17918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17918
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> The DESCRIBE output of the column names that using reserved keywords are not
> quoted for UDTs. The following test reproduces. Reading the code, it looks
> like that the such columns names are not quoted in materialized view, UDF and
> user defined aggregation.
> The impact of the bug is that schema described cannot be imported due to the
> usage of reserved keywords as column names.
>
> {code:java}
> @Test
> public void testUsingReservedInCreateType() throws Throwable
> {
> String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s
> (\"token\" text, \"desc\" text);");
> assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
> row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
> KEYSPACE_PER_TEST + "." + type + " (\n" +
> " \"token\" text,\n" +
> " \"desc\" text\n" +
> ");"));
> } {code}
> +Additional information for newcomers:+
> * Unit tests for DESCRIBE statements are in {{DescribeStatementTest}}
> * The statement implementation is in {{DescribeStatement and fetch the
> create statement from the different schema element using
> SchemaElement.toCqlString}}
--
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-17112) CEP-15: (C*) Strict Serializability verification
[ https://issues.apache.org/jira/browse/CASSANDRA-17112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17641012#comment-17641012 ] David Capwell commented on CASSANDRA-17112: --- started to look into this by looking into what we do today, and what Accord does > CEP-15: (C*) Strict Serializability verification > > > Key: CASSANDRA-17112 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17112 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: David Capwell >Priority: Normal > Fix For: NA > > -- 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-17254) nodetool toppartitions can fail because ByteBuffer.array() returns more bytes than would be considered valid by UTF8Serializer.validate
[
https://issues.apache.org/jira/browse/CASSANDRA-17254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West updated CASSANDRA-17254:
Status: Ready to Commit (was: Review In Progress)
> nodetool toppartitions can fail because ByteBuffer.array() returns more bytes
> than would be considered valid by UTF8Serializer.validate
> ---
>
> Key: CASSANDRA-17254
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17254
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 3.0.x
>
>
> The error below is caused by the use of
> [{{ByteBuffer.array()}}|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L1628].
> Doing so not only makes the hex key potentially incorrect but causes invalid
> data to be passed to {{AbstractType.getString}} and ultimately
> {{UTF8Validator.validate}}.
> {code}
> error: String didn't validate.
> -- StackTrace --
> org.apache.cassandra.serializers.MarshalException: String didn't validate.
> at
> org.apache.cassandra.serializers.UTF8Serializer.validate(UTF8Serializer.java:35)
> at
> org.apache.cassandra.db.marshal.AbstractType.getString(AbstractType.java:129)
> at
> org.apache.cassandra.db.ColumnFamilyStore.finishLocalSampling(ColumnFamilyStore.java:1633)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
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
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. jwest pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 13654332fe4f8da4124d29454afbe5d3cab59fee Merge: b7c7972a51 cc4c8a3637 Author: Jordan West AuthorDate: Tue Nov 29 18:32:25 2022 -0800 Merge branch 'cassandra-4.1' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (d9ef794ef6 -> 13d495aa7d)
This is an automated email from the ASF dual-hosted git repository. jwest pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from d9ef794ef6 Upgrade Cython, minimum required now is 0.27.2 add 13d495aa7d fix intermittent failures in nodetool toppartitions caused by failure to validate invalid bytes No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + src/java/org/apache/cassandra/db/ColumnFamilyStore.java | 12 +++- 2 files changed, 8 insertions(+), 5 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (1df8174d67 -> bba7ab3eca)
This is an automated email from the ASF dual-hosted git repository. jwest pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 1df8174d67 Cqlshlib tests are j11 greedy add 13d495aa7d fix intermittent failures in nodetool toppartitions caused by failure to validate invalid bytes add 5a53c36515 Merge branch 'cassandra-3.0' into cassandra-3.11 add bba7ab3eca Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (7572725def -> 5a53c36515)
This is an automated email from the ASF dual-hosted git repository. jwest pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 7572725def [CASSANDRA-17950] Enable dtest-offheap in CircleCI add 13d495aa7d fix intermittent failures in nodetool toppartitions caused by failure to validate invalid bytes add 5a53c36515 Merge branch 'cassandra-3.0' into cassandra-3.11 No new revisions were added by this update. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (b807f97b37 -> cc4c8a3637)
This is an automated email from the ASF dual-hosted git repository. jwest pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from b807f97b37 Prepare debian changelog for 4.1.0 add 13d495aa7d fix intermittent failures in nodetool toppartitions caused by failure to validate invalid bytes add 5a53c36515 Merge branch 'cassandra-3.0' into cassandra-3.11 add bba7ab3eca Merge branch 'cassandra-3.11' into cassandra-4.0 add cc4c8a3637 Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (b7c7972a51 -> 13654332fe)
This is an automated email from the ASF dual-hosted git repository. jwest pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from b7c7972a51 Add CQL scalar functions for collection aggregation add 13d495aa7d fix intermittent failures in nodetool toppartitions caused by failure to validate invalid bytes add 5a53c36515 Merge branch 'cassandra-3.0' into cassandra-3.11 add bba7ab3eca Merge branch 'cassandra-3.11' into cassandra-4.0 add cc4c8a3637 Merge branch 'cassandra-4.0' into cassandra-4.1 new 13654332fe Merge branch 'cassandra-4.1' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17254) nodetool toppartitions can fail because ByteBuffer.array() returns more bytes than would be considered valid by UTF8Serializer.validate
[
https://issues.apache.org/jira/browse/CASSANDRA-17254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West updated CASSANDRA-17254:
Since Version: 3.0.29
Source Control Link:
https://github.com/apache/cassandra/commit/13d495aa7d5b7a7c121fcc9e105f79107c5c2a1c
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Commited as
https://github.com/apache/cassandra/commit/13d495aa7d5b7a7c121fcc9e105f79107c5c2a1c
> nodetool toppartitions can fail because ByteBuffer.array() returns more bytes
> than would be considered valid by UTF8Serializer.validate
> ---
>
> Key: CASSANDRA-17254
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17254
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 3.0.x
>
>
> The error below is caused by the use of
> [{{ByteBuffer.array()}}|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L1628].
> Doing so not only makes the hex key potentially incorrect but causes invalid
> data to be passed to {{AbstractType.getString}} and ultimately
> {{UTF8Validator.validate}}.
> {code}
> error: String didn't validate.
> -- StackTrace --
> org.apache.cassandra.serializers.MarshalException: String didn't validate.
> at
> org.apache.cassandra.serializers.UTF8Serializer.validate(UTF8Serializer.java:35)
> at
> org.apache.cassandra.db.marshal.AbstractType.getString(AbstractType.java:129)
> at
> org.apache.cassandra.db.ColumnFamilyStore.finishLocalSampling(ColumnFamilyStore.java:1633)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
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-17848) Fix incorrect resource name in LIST PERMISSION output
[
https://issues.apache.org/jira/browse/CASSANDRA-17848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17641065#comment-17641065
]
Yifan Cai commented on CASSANDRA-17848:
---
The CI runs of cssandra-4.1 and trunk based branches show green result.
The runs of the other branches have failures. Some of them are flaky, and some
of them also appear in the Jenkins build results (on
https://ci-cassandra.apache.org).
All of the failures are not related with the changes added in this patch. Other
pairs of eyes will appreciated!
Regarding the changes, on the 4.x branches, they are identical. They are simply
cherry-picked from the commits in the patch against trunk.
On the 3.x branches, minimal change was made to check the functions names
during `prepare` of the statements, instead of in the `apply` method in the
trunk patch. I'd consider the commits are also identical to the original one.
cc: [~bereng]
> Fix incorrect resource name in LIST PERMISSION output
> -
>
> Key: CASSANDRA-17848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17848
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When producing the resource name, it seems to assume that the content in the
> `[]` is the function's input type, where it could also be part of the
> function name, as long as it is quoted. Here is an example to reproduce. In
> cqlsh,
> {code:java}
> > CREATE FUNCTION
> > test."admin_created_udf[org.apache.cassandra.db.marshal.LongType]"(input
> > int) RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE java AS 'return 42;';
> > LIST EXECUTE OF user;
> role | username | resource| permission
> ---+--+-+
> user |user | |EXECUTE
> (1 rows)
> {code}
> The input should be "int", but in the output, it says "long".
> If the content enclosed by "[]" is not a valid class, the LIST PERMISSION
> request always fails for the user with "ConfigurationException: Unable to
> find abstract-type class".
> The bug is discovered by Piotr Sarna.
--
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-18075) Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4) nodes during upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alaykumar Barochia updated CASSANDRA-18075:
---
Attachment: cassandra.yaml_10.110.49.242_explicitely_set_port
> Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4)
> nodes during upgrade
> -
>
> Key: CASSANDRA-18075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18075
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Priority: Normal
> Attachments: cassandra-env.sh_3114, cassandra-env.sh_404,
> cassandra.yaml_10.110.44.207_explicitely_set_port,
> cassandra.yaml_10.110.49.242_explicitely_set_port, cassandra.yaml_3114,
> cassandra.yaml_404, system.log_10.110.44.207,
> system.log_10.110.44.207_after_explicitely_set_port
>
>
> We are testing upgrade from Cassandra 3.11.4 to 4.0.4 on our test cluster
> which is SSL enabled and facing an issue.
> Our cluster size is 3x3.
> {noformat}
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 94.27 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8104.43 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 104.23 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 99.33 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-de-393671-v001-yqlvf:~# nodetool describecluster
> Cluster Information:
> Name: abssl_dev
> Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
> DynamicEndPointSnitch: enabled
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> f68fbc0c-c9d6-3709-8075-c5a0d74192f2: [10.110.4.110,
> 10.110.44.220, 10.109.6.153, 10.109.45.8, 10.109.66.149, 10.110.49.242]
> {noformat}
> During the upgrade, we re-run the pipeline in which we get new server (with
> different IP) that will have Cassandra 4.0.4 binary.
> Disk '/data' (contains data files, commitlogs etc.) will get detached from
> the old server and get attached to the new server.
> This process works fine on non-SSL cluster but when we perform this on SSL
> cluster, new node stops communicating with the rest of the nodes.
> In this example, after upgrade, node 10.110.4.110 got replaced with new
> server with new IP 10.110.44.207.
> *Output from 3.11.4 node:*
> {noformat}
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# hostname -i
> 10.109.6.153
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# java -version
> openjdk version "1.8.0_322"
> OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06)
> OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# nodetool status
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 135.24 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8135.35 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 135.25 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> DN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 104.44 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# nodetool describecluster
> Cluster Information:
> Name: abssl_
[jira] [Updated] (CASSANDRA-18075) Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4) nodes during upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alaykumar Barochia updated CASSANDRA-18075:
---
Attachment: system.log_10.110.44.207_after_explicitely_set_port
> Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4)
> nodes during upgrade
> -
>
> Key: CASSANDRA-18075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18075
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Priority: Normal
> Attachments: cassandra-env.sh_3114, cassandra-env.sh_404,
> cassandra.yaml_10.110.44.207_explicitely_set_port,
> cassandra.yaml_10.110.49.242_explicitely_set_port, cassandra.yaml_3114,
> cassandra.yaml_404, system.log_10.110.44.207,
> system.log_10.110.44.207_after_explicitely_set_port
>
>
> We are testing upgrade from Cassandra 3.11.4 to 4.0.4 on our test cluster
> which is SSL enabled and facing an issue.
> Our cluster size is 3x3.
> {noformat}
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 94.27 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8104.43 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 104.23 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 99.33 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-de-393671-v001-yqlvf:~# nodetool describecluster
> Cluster Information:
> Name: abssl_dev
> Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
> DynamicEndPointSnitch: enabled
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> f68fbc0c-c9d6-3709-8075-c5a0d74192f2: [10.110.4.110,
> 10.110.44.220, 10.109.6.153, 10.109.45.8, 10.109.66.149, 10.110.49.242]
> {noformat}
> During the upgrade, we re-run the pipeline in which we get new server (with
> different IP) that will have Cassandra 4.0.4 binary.
> Disk '/data' (contains data files, commitlogs etc.) will get detached from
> the old server and get attached to the new server.
> This process works fine on non-SSL cluster but when we perform this on SSL
> cluster, new node stops communicating with the rest of the nodes.
> In this example, after upgrade, node 10.110.4.110 got replaced with new
> server with new IP 10.110.44.207.
> *Output from 3.11.4 node:*
> {noformat}
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# hostname -i
> 10.109.6.153
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# java -version
> openjdk version "1.8.0_322"
> OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06)
> OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# nodetool status
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 135.24 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8135.35 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 135.25 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> DN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 104.44 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# nodetool describecluster
> Cluster Information:
> Name: abss
[jira] [Updated] (CASSANDRA-18075) Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4) nodes during upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alaykumar Barochia updated CASSANDRA-18075:
---
Attachment: cassandra.yaml_10.110.44.207_explicitely_set_port
> Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4)
> nodes during upgrade
> -
>
> Key: CASSANDRA-18075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18075
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Priority: Normal
> Attachments: cassandra-env.sh_3114, cassandra-env.sh_404,
> cassandra.yaml_10.110.44.207_explicitely_set_port,
> cassandra.yaml_10.110.49.242_explicitely_set_port, cassandra.yaml_3114,
> cassandra.yaml_404, system.log_10.110.44.207,
> system.log_10.110.44.207_after_explicitely_set_port
>
>
> We are testing upgrade from Cassandra 3.11.4 to 4.0.4 on our test cluster
> which is SSL enabled and facing an issue.
> Our cluster size is 3x3.
> {noformat}
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 94.27 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8104.43 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 104.23 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 99.33 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-de-393671-v001-yqlvf:~# nodetool describecluster
> Cluster Information:
> Name: abssl_dev
> Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
> DynamicEndPointSnitch: enabled
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> f68fbc0c-c9d6-3709-8075-c5a0d74192f2: [10.110.4.110,
> 10.110.44.220, 10.109.6.153, 10.109.45.8, 10.109.66.149, 10.110.49.242]
> {noformat}
> During the upgrade, we re-run the pipeline in which we get new server (with
> different IP) that will have Cassandra 4.0.4 binary.
> Disk '/data' (contains data files, commitlogs etc.) will get detached from
> the old server and get attached to the new server.
> This process works fine on non-SSL cluster but when we perform this on SSL
> cluster, new node stops communicating with the rest of the nodes.
> In this example, after upgrade, node 10.110.4.110 got replaced with new
> server with new IP 10.110.44.207.
> *Output from 3.11.4 node:*
> {noformat}
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# hostname -i
> 10.109.6.153
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# java -version
> openjdk version "1.8.0_322"
> OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06)
> OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# nodetool status
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 135.24 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8135.35 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 135.25 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> DN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 104.44 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# nodetool describecluster
> Cluster Information:
> Name: abssl_
[jira] [Updated] (CASSANDRA-18075) Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4) nodes during upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alaykumar Barochia updated CASSANDRA-18075:
---
Attachment: system.log_10.110.49.242_after_explicitely_set_port
> Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4)
> nodes during upgrade
> -
>
> Key: CASSANDRA-18075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18075
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Priority: Normal
> Attachments: cassandra-env.sh_3114, cassandra-env.sh_404,
> cassandra.yaml_10.110.44.207_explicitely_set_port,
> cassandra.yaml_10.110.49.242_explicitely_set_port, cassandra.yaml_3114,
> cassandra.yaml_404, system.log_10.110.44.207,
> system.log_10.110.44.207_after_explicitely_set_port,
> system.log_10.110.49.242_after_explicitely_set_port
>
>
> We are testing upgrade from Cassandra 3.11.4 to 4.0.4 on our test cluster
> which is SSL enabled and facing an issue.
> Our cluster size is 3x3.
> {noformat}
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 94.27 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8104.43 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 104.23 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 99.33 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-de-393671-v001-yqlvf:~# nodetool describecluster
> Cluster Information:
> Name: abssl_dev
> Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
> DynamicEndPointSnitch: enabled
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> f68fbc0c-c9d6-3709-8075-c5a0d74192f2: [10.110.4.110,
> 10.110.44.220, 10.109.6.153, 10.109.45.8, 10.109.66.149, 10.110.49.242]
> {noformat}
> During the upgrade, we re-run the pipeline in which we get new server (with
> different IP) that will have Cassandra 4.0.4 binary.
> Disk '/data' (contains data files, commitlogs etc.) will get detached from
> the old server and get attached to the new server.
> This process works fine on non-SSL cluster but when we perform this on SSL
> cluster, new node stops communicating with the rest of the nodes.
> In this example, after upgrade, node 10.110.4.110 got replaced with new
> server with new IP 10.110.44.207.
> *Output from 3.11.4 node:*
> {noformat}
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# hostname -i
> 10.109.6.153
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# java -version
> openjdk version "1.8.0_322"
> OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06)
> OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# nodetool status
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 135.24 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8135.35 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 135.25 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> DN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 104.44 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# nodetool d
[jira] [Commented] (CASSANDRA-18075) Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4) nodes during upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17641075#comment-17641075
]
Alaykumar Barochia commented on CASSANDRA-18075:
Performed below steps:
(1) Explicitely set 'storage_port' and 'ssl_storage_port' in cassandra.yaml
file on all C* 3.11.4 nodes (10.110.44.220, 10.110.49.242, 10.109.66.149,
10.109.45.8, 10.109.6.153) and restart cassandra service.
(2) Explicitely set 'storage_port' and 'ssl_storage_port' in cassandra.yaml
file on 10.110.44.207 (C* 4.0.4) and restart cassandra service.
Still getting the same error on C* 4 node 10.110.44.207.
Uploaded cassandra.yaml and system.log files for your review.
[^cassandra.yaml_10.110.44.207_explicitely_set_port]
[^cassandra.yaml_10.110.49.242_explicitely_set_port]
[^system.log_10.110.44.207_after_explicitely_set_port]
[^system.log_10.110.49.242_after_explicitely_set_port]
To me, it looks like, because we are getting new IP during the upgrade is
causing this issue. But as I said earlier, we are not getting this issue on
non-SSL cluster, only SSL cluster is causing this issue. So, something is going
wrong (probably a bug) with SSL cluster communication during the upgrade
process whenever we get new IP during the upgrade process.
> Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4)
> nodes during upgrade
> -
>
> Key: CASSANDRA-18075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18075
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Priority: Normal
> Attachments: cassandra-env.sh_3114, cassandra-env.sh_404,
> cassandra.yaml_10.110.44.207_explicitely_set_port,
> cassandra.yaml_10.110.49.242_explicitely_set_port, cassandra.yaml_3114,
> cassandra.yaml_404, system.log_10.110.44.207,
> system.log_10.110.44.207_after_explicitely_set_port,
> system.log_10.110.49.242_after_explicitely_set_port
>
>
> We are testing upgrade from Cassandra 3.11.4 to 4.0.4 on our test cluster
> which is SSL enabled and facing an issue.
> Our cluster size is 3x3.
> {noformat}
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 94.27 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8104.43 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 104.23 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 99.33 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-de-393671-v001-yqlvf:~# nodetool describecluster
> Cluster Information:
> Name: abssl_dev
> Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
> DynamicEndPointSnitch: enabled
> Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
> Schema versions:
> f68fbc0c-c9d6-3709-8075-c5a0d74192f2: [10.110.4.110,
> 10.110.44.220, 10.109.6.153, 10.109.45.8, 10.109.66.149, 10.110.49.242]
> {noformat}
> During the upgrade, we re-run the pipeline in which we get new server (with
> different IP) that will have Cassandra 4.0.4 binary.
> Disk '/data' (contains data files, commitlogs etc.) will get detached from
> the old server and get attached to the new server.
> This process works fine on non-SSL cluster but when we perform this on SSL
> cluster, new node stops communicating with the rest of the nodes.
> In this example, after upgrade, node 10.110.4.110 got replaced with new
> server with new IP 10.110.44.207.
> *Output from 3.11.4 node:*
> {noformat}
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# hostname -i
> 10.109.6.153
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# java -version
> openjdk version "1.8.0_322"
> OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06)
> OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# nodetool status
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving
[jira] [Updated] (CASSANDRA-18080) BLOG - Summit 2023 registrations open
[ https://issues.apache.org/jira/browse/CASSANDRA-18080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-18080: -- Attachment: c18080-02-blog-post.png c18080-01-blog-index.png > BLOG - Summit 2023 registrations open > - > > Key: CASSANDRA-18080 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18080 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Fix For: NA > > Attachments: c18080-01-blog-index.png, c18080-02-blog-post.png > > > Announcing registrations open for the 2023 Apache Cassandra Summit. > Blog draft - > https://docs.google.com/document/d/1eX_4bu0DnQ_henIxN0BRQ_2R4j5xADlAkGYGozsGB-Q/edit -- 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-18080) BLOG - Summit 2023 registrations open
[
https://issues.apache.org/jira/browse/CASSANDRA-18080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18080:
--
Test and Documentation Plan: Stage locally and verify that blog post
renders as expected
Status: Patch Available (was: Open)
Patch:
||Branch||PR||
|{{trunk}}|[#198|https://github.com/apache/cassandra-website/pull/198]
!c18080-01-blog-index.png|width=300!
!c18080-02-blog-post.png|width=300!
> BLOG - Summit 2023 registrations open
> -
>
> Key: CASSANDRA-18080
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18080
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18080-01-blog-index.png, c18080-02-blog-post.png
>
>
> Announcing registrations open for the 2023 Apache Cassandra Summit.
> Blog draft -
> https://docs.google.com/document/d/1eX_4bu0DnQ_henIxN0BRQ_2R4j5xADlAkGYGozsGB-Q/edit
--
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-17848) Fix incorrect resource name in LIST PERMISSION output
[
https://issues.apache.org/jira/browse/CASSANDRA-17848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17641110#comment-17641110
]
Berenguer Blasi commented on CASSANDRA-17848:
-
[~yifanc] 4.0 looks fishy I wouldn't expect so many failures at all. It's quite
a stable branch and failures don't align at all with jenkins. Would it be ok to
re-run or re-check all is ok? Also, why your circle runs don't show the
'pre-commit' and 'separate' group of tests the std circle files have? Otherwise
I'd have to checked no test has been missed.
> Fix incorrect resource name in LIST PERMISSION output
> -
>
> Key: CASSANDRA-17848
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17848
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When producing the resource name, it seems to assume that the content in the
> `[]` is the function's input type, where it could also be part of the
> function name, as long as it is quoted. Here is an example to reproduce. In
> cqlsh,
> {code:java}
> > CREATE FUNCTION
> > test."admin_created_udf[org.apache.cassandra.db.marshal.LongType]"(input
> > int) RETURNS NULL ON NULL INPUT RETURNS int LANGUAGE java AS 'return 42;';
> > LIST EXECUTE OF user;
> role | username | resource| permission
> ---+--+-+
> user |user | |EXECUTE
> (1 rows)
> {code}
> The input should be "int", but in the output, it says "long".
> If the content enclosed by "[]" is not a valid class, the LIST PERMISSION
> request always fails for the user with "ConfigurationException: Unable to
> find abstract-type class".
> The bug is discovered by Piotr Sarna.
--
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
[cassandra-website] branch asf-staging updated (6b9ee4b6 -> e5d329b5)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 6b9ee4b6 generate docs for 0834e145 new e5d329b5 generate docs for 0834e145 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (6b9ee4b6) \ N -- N -- N refs/heads/asf-staging (e5d329b5) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4970139 -> 4970139 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18079) Log better message when nodetool commands can not get probe.getOwnershipWithPort()
[
https://issues.apache.org/jira/browse/CASSANDRA-18079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18079:
--
Labels: lhf nodetool (was: nodetool)
> Log better message when nodetool commands can not get
> probe.getOwnershipWithPort()
> --
>
> Key: CASSANDRA-18079
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18079
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Stefan Miklosovic
>Priority: Normal
> Labels: lhf, nodetool
>
> When status, ring or describecluster nodetool commands are executed while a
> node which is queried is not fully bootstrapped / started, it can throw this
> exception:
> {code:java}
> cassandra_node_4 | error: No nodes present in the cluster. Has this node
> finished starting up?
> cassandra_node_4 | -- StackTrace --
> cassandra_node_4 | java.lang.RuntimeException: No nodes present in the
> cluster. Has this node finished starting up?
> cassandra_node_4 | at
> org.apache.cassandra.dht.Murmur3Partitioner.describeOwnership(Murmur3Partitioner.java:303)
> cassandra_node_4 | at
> org.apache.cassandra.service.StorageService.getOwnershipWithPort(StorageService.java:5751)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> cassandra_node_4 | at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> cassandra_node_4 | at
> jdk.internal.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> cassandra_node_4 | at
> java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
> cassandra_node_4 | at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:641)
> cassandra_node_4 | at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
> cassandra_node_4 | at
> java.management/com.sun.jmx.remote.security.MBeanServerAccessController.getAttribute(MBeanServerAccessController.java:320)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1443)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
> cassandra_node_4 | at
> java.base/java.security.AccessController.doPrivileged(Native Method)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1406)
> cassandra_node_4 | at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:637)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> cassandra_node_4 | at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> cassandra_node_4 | at
> java.base/java.lang.reflect.Method.invoke(Method.java:566)
> cassandra_node_4 | at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
> cassandra_node_4 | at
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
> cassandra_node_4 | at
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
> cassandra_node_4 | at
> java.base/java.security.AccessController.doPrivileged(Native Method)
> cassandra_node_4 | at
> java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> cassandra_n
