[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=17640416#comment-17640416
]
Berenguer Blasi commented on CASSANDRA-17848:
-
[~yifanc] I moved it back to 'review in progress'. AFAIK we only move it to
'ready to commit' once we have reviewed all branches, all CI is green and you
get the +1 for all branches.
Regarding the circle runs it seems sthg went wrong failing most of your 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
>
>
> 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-17848) Fix incorrect resource name in LIST PERMISSION output
[
https://issues.apache.org/jira/browse/CASSANDRA-17848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17848:
Status: Patch Available (was: Ready to Commit)
> 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
>
>
> 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-17848) Fix incorrect resource name in LIST PERMISSION output
[
https://issues.apache.org/jira/browse/CASSANDRA-17848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17848:
Reviewers: Berenguer Blasi, Sam Tunnicliffe, Berenguer Blasi (was:
Berenguer Blasi, Sam Tunnicliffe)
Berenguer Blasi, Sam Tunnicliffe, Berenguer Blasi (was:
Berenguer Blasi, Sam Tunnicliffe)
Status: Review In Progress (was: Patch Available)
> 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
>
>
> 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] [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=17640381#comment-17640381
]
Alaykumar Barochia edited comment on CASSANDRA-18075 at 11/29/22 4:55 AM:
--
[~brandon.williams] - I know about this parameter and have set it to {{true}}
in my C*4 cassandra.yaml file.
{noformat}
server_encryption_options:
internode_encryption: all
enable_legacy_ssl_storage_port: true
keystore: /data/conf/keystore
keystore_password:
truststore: /data/conf/truststore
truststore_password:
{noformat}
You can verify the same in the attached file {{cassandra.yaml_404}}.
Is there anything else I am missing here?
was (Author: abarochia):
[~brandon.williams] - I know about this parameter and have set it to {{true}}
in my C*4 cassandra.yaml file.
{noformat}
server_encryption_options:
internode_encryption: all
enable_legacy_ssl_storage_port: true
keystore: /data/conf/keystore
keystore_password:
truststore: /data/conf/truststore
truststore_password:
{noformat}
You can verify the same in the attached file {{cassandra.yaml_404}}.
> 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
[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=17640381#comment-17640381
]
Alaykumar Barochia commented on CASSANDRA-18075:
[~brandon.williams] - I know about this parameter and have set it to {{true}}
in my C*4 cassandra.yaml file.
{noformat}
server_encryption_options:
internode_encryption: all
enable_legacy_ssl_storage_port: true
keystore: /data/conf/keystore
keystore_password:
truststore: /data/conf/truststore
truststore_password:
{noformat}
You can verify the same in the attached file {{cassandra.yaml_404}}.
> 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%
> f1dc35c
[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:
--
Test and Documentation Plan: Stage locally and verify that the new post
renders as expected
Status: Patch Available (was: Open)
Patch:
||Branch||PR||
|{{trunk}}|[#197|https://github.com/apache/cassandra-website/pull/197]|
!c18076-01-blog-index.png|width=300!
!c18076-02-blog-post.png|width=300!
> 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 ] Erick Ramirez updated CASSANDRA-18076: -- Attachment: c18076-02-blog-post.png c18076-01-blog-index.png > 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 ] Erick Ramirez updated CASSANDRA-18076: -- Description: [~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! was: [~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 > 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 > > > [~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! -- 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 ] Erick Ramirez updated CASSANDRA-18076: -- Description: [~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! was: [~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! > 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 > > > [~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-17178) CEP-10: Simulator Java11 Support
[ https://issues.apache.org/jira/browse/CASSANDRA-17178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640316#comment-17640316 ] David Capwell commented on CASSANDRA-17178: --- Got +1 from Benedict, waiting on Ekaterina > CEP-10: Simulator Java11 Support > > > Key: CASSANDRA-17178 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17178 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Benedict Elliott Smith >Assignee: David Capwell >Priority: Normal > Fix For: NA > > > Java11 introduces new protection domains for package private methods, so that > classes loaded with different class loaders may not access each others’ > package private methods, regardless of the package they are declared within. > There are differences within the JDK also, and there may be byte weaving > targets that need updating (ThreadLocalRandom was one that has been handled) -- 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-17178) CEP-10: Simulator Java11 Support
[ https://issues.apache.org/jira/browse/CASSANDRA-17178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17178: -- Reviewers: Benedict Elliott Smith Status: Review In Progress (was: Patch Available) > CEP-10: Simulator Java11 Support > > > Key: CASSANDRA-17178 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17178 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Benedict Elliott Smith >Assignee: David Capwell >Priority: Normal > Fix For: NA > > > Java11 introduces new protection domains for package private methods, so that > classes loaded with different class loaders may not access each others’ > package private methods, regardless of the package they are declared within. > There are differences within the JDK also, and there may be byte weaving > targets that need updating (ThreadLocalRandom was one that has been handled) -- 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/28/22 11:37 PM:
--
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]|
was (Author: yifanc):
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||
|cassandra-3.0|[branch|https://github.com/yifan_cai/cassandra/tree/commit_remote_branch/CASSANDRA-17848-cassandra-3.0-0BEEE733-4B08-4382-971F-77727647709C]|[build|https://app.circleci.com/pipelines/github/yifan_cai/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-cassandra-3.0-0BEEE733-4B08-4382-971F-77727647709C]|
|cassandra-3.11|[branch|https://github.com/yifan_cai/cassandra/tree/commit_remote_branch/CASSANDRA-17848-cassandra-3.11-0BEEE733-4B08-4382-971F-77727647709C]|[build|https://app.circleci.com/pipelines/github/yifan_cai/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-cassandra-3.11-0BEEE733-4B08-4382-971F-77727647709C]|
|cassandra-4.0|[branch|https://github.com/yifan_cai/cassandra/tree/commit_remote_branch/CASSANDRA-17848-cassandra-4.0-0BEEE733-4B08-4382-971F-77727647709C]|[build|https://app.circleci.com/pipelines/github/yifan_cai/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-cassandra-4.0-0BEEE733-4B08-4382-971F-77727647709C]|
|cassandra-4.1|[branch|https://github.com/yifan_cai/cassandra/tree/commit_remote_branch/CASSANDRA-17848-cassandra-4.1-0BEEE733-4B08-4382-971F-77727647709C]|[build|https://app.circleci.com/pipelines/github/yifan_cai/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-cassandra-4.1-0BEEE733-4B08-4382-971F-77727647709C]|
|trunk|[branch|https://github.com/yifan_cai/cassandra/tree/commit_remote_branch/CASSANDRA-17848-trunk-0BEEE733-4B08-4382-971F-77727647709C]|[build|https://app.circleci.com/pipelines/github/yifan_cai/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
>
>
> 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 "Co
[jira] [Updated] (CASSANDRA-18077) Add SpotBugs to the build
[ https://issues.apache.org/jira/browse/CASSANDRA-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18077: -- Attachment: spotbugs.html > Add SpotBugs to the build > - > > Key: CASSANDRA-18077 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18077 > Project: Cassandra > Issue Type: Improvement > Components: Build, CI >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > Attachments: spotbugs.html > > > When working on CASSANDRA-17178 I found that several classes were being > reported by the Simulator for not defining serializer version when they are > Serializable; this may cause issues for the Simulator so felt it would be > best to detect these earlier on before merging new ones. > SpotBugs has a large set of checks, some more valuable than others for the > project; so we should maintain a curated list of issues to fail the build on, > and others to warn on. > This topic was discussed in the following mail threads: > * Should we add?: > https://lists.apache.org/thread/1ro1mvkpvt4vr24nw7dbpdlxo82mq3hz > * Should we fix UTF-8 issues? > https://lists.apache.org/thread/sokxf46s7hyoxr9q4wm7dv3q2nm19nt3 -- 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-18077) Add SpotBugs to the build
[ https://issues.apache.org/jira/browse/CASSANDRA-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640297#comment-17640297 ] David Capwell edited comment on CASSANDRA-18077 at 11/28/22 11:31 PM: -- [~e.dimitrova] [~mck] would you mind reviewing? Currently the new tasks fail as more bugs are detected, I wanted to get feedback before going too far as the patch was already large to deal with. Attached a sample result from trunk: https://issues.apache.org/jira/secure/attachment/13053250/spotbugs.html was (Author: dcapwell): [~e.dimitrova] [~mck] would you mind reviewing? Currently the new tasks fail as more bugs are detected, I wanted to get feedback before going too far as the patch was already large to deal with. > Add SpotBugs to the build > - > > Key: CASSANDRA-18077 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18077 > Project: Cassandra > Issue Type: Improvement > Components: Build, CI >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > Attachments: spotbugs.html > > > When working on CASSANDRA-17178 I found that several classes were being > reported by the Simulator for not defining serializer version when they are > Serializable; this may cause issues for the Simulator so felt it would be > best to detect these earlier on before merging new ones. > SpotBugs has a large set of checks, some more valuable than others for the > project; so we should maintain a curated list of issues to fail the build on, > and others to warn on. > This topic was discussed in the following mail threads: > * Should we add?: > https://lists.apache.org/thread/1ro1mvkpvt4vr24nw7dbpdlxo82mq3hz > * Should we fix UTF-8 issues? > https://lists.apache.org/thread/sokxf46s7hyoxr9q4wm7dv3q2nm19nt3 -- 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-18077) Add SpotBugs to the build
[ https://issues.apache.org/jira/browse/CASSANDRA-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640297#comment-17640297 ] David Capwell commented on CASSANDRA-18077: --- [~e.dimitrova] [~mck] would you mind reviewing? Currently the new tasks fail as more bugs are detected, I wanted to get feedback before going too far as the patch was already large to deal with. > Add SpotBugs to the build > - > > Key: CASSANDRA-18077 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18077 > Project: Cassandra > Issue Type: Improvement > Components: Build, CI >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > > When working on CASSANDRA-17178 I found that several classes were being > reported by the Simulator for not defining serializer version when they are > Serializable; this may cause issues for the Simulator so felt it would be > best to detect these earlier on before merging new ones. > SpotBugs has a large set of checks, some more valuable than others for the > project; so we should maintain a curated list of issues to fail the build on, > and others to warn on. > This topic was discussed in the following mail threads: > * Should we add?: > https://lists.apache.org/thread/1ro1mvkpvt4vr24nw7dbpdlxo82mq3hz > * Should we fix UTF-8 issues? > https://lists.apache.org/thread/sokxf46s7hyoxr9q4wm7dv3q2nm19nt3 -- 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-18077) Add SpotBugs to the build
[ https://issues.apache.org/jira/browse/CASSANDRA-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18077: -- Test and Documentation Plan: added new task Status: Patch Available (was: Open) > Add SpotBugs to the build > - > > Key: CASSANDRA-18077 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18077 > Project: Cassandra > Issue Type: Improvement > Components: Build, CI >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > > When working on CASSANDRA-17178 I found that several classes were being > reported by the Simulator for not defining serializer version when they are > Serializable; this may cause issues for the Simulator so felt it would be > best to detect these earlier on before merging new ones. > SpotBugs has a large set of checks, some more valuable than others for the > project; so we should maintain a curated list of issues to fail the build on, > and others to warn on. > This topic was discussed in the following mail threads: > * Should we add?: > https://lists.apache.org/thread/1ro1mvkpvt4vr24nw7dbpdlxo82mq3hz > * Should we fix UTF-8 issues? > https://lists.apache.org/thread/sokxf46s7hyoxr9q4wm7dv3q2nm19nt3 -- 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-18077) Add SpotBugs to the build
[ https://issues.apache.org/jira/browse/CASSANDRA-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640284#comment-17640284 ] David Capwell commented on CASSANDRA-18077: --- There was a request from Mick to follow https://github.com/apache/cassandra/compare/cassandra-4.1...thelastpickle:cassandra:mck/buildfiles-linter-docs/4.1, posting here to make sure feedback is not lost > Add SpotBugs to the build > - > > Key: CASSANDRA-18077 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18077 > Project: Cassandra > Issue Type: Improvement > Components: Build, CI >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > > When working on CASSANDRA-17178 I found that several classes were being > reported by the Simulator for not defining serializer version when they are > Serializable; this may cause issues for the Simulator so felt it would be > best to detect these earlier on before merging new ones. > SpotBugs has a large set of checks, some more valuable than others for the > project; so we should maintain a curated list of issues to fail the build on, > and others to warn on. > This topic was discussed in the following mail threads: > * Should we add?: > https://lists.apache.org/thread/1ro1mvkpvt4vr24nw7dbpdlxo82mq3hz > * Should we fix UTF-8 issues? > https://lists.apache.org/thread/sokxf46s7hyoxr9q4wm7dv3q2nm19nt3 -- 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-18077) Add SpotBugs to the build
[ https://issues.apache.org/jira/browse/CASSANDRA-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18077: -- Description: When working on CASSANDRA-17178 I found that several classes were being reported by the Simulator for not defining serializer version when they are Serializable; this may cause issues for the Simulator so felt it would be best to detect these earlier on before merging new ones. SpotBugs has a large set of checks, some more valuable than others for the project; so we should maintain a curated list of issues to fail the build on, and others to warn on. This topic was discussed in the following mail threads: * Should we add?: https://lists.apache.org/thread/1ro1mvkpvt4vr24nw7dbpdlxo82mq3hz * Should we fix UTF-8 issues? https://lists.apache.org/thread/sokxf46s7hyoxr9q4wm7dv3q2nm19nt3 was: When working on CASSANDRA-17178 I found that several classes were being reported by the Simulator for not defining serializer version when they are Serializable; this may cause issues for the Simulator so felt it would be best to detect these earlier on before merging new ones. SpotBugs has a large set of checks, some more valuable than others for the project; so we should maintain a curated list of issues to fail the build on, and others to warn on. > Add SpotBugs to the build > - > > Key: CASSANDRA-18077 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18077 > Project: Cassandra > Issue Type: Improvement > Components: Build, CI >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > > When working on CASSANDRA-17178 I found that several classes were being > reported by the Simulator for not defining serializer version when they are > Serializable; this may cause issues for the Simulator so felt it would be > best to detect these earlier on before merging new ones. > SpotBugs has a large set of checks, some more valuable than others for the > project; so we should maintain a curated list of issues to fail the build on, > and others to warn on. > This topic was discussed in the following mail threads: > * Should we add?: > https://lists.apache.org/thread/1ro1mvkpvt4vr24nw7dbpdlxo82mq3hz > * Should we fix UTF-8 issues? > https://lists.apache.org/thread/sokxf46s7hyoxr9q4wm7dv3q2nm19nt3 -- 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-18077) Add SpotBugs to the build
[ https://issues.apache.org/jira/browse/CASSANDRA-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell reassigned CASSANDRA-18077: - Assignee: David Capwell > Add SpotBugs to the build > - > > Key: CASSANDRA-18077 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18077 > Project: Cassandra > Issue Type: Improvement > Components: Build, CI >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: NA > > > When working on CASSANDRA-17178 I found that several classes were being > reported by the Simulator for not defining serializer version when they are > Serializable; this may cause issues for the Simulator so felt it would be > best to detect these earlier on before merging new ones. > SpotBugs has a large set of checks, some more valuable than others for the > project; so we should maintain a curated list of issues to fail the build on, > and others to warn on. -- 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-18077) Add SpotBugs to the build
[ https://issues.apache.org/jira/browse/CASSANDRA-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18077: -- Change Category: Quality Assurance Complexity: Low Hanging Fruit Fix Version/s: NA Status: Open (was: Triage Needed) > Add SpotBugs to the build > - > > Key: CASSANDRA-18077 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18077 > Project: Cassandra > Issue Type: Improvement > Components: Build, CI >Reporter: David Capwell >Priority: Normal > Fix For: NA > > > When working on CASSANDRA-17178 I found that several classes were being > reported by the Simulator for not defining serializer version when they are > Serializable; this may cause issues for the Simulator so felt it would be > best to detect these earlier on before merging new ones. > SpotBugs has a large set of checks, some more valuable than others for the > project; so we should maintain a curated list of issues to fail the build on, > and others to warn on. -- 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-18064) WEBSITE - Add new contributor instruction for provisioning a Jira account
[
https://issues.apache.org/jira/browse/CASSANDRA-18064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640276#comment-17640276
]
Erick Ramirez commented on CASSANDRA-18064:
---
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 6bbc42ab generate docs for 59cc0422
$ git push -f origin asf-site
Total 0 (delta 0), reused 0 (delta 0)
To [https://github.com/apache/cassandra-website.git]
+ 6af2846a...6bbc42ab asf-site -> asf-site (forced update)
{noformat}
The updated pages are now live on the site –
*
[https://cassandra.apache.org/_/bugs.html|https://cassandra.staged.apache.org/_/bugs.html]
* [https://cassandra.apache.org/_/development/index.html]
* [https://cassandra.apache.org/_/development/patches.html]
* [https://cassandra.apache.org/_/community.html#how-to-contribute]
> WEBSITE - Add new contributor instruction for provisioning a Jira account
> -
>
> Key: CASSANDRA-18064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18064
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18064-01-reporting_bugs.png,
> c18064-02-contributing.png, c18064-03-patches.png, c18064-04-community.png
>
>
> In an effort to curb spam tickets, there is a new process that new ASF
> contributors must follow in order to get a Jira account provisioned. Here is
> an extract of the email announcement from the Infrastructure team:
> {quote}As I'm sure most of you are aware, the spam issues on Jira are getting
> worse. We are seeing spam user creation of over 10,000 accounts per year, and
> receive many requests per month from project members for help addressing spam
> complaints. Infra is taking steps to disable public Jira signups.
> Infra has developed a self-service tool by which folks on a PMC can request a
> Jira account for non-ASF contributors...
> {quote}
> The instruction needs to be added to the following pages:
> * [Contributing to
> Cassandra|https://cassandra.apache.org/_/development/index.html] page
> * [Contributing Code
> Changes|https://cassandra.apache.org/_/development/patches.html] (Patches)
> page
> * [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
> * *Reporting Bugs* section of the
> [Community|https://cassandra.apache.org/_/community.html#how-to-contribute]
> page
--
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-18077) Add SpotBugs to the build
David Capwell created CASSANDRA-18077: - Summary: Add SpotBugs to the build Key: CASSANDRA-18077 URL: https://issues.apache.org/jira/browse/CASSANDRA-18077 Project: Cassandra Issue Type: Improvement Components: Build, CI Reporter: David Capwell When working on CASSANDRA-17178 I found that several classes were being reported by the Simulator for not defining serializer version when they are Serializable; this may cause issues for the Simulator so felt it would be best to detect these earlier on before merging new ones. SpotBugs has a large set of checks, some more valuable than others for the project; so we should maintain a curated list of issues to fail the build on, and others to warn on. -- 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 (6af2846a -> 6bbc42ab)
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 6af2846a generate docs for 9b5fa3b6 add 59cc0422 WEBSITE - Added instruction for requesting JIRA account add 6bbc42ab generate docs for 59cc0422 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 (6af2846a) \ N -- N -- N refs/heads/asf-site (6bbc42ab) 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/_/bugs.html| 3 + content/_/community.html | 3 + content/_/development/gettingstarted.html | 3 + content/_/development/index.html | 6 + content/_/development/patches.html | 3 + content/doc/4.1/cassandra/architecture/dynamo.html | 44 +- .../doc/4.1/cassandra/architecture/guarantees.html | 44 +- content/doc/4.1/cassandra/architecture/index.html | 44 +- .../doc/4.1/cassandra/architecture/messaging.html | 53 ++- .../doc/4.1/cassandra/architecture/overview.html | 44 +- content/doc/4.1/cassandra/architecture/snitch.html | 44 +- .../4.1/cassandra/architecture/storage_engine.html | 44 +- .../doc/4.1/cassandra/architecture/streaming.html | 53 ++- .../configuration/cass_cl_archive_file.html| 44 +- .../cassandra/configuration/cass_env_sh_file.html | 44 +- .../configuration/cass_jvm_options_file.html | 44 +- .../configuration/cass_logback_xml_file.html | 44 +- .../cassandra/configuration/cass_rackdc_file.html | 44 +- .../cassandra/configuration/cass_topo_file.html| 44 +- .../cassandra/configuration/cass_yaml_file.html| 44 +- .../4.1/cassandra/configuration/configuration.html | 51 ++- content/doc/4.1/cassandra/configuration/index.html | 44 +- content/doc/4.1/cassandra/cql/SASI.html| 44 +- content/doc/4.1/cassandra/cql/appendices.html | 44 +- content/doc/4.1/cassandra/cql/changes.html | 44 +- content/doc/4.1/cassandra/cql/cql_singlefile.html | 44 +- content/doc/4.1/cassandra/cql/ddl.html | 44 +- content/doc/4.1/cassandra/cql/definitions.html | 44 +- content/doc/4.1/cassandra/cql/dml.html | 44 +- content/doc/4.1/cassandra/cql/functions.html | 44 +- content/doc/4.1/cassandra/cql/index.html | 44 +- content/doc/4.1/cassandra/cql/indexes.html | 44 +- content/doc/4.1/cassandra/cql/json.html| 44 +- content/doc/4.1/cassandra/cql/mvs.html | 44 +- content/doc/4.1/cassandra/cql/operators.html | 44 +- content/doc/4.1/cassandra/cql/security.html| 44 +- content/doc/4.1/cassandra/cql/triggers.html| 44 +- content/doc/4.1/cassandra/cql/types.html | 44 +- .../data_modeling/data_modeling_conceptual.html| 44 +- .../data_modeling/data_modeling_logical.html | 44 +- .../data_modeling/data_modeling_physical.html | 44 +- .../data_modeling/data_modeling_queries.html | 44 +- .../data_modeling/data_modeling_rdbms.html | 44 +- .../data_modeling/data_modeling_refining.html | 44 +- .../data_modeling/data_modeling_schema.html| 44 +- .../data_modeling/data_modeling_tools.html | 44 +- content/doc/4.1/cassandra/data_modeling/index.html | 44 +- content/doc/4.1/cassandra/data_modeling/intro.html | 44 +- content/doc/4.1/cassandra/faq/index.html | 44 +- .../4.1/cassandra/getting_started/configuring.html | 44 +- .../doc/4.1/cassandra/getting_started/drivers.html | 44 +- .../doc/4.1/cassandra/getting_started/index.html | 44 +- .../4.1/cassandra/getting_started/installing.html | 44 +- .../doc/4.1/cassandra/getting_started/java11.html | 51 ++- .../4.1/cassandra/getting_started/production.html | 44 +- .../4.1/cassandra/getting_started/querying.html| 44 +- .../4.1/cassandra/getting_started/quickstart.html | 44 +- content/doc/4.1/cassandra/new/index.html | 44 +- content/doc/4.1/cassandra/new/virtualtables.html | 44 +- .../doc/4.1/cassandra/operating/audit_logging.html | 46 +-
[jira] [Commented] (CASSANDRA-18064) WEBSITE - Add new contributor instruction for provisioning a Jira account
[
https://issues.apache.org/jira/browse/CASSANDRA-18064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640275#comment-17640275
]
Erick Ramirez commented on CASSANDRA-18064:
---
The build completed in 15 minutes and the updated pages are now in staging:
* [https://cassandra.staged.apache.org/_/development/index.html]
* [https://cassandra.staged.apache.org/_/development/patches.html]
* [https://cassandra.staged.apache.org/_/bugs.html]
* [https://cassandra.staged.apache.org/_/community.html#how-to-contribute]
> WEBSITE - Add new contributor instruction for provisioning a Jira account
> -
>
> Key: CASSANDRA-18064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18064
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18064-01-reporting_bugs.png,
> c18064-02-contributing.png, c18064-03-patches.png, c18064-04-community.png
>
>
> In an effort to curb spam tickets, there is a new process that new ASF
> contributors must follow in order to get a Jira account provisioned. Here is
> an extract of the email announcement from the Infrastructure team:
> {quote}As I'm sure most of you are aware, the spam issues on Jira are getting
> worse. We are seeing spam user creation of over 10,000 accounts per year, and
> receive many requests per month from project members for help addressing spam
> complaints. Infra is taking steps to disable public Jira signups.
> Infra has developed a self-service tool by which folks on a PMC can request a
> Jira account for non-ASF contributors...
> {quote}
> The instruction needs to be added to the following pages:
> * [Contributing to
> Cassandra|https://cassandra.apache.org/_/development/index.html] page
> * [Contributing Code
> Changes|https://cassandra.apache.org/_/development/patches.html] (Patches)
> page
> * [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
> * *Reporting Bugs* section of the
> [Community|https://cassandra.apache.org/_/community.html#how-to-contribute]
> page
--
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-17848) Fix incorrect resource name in LIST PERMISSION output
[
https://issues.apache.org/jira/browse/CASSANDRA-17848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-17848:
--
Fix Version/s: 3.0.29
3.11.15
4.0.8
4.1.1
4.2
Since Version: 3.0.0
> 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
>
>
> 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-17848) Fix incorrect resource name in LIST PERMISSION output
[
https://issues.apache.org/jira/browse/CASSANDRA-17848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-17848:
--
Status: Ready to Commit (was: Review In Progress)
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||
|cassandra-3.0|[branch|https://github.com/yifan_cai/cassandra/tree/commit_remote_branch/CASSANDRA-17848-cassandra-3.0-0BEEE733-4B08-4382-971F-77727647709C]|[build|https://app.circleci.com/pipelines/github/yifan_cai/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-cassandra-3.0-0BEEE733-4B08-4382-971F-77727647709C]|
|cassandra-3.11|[branch|https://github.com/yifan_cai/cassandra/tree/commit_remote_branch/CASSANDRA-17848-cassandra-3.11-0BEEE733-4B08-4382-971F-77727647709C]|[build|https://app.circleci.com/pipelines/github/yifan_cai/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-cassandra-3.11-0BEEE733-4B08-4382-971F-77727647709C]|
|cassandra-4.0|[branch|https://github.com/yifan_cai/cassandra/tree/commit_remote_branch/CASSANDRA-17848-cassandra-4.0-0BEEE733-4B08-4382-971F-77727647709C]|[build|https://app.circleci.com/pipelines/github/yifan_cai/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-cassandra-4.0-0BEEE733-4B08-4382-971F-77727647709C]|
|cassandra-4.1|[branch|https://github.com/yifan_cai/cassandra/tree/commit_remote_branch/CASSANDRA-17848-cassandra-4.1-0BEEE733-4B08-4382-971F-77727647709C]|[build|https://app.circleci.com/pipelines/github/yifan_cai/cassandra?branch=commit_remote_branch%2FCASSANDRA-17848-cassandra-4.1-0BEEE733-4B08-4382-971F-77727647709C]|
|trunk|[branch|https://github.com/yifan_cai/cassandra/tree/commit_remote_branch/CASSANDRA-17848-trunk-0BEEE733-4B08-4382-971F-77727647709C]|[build|https://app.circleci.com/pipelines/github/yifan_cai/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
>
> 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 (91ed6029 -> 6bbc42ab)
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 91ed6029 generate docs for 9b5fa3b6 add 59cc0422 WEBSITE - Added instruction for requesting JIRA account new 6bbc42ab generate docs for 59cc0422 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 (91ed6029) \ N -- N -- N refs/heads/asf-staging (6bbc42ab) 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/_/bugs.html| 3 +++ content/_/community.html | 3 +++ content/_/development/gettingstarted.html | 3 +++ content/_/development/index.html | 6 ++ content/_/development/patches.html | 3 +++ content/search-index.js| 2 +- site-content/source/modules/ROOT/pages/bugs.adoc | 2 ++ .../source/modules/ROOT/pages/community.adoc | 2 ++ .../ROOT/pages/development/gettingstarted.adoc | 2 ++ .../modules/ROOT/pages/development/patches.adoc| 2 ++ site-ui/build/ui-bundle.zip| Bin 4970139 -> 4970139 bytes 11 files changed, 27 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18064) WEBSITE - Add new contributor instruction for provisioning a Jira account
[
https://issues.apache.org/jira/browse/CASSANDRA-18064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640262#comment-17640262
]
Erick Ramirez commented on CASSANDRA-18064:
---
The website content is getting built in staging:
||Branch||PR||Commit||Build||
|{{trunk}}|[#196|https://github.com/apache/cassandra-website/pull/196]|[59cc042|https://github.com/apache/cassandra-website/commit/59cc04229a9836d78ac1c2273225e32ead86e331]|[#786|https://ci-cassandra.apache.org/job/cassandra-website/786/]|
> WEBSITE - Add new contributor instruction for provisioning a Jira account
> -
>
> Key: CASSANDRA-18064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18064
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18064-01-reporting_bugs.png,
> c18064-02-contributing.png, c18064-03-patches.png, c18064-04-community.png
>
>
> In an effort to curb spam tickets, there is a new process that new ASF
> contributors must follow in order to get a Jira account provisioned. Here is
> an extract of the email announcement from the Infrastructure team:
> {quote}As I'm sure most of you are aware, the spam issues on Jira are getting
> worse. We are seeing spam user creation of over 10,000 accounts per year, and
> receive many requests per month from project members for help addressing spam
> complaints. Infra is taking steps to disable public Jira signups.
> Infra has developed a self-service tool by which folks on a PMC can request a
> Jira account for non-ASF contributors...
> {quote}
> The instruction needs to be added to the following pages:
> * [Contributing to
> Cassandra|https://cassandra.apache.org/_/development/index.html] page
> * [Contributing Code
> Changes|https://cassandra.apache.org/_/development/patches.html] (Patches)
> page
> * [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
> * *Reporting Bugs* section of the
> [Community|https://cassandra.apache.org/_/community.html#how-to-contribute]
> page
--
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-18064) WEBSITE - Add new contributor instruction for provisioning a Jira account
[
https://issues.apache.org/jira/browse/CASSANDRA-18064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18064:
--
Source Control Link:
https://github.com/apache/cassandra-website/commit/59cc04229a9836d78ac1c2273225e32ead86e331
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed:
||Branch||PR||Commit||
|{{trunk}}|[#196|https://github.com/apache/cassandra-website/pull/196]|[59cc042|https://github.com/apache/cassandra-website/commit/59cc04229a9836d78ac1c2273225e32ead86e331]|
> WEBSITE - Add new contributor instruction for provisioning a Jira account
> -
>
> Key: CASSANDRA-18064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18064
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18064-01-reporting_bugs.png,
> c18064-02-contributing.png, c18064-03-patches.png, c18064-04-community.png
>
>
> In an effort to curb spam tickets, there is a new process that new ASF
> contributors must follow in order to get a Jira account provisioned. Here is
> an extract of the email announcement from the Infrastructure team:
> {quote}As I'm sure most of you are aware, the spam issues on Jira are getting
> worse. We are seeing spam user creation of over 10,000 accounts per year, and
> receive many requests per month from project members for help addressing spam
> complaints. Infra is taking steps to disable public Jira signups.
> Infra has developed a self-service tool by which folks on a PMC can request a
> Jira account for non-ASF contributors...
> {quote}
> The instruction needs to be added to the following pages:
> * [Contributing to
> Cassandra|https://cassandra.apache.org/_/development/index.html] page
> * [Contributing Code
> Changes|https://cassandra.apache.org/_/development/patches.html] (Patches)
> page
> * [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
> * *Reporting Bugs* section of the
> [Community|https://cassandra.apache.org/_/community.html#how-to-contribute]
> page
--
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-17848) Fix incorrect resource name in LIST PERMISSION output
[
https://issues.apache.org/jira/browse/CASSANDRA-17848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-17848:
--
Summary: Fix incorrect resource name in LIST PERMISSION output (was: LIST
PERMISSION can display incorrect resource name)
> 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
>
> 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 trunk updated: WEBSITE - Added instruction for requesting JIRA account
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 59cc0422 WEBSITE - Added instruction for requesting JIRA account 59cc0422 is described below commit 59cc04229a9836d78ac1c2273225e32ead86e331 Author: Erick Ramirez AuthorDate: Mon Nov 28 21:44:46 2022 +1100 WEBSITE - Added instruction for requesting JIRA account patch by Erick Ramirez; reviewed by Mick Semb Wever for CASSANDRA-18064 --- site-content/source/modules/ROOT/pages/bugs.adoc | 2 ++ site-content/source/modules/ROOT/pages/community.adoc | 2 ++ site-content/source/modules/ROOT/pages/development/gettingstarted.adoc | 2 ++ site-content/source/modules/ROOT/pages/development/patches.adoc| 2 ++ 4 files changed, 8 insertions(+) diff --git a/site-content/source/modules/ROOT/pages/bugs.adoc b/site-content/source/modules/ROOT/pages/bugs.adoc index 676d07ab..ba8e8cd8 100644 --- a/site-content/source/modules/ROOT/pages/bugs.adoc +++ b/site-content/source/modules/ROOT/pages/bugs.adoc @@ -14,6 +14,8 @@ Please provide as much details as you can on your problem, and don't forget to indicate which version of Cassandra you are running and on which environment. +To create a JIRA account, please request it on xref:community.adoc#discussions[the #cassandra or #cassandra-dev channels on ASF Slack], or on xref:community.adoc#discussions[the user or dev mailing list]. + Further details on how to contribute can be found at our xref:community.adoc#how-to-contribute[Contributing to Cassandra] section. Please note that the source of this documentation is part of the Cassandra git repository and hence diff --git a/site-content/source/modules/ROOT/pages/community.adoc b/site-content/source/modules/ROOT/pages/community.adoc index c4d730f8..6f4e3739 100644 --- a/site-content/source/modules/ROOT/pages/community.adoc +++ b/site-content/source/modules/ROOT/pages/community.adoc @@ -437,6 +437,8 @@ If you encounter a problem with Cassandra, the first places to ask for help are If, after having asked for help, you suspect that you have found a bug in Cassandra, you should report it by opening a ticket through the https://issues.apache.org/jira/browse/CASSANDRA[Apache Cassandra JIRA tracking system,window=blank]. Please provide as much detail as you can on your problem. Don’t forget to indicate which version of Cassandra you are running and on which environment. +To create a JIRA account, please request it on xref:community.adoc#discussions[the #cassandra or #cassandra-dev channels on ASF Slack], or on xref:community.adoc#discussions[the user or dev mailing list]. + -- // end row diff --git a/site-content/source/modules/ROOT/pages/development/gettingstarted.adoc b/site-content/source/modules/ROOT/pages/development/gettingstarted.adoc index efe2574b..b38baeb2 100644 --- a/site-content/source/modules/ROOT/pages/development/gettingstarted.adoc +++ b/site-content/source/modules/ROOT/pages/development/gettingstarted.adoc @@ -58,6 +58,8 @@ better yet, produce an automated test that reproduces the issue and attach it to the ticket. If you go as far as producing a fix, follow the process for submitting a xref::patches.adoc[patch]. +To create a JIRA account, please request it on xref:community.adoc#discussions[the #cassandra or #cassandra-dev channels on ASF Slack], or on xref:community.adoc#discussions[the user or dev mailing list]. + === Create unit tests and Dtests Test coverage for Cassandra will always benefit from more automated test diff --git a/site-content/source/modules/ROOT/pages/development/patches.adoc b/site-content/source/modules/ROOT/pages/development/patches.adoc index 438decd0..13956ac2 100644 --- a/site-content/source/modules/ROOT/pages/development/patches.adoc +++ b/site-content/source/modules/ROOT/pages/development/patches.adoc @@ -31,6 +31,8 @@ https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20Com Hanging Fruit] Complexity in JIRA, which flags issues that often turn out to be good starter tasks for beginners. +To create a JIRA account, please request it on xref:community.adoc#discussions[the #cassandra or #cassandra-dev channels on ASF Slack], or on xref:community.adoc#discussions[the user or dev mailing list]. + === Before You Start Coding Although contributions are highly appreciated, we do not guarantee that - 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 ] Erick Ramirez updated CASSANDRA-18076: -- Authors: Chris Thornett, Erick Ramirez (was: Erick Ramirez) > 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 > > > [~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 -- 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 ] Erick Ramirez updated CASSANDRA-18076: -- Change Category: Semantic Complexity: Normal Component/s: Documentation/Blog Fix Version/s: NA Status: Open (was: Triage Needed) > 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 > > > [~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 -- 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-18076) BLOG - BigDATAwire Open Source Projects to Watch Award
Erick Ramirez created CASSANDRA-18076: - Summary: 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 Reporter: Erick Ramirez Assignee: Erick Ramirez Attachments: BigDATAwire-2022-award.jpg [~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 -- 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-17178) CEP-10: Simulator Java11 Support
[ https://issues.apache.org/jira/browse/CASSANDRA-17178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640260#comment-17640260 ] David Capwell commented on CASSANDRA-17178: --- [~benedict] [~e.dimitrova] I don't see more comments in the PR, can you review again? > CEP-10: Simulator Java11 Support > > > Key: CASSANDRA-17178 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17178 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Benedict Elliott Smith >Assignee: David Capwell >Priority: Normal > Fix For: NA > > > Java11 introduces new protection domains for package private methods, so that > classes loaded with different class loaders may not access each others’ > package private methods, regardless of the package they are declared within. > There are differences within the JDK also, and there may be byte weaving > targets that need updating (ThreadLocalRandom was one that has been handled) -- 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-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=17640231#comment-17640231
]
Stefan Miklosovic edited comment on CASSANDRA-18042 at 11/28/22 7:58 PM:
-
What about:
{code}
zero_ttl_on_twcs_fail: false
zero_ttl_on_twcs_warn: true
{code}
I do not think it is a good idea to start property in cassandra.yaml on "warn"
or "fail". This is as well 1 character shorter :)
was (Author: smiklosovic):
What about:
{code}
zero_ttl_on_twcs_fail: false
zero_ttl_on_twcs_warn: true
{code}
I do not think it is not a good idea to start property in cassandra.yaml on
"warn" or "fail". This is as well 1 character shorter :)
> 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] [Comment Edited] (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=17640233#comment-17640233 ] Ekaterina Dimitrova edited comment on CASSANDRA-18042 at 11/28/22 7:55 PM: --- I like the suggestions made by [~smiklosovic] and [~adelapena] as they are in line with the guardrails framework. Diverging can be confusing for users IMHO. After all that is why we also did all the config exercise, etc. To have some consistency was (Author: e.dimitrova): I like the suggestions made by [~smiklosovic] and [~adelapena] as they are in line with the guardrails framework. Diverging can be confusing for users IMHO > 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=17640233#comment-17640233 ] Ekaterina Dimitrova commented on CASSANDRA-18042: - I like the suggestions made by [~smiklosovic] and [~adelapena] as they are in line with the guardrails framework. Diverging can be confusing for users IMHO > 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] [Comment Edited] (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=17640231#comment-17640231
]
Stefan Miklosovic edited comment on CASSANDRA-18042 at 11/28/22 7:52 PM:
-
What about:
{code}
zero_ttl_on_twcs_fail: false
zero_ttl_on_twcs_warn: true
{code}
I do not think it is not a good idea to start property in cassandra.yaml on
"warn" or "fail". This is as well 1 character shorter :)
was (Author: smiklosovic):
What about:
{code}
zero_ttl_on_twcs_fail: true
zero_ttl_on_twcs_warn: true
{code}
I do not think it is not a good idea to start property in cassandra.yaml on
"warn" or "fail". This is as well 1 character shorter :)
> 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=17640231#comment-17640231
]
Stefan Miklosovic commented on CASSANDRA-18042:
---
What about:
{code}
zero_ttl_on_twcs_fail: true
zero_ttl_on_twcs_warn: true
{code}
I do not think it is not a good idea to start property in cassandra.yaml on
"warn" or "fail". This is as well 1 character shorter :)
> 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-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=17640223#comment-17640223
]
Stefan Miklosovic commented on CASSANDRA-17925:
---
That works for me but I am not sure if it is possible to just warn and not
error out in practice. Do you mean you want to warn just on new / modified
files? So in that case, checkstyle would have to know what "new or modified"
means. I think that checkstyle can not see this. If it was just warning all
such violations, the output would be monstrously long but I guess that is fine?
How do we motivate people to actually fix it though.
We might also wait for big integrations to be merged and we do the big-bang
after that.
> 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-17547) Documentation from Partition Denylist Lost in Document Migration + Minor Fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-17547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640218#comment-17640218 ] Josh McKenzie commented on CASSANDRA-17547: --- +1 > Documentation from Partition Denylist Lost in Document Migration + Minor Fixes > -- > > Key: CASSANDRA-17547 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17547 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Jordan West >Assignee: Sharan Foga >Priority: Normal > Time Spent: 0.5h > Remaining Estimate: 0h > > The documentation added in > https://issues.apache.org/jira/browse/CASSANDRA-12106 went missing when the > documents were migrated to the new format. We just need to bring the doc > back. Along with this fix there are a couple minor edits to make to the > document itself to correct the examples. -- 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=17640213#comment-17640213
]
Josh McKenzie commented on CASSANDRA-17925:
---
{quote}I think this is quite an important change
{quote}
{quote}We will touch almost all classes in Cassandra code base
{quote}
{quote}the headache that it is going to cause for forward merging
{quote}
What's the upside to us fixing this in the entire codebase and failing the
build on checkstyle vs. introducing this rule as a warning and fixing it over
time as we go? Seems like there's a lot of work in flight that's going to have
to do a lot of trench-digging work just to get over this diff.
> 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-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=17640210#comment-17640210
]
Josh McKenzie commented on CASSANDRA-18042:
---
{quote}#zero_default_ttl_on_twcs_disallowed: false
{quote}
Could we go with the somewhat simpler:
{code:java}
warn_on_0_ttl_for_twcs: true
fail_on_0_ttl_for_twcs: false
{code}
Or something along those lines? This parameter is different than the other
_enabled guardrails as they're binary "on/off" switches, effectively feature
flags, whereas this is a "you could be using this wrong and/or be setting
yourself up for future pain" style guardrail.
> 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] [Updated] (CASSANDRA-18046) A few large DTests failing on trunk after CASSANDRA-17679
[
https://issues.apache.org/jira/browse/CASSANDRA-18046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-18046:
--
Resolution: Fixed
Status: Resolved (was: Open)
> A few large DTests failing on trunk after CASSANDRA-17679
> --
>
> Key: CASSANDRA-18046
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18046
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
>
> While testing CASSANDRA-18001 I noticed that a few large DTests are failing
> after CASSANDRA-17679.
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2129/workflows/885a9ac1-cf12-4fe2-8e27-431af0cd7417/jobs/16691/tests#failed-test-3]
> [TestMaterializedViews.test_add_dc_after_mv_network_replication
> (large)|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/materialized_views_test/TestMaterializedViews/test_add_dc_after_mv_network_replication]
> [TestMaterializedViews.test_add_dc_after_mv_network_replication
> (large-novnode)|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/materialized_views_test/TestMaterializedViews/test_add_dc_after_mv_network_replication]
> [TestReplaceAddress.test_resume_failed_replace
> (large)|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/replace_address_test/TestReplaceAddress/test_resume_failed_replace]
> [TestReplaceAddress.test_resume_failed_replace
> (large-novnode)|https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/replace_address_test/TestReplaceAddress/test_resume_failed_replace]
> From test_add_dc_after_mv_network_replication:
> {code:java}
> test teardown failure Unexpected error found in node logs (see stdout for
> full details). Errors: [[node4] 'ERROR [RMI TCP Connection(2)-127.0.0.1]
> 2022-11-14 18:17:12,075 RangeStreamer.java:716 - Discovered existing
> bootstrap data and cassandra.reset_bootstrap_progress is not configured;
> aborting bootstrap. Please clean up local files manually and try again or set
> cassandra.reset_bootstrap_progress=true to ignore. Found:
> [FetchReplica{local=Full(/127.0.0.4:7000,(-948011243982554585,-529333561071865027]),
> remote=Full(/127.0.0.1:7000,(-948011243982554585,-529333561071865027])},
> FetchReplica{local=Full(/127.0.0.4:7000,(-1913296136443343226,-1608706368519466684]),
> remote=Full(/127.0.0.1:7000,(-1913296136443343226,-1608706368519466684])},
> FetchReplica{local=Full(/127.0.0.4:7000,(-4645079874475487012,-4478384472891273586]),
> remote=Full(/127.0.0.1:7000,(-4645079874475487012,-4478384472891273586])},
> FetchReplica{local=Full(/127.0.0.4:7000,(-8099177469676285022,-7854326460977230843]),
> remote=Full(/127.0.0.1:7000,(-8099177469676285022,-7854326460977230843])},
> FetchReplica{local=Full(/127.0.0.4:7000,(4622442467519845550,4890578535898204379]),
> remote=Full(/127.0.0.1:7000,(4622442467519845550,4890578535898204379])},
> FetchReplica{local=Full(/127.0.0.4:7000,(7380640855742145045,7647358289237905583]),
> remote=Full(/127.0.0.1:7000,(7380640855742145045,7647358289237905583])},
> FetchReplica{local=Full(/127.0.0.4:7000,(-3745211865398425909,-3420377942455939864]),
> remote=Full(/127.0.0.1:7000,(-3745211865398425909,-3420377942455939864])},
> FetchReplica{local=Full(/127.0.0.4:7000,(220943679196459793,240311054740010215]),
> remote=Full(/127.0.0.1:7000,(220943679196459793,240311054740010215])},
> FetchReplica{local=Full(/127.0.0.4:7000,(-9089536355394438553,-8950368361212169132]),
> remote=Full(/127.0.0.1:7000,(-9089536355394438553,-8950368361212169132])},
> FetchReplica{local=Full(/127.0.0.4:7000,(1270067479525650881,1319683862187611873]),
> remote=Full(/127.0.0.1:7000,(1270067479525650881,1319683862187611873])}].
> Fully available: [(220943679196459793,240311054740010215],
> (714186444608726945,1270067479525650881],
> (1270067479525650881,1319683862187611873],
> (1681550687687262444,2205980652317166301],
> (2205980652317166301,2563203867868203845],
> (2989961503515581499,3271555240201161082],
> (3271555240201161082,3530568110946739344],
> (4622442467519845550,4890578535898204379],
> (4890578535898204379,5120572663460637982],
> (6233317147386468337,6523342873530347572],
> (6523342873530347572,6739595959157681279],
> (7380640855742145045,7647358289237905583],
> (7647358289237905583,7717741411673795355],
> (9105128289353134439,-9089536355394438553],
> (-9089536355394438553,-8950368361212169132],
> (-8612046773544495484,-8099177469676285022],
> (-8099177469676285022,-7854326460977230843],
> (-7272331012938171751,-6967841455392203442],
> (-6967841455392203442,-6763029350285018583],
> (-632
[jira] [Commented] (CASSANDRA-18035) Add quick start development guide and docker ant targets
[
https://issues.apache.org/jira/browse/CASSANDRA-18035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640205#comment-17640205
]
Josh McKenzie commented on CASSANDRA-18035:
---
bq. I have created a cassandra-website PR to add a reference to the new Quick
Start Development Guide in the Contributing to Cassandra section of the
website. Does this work Josh McKenzie ?
Conceptual structure works for me. I won't have time to review this work
unfortunately so can't speak to the details of impl.
> Add quick start development guide and docker ant targets
>
>
> Key: CASSANDRA-18035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18035
> Project: Cassandra
> Issue Type: Task
> Components: Documentation
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Time Spent: 40m
> Remaining Estimate: 0h
>
> I propose adding a new {{QUICKSTART.md}} guide that provides instructions to
> beginner contributors on how to:
> a) Setup a development environment and IDE from scratch on WSL/Ubuntu/Debian
> environments
> b) Run a simple unit test from the IDE
> c) Create a simple patch that prints "Hello World" during Cassandra
> initialization
> d) Test the patch on a local docker instance
> A new {{docker/}} directory is added along with the guide with the following
> utilities:
> a) Dockerfile: unoptimized vanilla docker image manifest suitable only for
> local dev testing.
> b) build.sh: build a cassandra artifact and cassandra-test image.
> c) start.sh: start local cassandra-test container.
> d) stop.sh: stop local-cassandra test container.
> A couple of follow-up improvements that come to mind:
> - Add ant targets to build/start/stop cassandra-test container.
> - Add OSX instructions.
> - More IDE setup instructions (ie. Eclipse/VScode).
> - A more involved Hello World example, perhaps creating a dummy VirtualTable
> with unit/dtests.
> - Update Dockerfile to point to build/ instead of creating an artifact.
> A DEV mailing list message was sent to gather community feedback on this
> proposal: https://lists.apache.org/thread/gmb0q5yb2bzbs0cjw7mlcz1vwk2l23g2
--
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 (ee17e08e -> 91ed6029)
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 ee17e08e generate docs for 9b5fa3b6 new 91ed6029 generate docs for 9b5fa3b6 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 (ee17e08e) \ N -- N -- N refs/heads/asf-staging (91ed6029) 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] [Commented] (CASSANDRA-18025) cassandra-stress: not all contact point are passed down to driver
[ https://issues.apache.org/jira/browse/CASSANDRA-18025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640146#comment-17640146 ] Israel Fruchter commented on CASSANDRA-18025: - [~smiklosovic] the idea is that we are using cassandra-stress during complex test cases, in which at any given time one of the nodes might be affect by a ChaosMonkey style experiment/fault. in those situation we might start cassandra-stress with a list of nodes, which one of them is down. and it's part of what we are testing. other stress tools we are using, doesn't suffer from this issue, since they are passing all contact points down to their driver code. The whole idea is to let user run the stress tool also on cluster which are not fully functioning, as long as you doing CQL command in QUORUM for example, you have guarantee it should work, isn't that what Cassandra advertise ? :) Anyhow randomly picking one of the nodes doesn't guarantees that all of them are working, just that this one that was selected is up. [~brandon.williams] the driver is aware that nodes goes down, but I don't think cassandra-stress is listen to those. (but it's visible you turn on some of the driver debug levels) And again, all production code will be using multiple contact points (for exactly the reason I've described), I think tooling and tests should act as close to production behavior as possible. > cassandra-stress: not all contact point are passed down to driver > - > > Key: CASSANDRA-18025 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18025 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Israel Fruchter >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.2 > > Time Spent: 10m > Remaining Estimate: 0h > > Seem like c-s is randomly selecting a node from the nodes passed down to it > in the command line, and use that node as contact point to the driver. > > When using c-s together with other management operations (for example > expending/shrinking the cluster), we can get into situation some of the nodes > mentioned in the command line aren't reachable/available, and c-s instead of > applying the best practice of having multiple contact points, pass down only > one that can be unavailable and fail completely without trying any of the > other nodes mentioned in the command line > we just fixed that in our fork of cassandra-stress: > [https://github.com/scylladb/scylla-tools-java/pull/314] > -- 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-18025) cassandra-stress: not all contact point are passed down to driver
[ https://issues.apache.org/jira/browse/CASSANDRA-18025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640135#comment-17640135 ] Brandon Williams commented on CASSANDRA-18025: -- I think the driver probably does notify that the node it tried was down? > cassandra-stress: not all contact point are passed down to driver > - > > Key: CASSANDRA-18025 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18025 > Project: Cassandra > Issue Type: Bug > Components: Tool/stress >Reporter: Israel Fruchter >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.2 > > Time Spent: 10m > Remaining Estimate: 0h > > Seem like c-s is randomly selecting a node from the nodes passed down to it > in the command line, and use that node as contact point to the driver. > > When using c-s together with other management operations (for example > expending/shrinking the cluster), we can get into situation some of the nodes > mentioned in the command line aren't reachable/available, and c-s instead of > applying the best practice of having multiple contact points, pass down only > one that can be unavailable and fail completely without trying any of the > other nodes mentioned in the command line > we just fixed that in our fork of cassandra-stress: > [https://github.com/scylladb/scylla-tools-java/pull/314] > -- 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-18058) In-memory index and query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18058: Reviewers: Andres de la Peña, Caleb Rackliffe (was: Andres de la Peña) > 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
[cassandra-builds] branch trunk updated: Switch to use debian repo mirrors
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git The following commit(s) were added to refs/heads/trunk by this push: new 6a3c6d3 Switch to use debian repo mirrors 6a3c6d3 is described below commit 6a3c6d38cac4c92cd7760bff6bb91ec7a0642830 Author: Mick Semb Wever AuthorDate: Mon Nov 28 14:56:41 2022 +0100 Switch to use debian repo mirrors ref: https://wiki.debian.org/ftp.debian.org --- docker/bullseye-image.docker | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docker/bullseye-image.docker b/docker/bullseye-image.docker index b5d801b..76d4ed9 100644 --- a/docker/bullseye-image.docker +++ b/docker/bullseye-image.docker @@ -26,8 +26,8 @@ RUN echo 'Acquire::ftp::Timeout "60";' >> /etc/apt/apt.conf.d/80proxy.conf RUN until apt-get update && apt-get -y install ant build-essential curl devscripts git python2 sudo ; \ do echo "apt failed… trying again in 10s… " ; sleep 10 ; done -RUN echo 'deb http://ftp.debian.org/debian bullseye main' >> /etc/apt/sources.list \ -&& echo 'deb http://ftp.debian.org/debian stretch main' >> /etc/apt/sources.list +RUN echo 'deb http://deb.debian.org/debian bullseye main' >> /etc/apt/sources.list \ +&& echo 'deb http://deb.debian.org/debian stretch main' >> /etc/apt/sources.list RUN until apt-get update \ && apt-get install -y --no-install-recommends openjdk-8-jdk openjdk-11-jdk openjdk-17-jdk ; \ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cep-15-accord updated: Refactor response tracking to improve efficiency and clarity; introduce dedicated property tests; re-activate fast-path during range movements
This is an automated email from the ASF dual-hosted git repository.
benedict pushed a commit to branch cep-15-accord
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cep-15-accord by this push:
new 822bff2c72 Refactor response tracking to improve efficiency and
clarity; introduce dedicated property tests; re-activate fast-path during range
movements
822bff2c72 is described below
commit 822bff2c72791e654e315607b587a14d86bc4741
Author: Benedict Elliott Smith
AuthorDate: Mon Nov 28 16:07:26 2022 +
Refactor response tracking to improve efficiency and clarity; introduce
dedicated property tests; re-activate fast-path during range movements
patch by Benedict; reviewed by Ariel Weisberg for CASSANDRA-18056
---
src/java/org/apache/cassandra/service/accord/AccordService.java| 2 ++
.../service/accord/serializers/BeginInvalidationSerializers.java | 7 ---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/java/org/apache/cassandra/service/accord/AccordService.java
b/src/java/org/apache/cassandra/service/accord/AccordService.java
index 02c62510b6..1400d6e2f1 100644
--- a/src/java/org/apache/cassandra/service/accord/AccordService.java
+++ b/src/java/org/apache/cassandra/service/accord/AccordService.java
@@ -26,6 +26,7 @@ import java.util.concurrent.TimeoutException;
import com.google.common.annotations.VisibleForTesting;
import accord.impl.SimpleProgressLog;
+import accord.impl.SizeOfIntersectionSorter;
import accord.local.Node;
import accord.messages.Reply;
import accord.messages.Request;
@@ -75,6 +76,7 @@ public class AccordService implements Shutdownable
new AccordAgent(),
new Random(),
scheduler,
+ SizeOfIntersectionSorter.SUPPLIER,
SimpleProgressLog::new,
AccordCommandStores::new);
this.nodeShutdown = toShutdownable(node);
diff --git
a/src/java/org/apache/cassandra/service/accord/serializers/BeginInvalidationSerializers.java
b/src/java/org/apache/cassandra/service/accord/serializers/BeginInvalidationSerializers.java
index 9596761f35..d4ebe727f9 100644
---
a/src/java/org/apache/cassandra/service/accord/serializers/BeginInvalidationSerializers.java
+++
b/src/java/org/apache/cassandra/service/accord/serializers/BeginInvalidationSerializers.java
@@ -21,6 +21,7 @@ package org.apache.cassandra.service.accord.serializers;
import java.io.IOException;
import accord.api.RoutingKey;
+import accord.local.SaveStatus;
import accord.local.Status;
import accord.messages.BeginInvalidation;
import accord.messages.BeginInvalidation.InvalidateNack;
@@ -70,14 +71,14 @@ public class BeginInvalidationSerializers
{
void serializeOk(InvalidateOk ok, DataOutputPlus out, int version)
throws IOException
{
-CommandSerializers.status.serialize(ok.status, out, version);
+CommandSerializers.saveStatus.serialize(ok.status, out, version);
serializeNullable(KeySerializers.abstractRoute, ok.route, out,
version);
serializeNullable(KeySerializers.routingKey, ok.homeKey, out,
version);
}
InvalidateOk deserializeOk(DataInputPlus in, int version) throws
IOException
{
-Status status = CommandSerializers.status.deserialize(in, version);
+SaveStatus status = CommandSerializers.saveStatus.deserialize(in,
version);
AbstractRoute route =
deserializeNullable(KeySerializers.abstractRoute, in, version);
RoutingKey homeKey =
deserializeNullable(KeySerializers.routingKey, in, version);
return new InvalidateOk(status, route, homeKey);
@@ -85,7 +86,7 @@ public class BeginInvalidationSerializers
long serializedOkSize(InvalidateOk ok, int version)
{
-return CommandSerializers.status.serializedSize(ok.status, version)
+return CommandSerializers.saveStatus.serializedSize(ok.status,
version)
+ serializedSizeNullable(KeySerializers.abstractRoute,
ok.route, version)
+ serializedSizeNullable(KeySerializers.routingKey,
ok.homeKey, version);
}
-
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=17640110#comment-17640110
]
Brandon Williams commented on CASSANDRA-18075:
--
I think you may have overlooked
[this|https://github.com/apache/cassandra/blob/cassandra-4.0/NEWS.txt#L302]
part of NEWS.txt and need to set
[this|https://github.com/apache/cassandra/blob/cassandra-4.0/conf/cassandra.yaml#L1127]
option.
> 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
> dbaasprod-ca-abssl-dc-437097-v001-7mump:~# nod
[cassandra-website] branch asf-staging updated (eca73cec -> ee17e08e)
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 eca73cec generate docs for 9b5fa3b6 new ee17e08e generate docs for 9b5fa3b6 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 (eca73cec) \ N -- N -- N refs/heads/asf-staging (ee17e08e) 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/doc/4.2/cassandra/cql/functions.html | 89 - content/doc/trunk/cassandra/cql/functions.html | 89 - content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4970139 -> 4970139 bytes 4 files changed, 173 insertions(+), 7 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18064) WEBSITE - Add new contributor instruction for provisioning a Jira account
[
https://issues.apache.org/jira/browse/CASSANDRA-18064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18064:
---
Status: Review In Progress (was: Patch Available)
> WEBSITE - Add new contributor instruction for provisioning a Jira account
> -
>
> Key: CASSANDRA-18064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18064
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18064-01-reporting_bugs.png,
> c18064-02-contributing.png, c18064-03-patches.png, c18064-04-community.png
>
>
> In an effort to curb spam tickets, there is a new process that new ASF
> contributors must follow in order to get a Jira account provisioned. Here is
> an extract of the email announcement from the Infrastructure team:
> {quote}As I'm sure most of you are aware, the spam issues on Jira are getting
> worse. We are seeing spam user creation of over 10,000 accounts per year, and
> receive many requests per month from project members for help addressing spam
> complaints. Infra is taking steps to disable public Jira signups.
> Infra has developed a self-service tool by which folks on a PMC can request a
> Jira account for non-ASF contributors...
> {quote}
> The instruction needs to be added to the following pages:
> * [Contributing to
> Cassandra|https://cassandra.apache.org/_/development/index.html] page
> * [Contributing Code
> Changes|https://cassandra.apache.org/_/development/patches.html] (Patches)
> page
> * [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
> * *Reporting Bugs* section of the
> [Community|https://cassandra.apache.org/_/community.html#how-to-contribute]
> page
--
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-18064) WEBSITE - Add new contributor instruction for provisioning a Jira account
[
https://issues.apache.org/jira/browse/CASSANDRA-18064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18064:
---
Status: Ready to Commit (was: Review In Progress)
> WEBSITE - Add new contributor instruction for provisioning a Jira account
> -
>
> Key: CASSANDRA-18064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18064
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18064-01-reporting_bugs.png,
> c18064-02-contributing.png, c18064-03-patches.png, c18064-04-community.png
>
>
> In an effort to curb spam tickets, there is a new process that new ASF
> contributors must follow in order to get a Jira account provisioned. Here is
> an extract of the email announcement from the Infrastructure team:
> {quote}As I'm sure most of you are aware, the spam issues on Jira are getting
> worse. We are seeing spam user creation of over 10,000 accounts per year, and
> receive many requests per month from project members for help addressing spam
> complaints. Infra is taking steps to disable public Jira signups.
> Infra has developed a self-service tool by which folks on a PMC can request a
> Jira account for non-ASF contributors...
> {quote}
> The instruction needs to be added to the following pages:
> * [Contributing to
> Cassandra|https://cassandra.apache.org/_/development/index.html] page
> * [Contributing Code
> Changes|https://cassandra.apache.org/_/development/patches.html] (Patches)
> page
> * [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
> * *Reporting Bugs* section of the
> [Community|https://cassandra.apache.org/_/community.html#how-to-contribute]
> page
--
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-18064) WEBSITE - Add new contributor instruction for provisioning a Jira account
[
https://issues.apache.org/jira/browse/CASSANDRA-18064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640001#comment-17640001
]
Michael Semb Wever commented on CASSANDRA-18064:
+1
> WEBSITE - Add new contributor instruction for provisioning a Jira account
> -
>
> Key: CASSANDRA-18064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18064
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18064-01-reporting_bugs.png,
> c18064-02-contributing.png, c18064-03-patches.png, c18064-04-community.png
>
>
> In an effort to curb spam tickets, there is a new process that new ASF
> contributors must follow in order to get a Jira account provisioned. Here is
> an extract of the email announcement from the Infrastructure team:
> {quote}As I'm sure most of you are aware, the spam issues on Jira are getting
> worse. We are seeing spam user creation of over 10,000 accounts per year, and
> receive many requests per month from project members for help addressing spam
> complaints. Infra is taking steps to disable public Jira signups.
> Infra has developed a self-service tool by which folks on a PMC can request a
> Jira account for non-ASF contributors...
> {quote}
> The instruction needs to be added to the following pages:
> * [Contributing to
> Cassandra|https://cassandra.apache.org/_/development/index.html] page
> * [Contributing Code
> Changes|https://cassandra.apache.org/_/development/patches.html] (Patches)
> page
> * [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
> * *Reporting Bugs* section of the
> [Community|https://cassandra.apache.org/_/community.html#how-to-contribute]
> page
--
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-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=17639952#comment-17639952 ] Mike Adamson edited comment on CASSANDRA-18058 at 11/28/22 11:35 AM: - Apart from StorageAttachedIndex the rest of these classes are not touched by my patch. Is it appropriate for me to correct these on my patch? EDIT: Ignore this, I have fixed all the imports on failing classes on my patch to allow JDK8 CI builds to run. was (Author: mike_tr_adamson): Apart from StorageAttachedIndex the rest of these classes are not touched by my patch. Is it appropriate for me to correct these on my patch? > 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] [Comment Edited] (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=17639952#comment-17639952 ] Mike Adamson edited comment on CASSANDRA-18058 at 11/28/22 11:05 AM: - Apart from StorageAttachedIndex the rest of these classes are not touched by my patch. Is it appropriate for me to correct these on my patch? was (Author: mike_tr_adamson): Apart from `StorageAttachedIndex` the rest of these classes are not touched by my patch. Is it appropriate for me to correct these on my patch? > 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-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=17639952#comment-17639952 ] Mike Adamson commented on CASSANDRA-18058: -- Apart from `StorageAttachedIndex` the rest of these classes are not touched by my patch. Is it appropriate for me to correct these on my patch? > 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] [Updated] (CASSANDRA-18064) WEBSITE - Add new contributor instruction for provisioning a Jira account
[
https://issues.apache.org/jira/browse/CASSANDRA-18064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18064:
--
Description:
In an effort to curb spam tickets, there is a new process that new ASF
contributors must follow in order to get a Jira account provisioned. Here is an
extract of the email announcement from the Infrastructure team:
{quote}As I'm sure most of you are aware, the spam issues on Jira are getting
worse. We are seeing spam user creation of over 10,000 accounts per year, and
receive many requests per month from project members for help addressing spam
complaints. Infra is taking steps to disable public Jira signups.
Infra has developed a self-service tool by which folks on a PMC can request a
Jira account for non-ASF contributors...
{quote}
The instruction needs to be added to the following pages:
* [Contributing to
Cassandra|https://cassandra.apache.org/_/development/index.html] page
* [Contributing Code
Changes|https://cassandra.apache.org/_/development/patches.html] (Patches) page
* [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
* *Reporting Bugs* section of the
[Community|https://cassandra.apache.org/_/community.html#how-to-contribute] page
was:
In an effort to curb spam tickets, there is a new process that new ASF
contributors must follow in order to get a Jira account provisioned. Here is an
extract of the email announcement from the Infrastructure team:
{quote}As I'm sure most of you are aware, the spam issues on Jira are getting
worse. We are seeing spam user creation of over 10,000 accounts per year, and
receive many requests per month from project members for help addressing spam
complaints. Infra is taking steps to disable public Jira signups.
Infra has developed a self-service tool by which folks on a PMC can request a
Jira account for non-ASF contributors...{quote}
The instruction needs to be added to the following pages:
* [Contributing to
Cassandra|https://cassandra.apache.org/_/development/index.html] page
* [Contributing Code
Changes|https://cassandra.apache.org/_/development/patches.html] (Patches) page
* [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
> WEBSITE - Add new contributor instruction for provisioning a Jira account
> -
>
> Key: CASSANDRA-18064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18064
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18064-01-reporting_bugs.png,
> c18064-02-contributing.png, c18064-03-patches.png, c18064-04-community.png
>
>
> In an effort to curb spam tickets, there is a new process that new ASF
> contributors must follow in order to get a Jira account provisioned. Here is
> an extract of the email announcement from the Infrastructure team:
> {quote}As I'm sure most of you are aware, the spam issues on Jira are getting
> worse. We are seeing spam user creation of over 10,000 accounts per year, and
> receive many requests per month from project members for help addressing spam
> complaints. Infra is taking steps to disable public Jira signups.
> Infra has developed a self-service tool by which folks on a PMC can request a
> Jira account for non-ASF contributors...
> {quote}
> The instruction needs to be added to the following pages:
> * [Contributing to
> Cassandra|https://cassandra.apache.org/_/development/index.html] page
> * [Contributing Code
> Changes|https://cassandra.apache.org/_/development/patches.html] (Patches)
> page
> * [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
> * *Reporting Bugs* section of the
> [Community|https://cassandra.apache.org/_/community.html#how-to-contribute]
> page
--
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-18064) WEBSITE - Add new contributor instruction for provisioning a Jira account
[
https://issues.apache.org/jira/browse/CASSANDRA-18064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18064:
--
Attachment: (was: c18064-03-patches.png)
> WEBSITE - Add new contributor instruction for provisioning a Jira account
> -
>
> Key: CASSANDRA-18064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18064
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18064-01-reporting_bugs.png,
> c18064-02-contributing.png, c18064-03-patches.png, c18064-04-community.png
>
>
> In an effort to curb spam tickets, there is a new process that new ASF
> contributors must follow in order to get a Jira account provisioned. Here is
> an extract of the email announcement from the Infrastructure team:
> {quote}As I'm sure most of you are aware, the spam issues on Jira are getting
> worse. We are seeing spam user creation of over 10,000 accounts per year, and
> receive many requests per month from project members for help addressing spam
> complaints. Infra is taking steps to disable public Jira signups.
> Infra has developed a self-service tool by which folks on a PMC can request a
> Jira account for non-ASF contributors...{quote}
> The instruction needs to be added to the following pages:
> * [Contributing to
> Cassandra|https://cassandra.apache.org/_/development/index.html] page
> * [Contributing Code
> Changes|https://cassandra.apache.org/_/development/patches.html] (Patches)
> page
> * [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
--
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-18064) WEBSITE - Add new contributor instruction for provisioning a Jira account
[
https://issues.apache.org/jira/browse/CASSANDRA-18064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18064:
--
Attachment: c18064-04-community.png
c18064-03-patches.png
c18064-02-contributing.png
c18064-01-reporting_bugs.png
> WEBSITE - Add new contributor instruction for provisioning a Jira account
> -
>
> Key: CASSANDRA-18064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18064
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18064-01-reporting_bugs.png,
> c18064-02-contributing.png, c18064-03-patches.png, c18064-04-community.png
>
>
> In an effort to curb spam tickets, there is a new process that new ASF
> contributors must follow in order to get a Jira account provisioned. Here is
> an extract of the email announcement from the Infrastructure team:
> {quote}As I'm sure most of you are aware, the spam issues on Jira are getting
> worse. We are seeing spam user creation of over 10,000 accounts per year, and
> receive many requests per month from project members for help addressing spam
> complaints. Infra is taking steps to disable public Jira signups.
> Infra has developed a self-service tool by which folks on a PMC can request a
> Jira account for non-ASF contributors...{quote}
> The instruction needs to be added to the following pages:
> * [Contributing to
> Cassandra|https://cassandra.apache.org/_/development/index.html] page
> * [Contributing Code
> Changes|https://cassandra.apache.org/_/development/patches.html] (Patches)
> page
> * [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
--
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-18064) WEBSITE - Add new contributor instruction for provisioning a Jira account
[
https://issues.apache.org/jira/browse/CASSANDRA-18064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18064:
--
Attachment: (was: c18064-02-contributing.png)
> WEBSITE - Add new contributor instruction for provisioning a Jira account
> -
>
> Key: CASSANDRA-18064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18064
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18064-03-patches.png
>
>
> In an effort to curb spam tickets, there is a new process that new ASF
> contributors must follow in order to get a Jira account provisioned. Here is
> an extract of the email announcement from the Infrastructure team:
> {quote}As I'm sure most of you are aware, the spam issues on Jira are getting
> worse. We are seeing spam user creation of over 10,000 accounts per year, and
> receive many requests per month from project members for help addressing spam
> complaints. Infra is taking steps to disable public Jira signups.
> Infra has developed a self-service tool by which folks on a PMC can request a
> Jira account for non-ASF contributors...{quote}
> The instruction needs to be added to the following pages:
> * [Contributing to
> Cassandra|https://cassandra.apache.org/_/development/index.html] page
> * [Contributing Code
> Changes|https://cassandra.apache.org/_/development/patches.html] (Patches)
> page
> * [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
--
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-18064) WEBSITE - Add new contributor instruction for provisioning a Jira account
[
https://issues.apache.org/jira/browse/CASSANDRA-18064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18064:
--
Attachment: (was: c18064-04-community.png)
> WEBSITE - Add new contributor instruction for provisioning a Jira account
> -
>
> Key: CASSANDRA-18064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18064
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18064-03-patches.png
>
>
> In an effort to curb spam tickets, there is a new process that new ASF
> contributors must follow in order to get a Jira account provisioned. Here is
> an extract of the email announcement from the Infrastructure team:
> {quote}As I'm sure most of you are aware, the spam issues on Jira are getting
> worse. We are seeing spam user creation of over 10,000 accounts per year, and
> receive many requests per month from project members for help addressing spam
> complaints. Infra is taking steps to disable public Jira signups.
> Infra has developed a self-service tool by which folks on a PMC can request a
> Jira account for non-ASF contributors...{quote}
> The instruction needs to be added to the following pages:
> * [Contributing to
> Cassandra|https://cassandra.apache.org/_/development/index.html] page
> * [Contributing Code
> Changes|https://cassandra.apache.org/_/development/patches.html] (Patches)
> page
> * [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
--
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-18064) WEBSITE - Add new contributor instruction for provisioning a Jira account
[
https://issues.apache.org/jira/browse/CASSANDRA-18064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18064:
--
Attachment: (was: c18064-01-reporting_bugs.png)
> WEBSITE - Add new contributor instruction for provisioning a Jira account
> -
>
> Key: CASSANDRA-18064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18064
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18064-03-patches.png
>
>
> In an effort to curb spam tickets, there is a new process that new ASF
> contributors must follow in order to get a Jira account provisioned. Here is
> an extract of the email announcement from the Infrastructure team:
> {quote}As I'm sure most of you are aware, the spam issues on Jira are getting
> worse. We are seeing spam user creation of over 10,000 accounts per year, and
> receive many requests per month from project members for help addressing spam
> complaints. Infra is taking steps to disable public Jira signups.
> Infra has developed a self-service tool by which folks on a PMC can request a
> Jira account for non-ASF contributors...{quote}
> The instruction needs to be added to the following pages:
> * [Contributing to
> Cassandra|https://cassandra.apache.org/_/development/index.html] page
> * [Contributing Code
> Changes|https://cassandra.apache.org/_/development/patches.html] (Patches)
> page
> * [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
--
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-18064) WEBSITE - Add new contributor instruction for provisioning a Jira account
[
https://issues.apache.org/jira/browse/CASSANDRA-18064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18064:
--
Test and Documentation Plan: Stage locally and verify that updates pages
render as expected
Status: Patch Available (was: In Progress)
Patch:
||Branch||PR||
|{{trunk}}|[#196|https://github.com/apache/cassandra-website/pull/196]|
I've added the following text to four pages on the website:
{noformat}
To create a JIRA account, please request it on
xref:community.adoc#discussions[the #cassandra or #cassandra-dev channels on
ASF Slack], or on xref:community.adoc#discussions[the user or dev mailing list].
{noformat}
!c18064-01-reporting_bugs.png|width=300!
!c18064-02-contributing.png|width=300!
!c18064-03-patches.png|width=300!
!c18064-04-community.png|width=300!
> WEBSITE - Add new contributor instruction for provisioning a Jira account
> -
>
> Key: CASSANDRA-18064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18064
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18064-01-reporting_bugs.png,
> c18064-02-contributing.png, c18064-03-patches.png, c18064-04-community.png
>
>
> In an effort to curb spam tickets, there is a new process that new ASF
> contributors must follow in order to get a Jira account provisioned. Here is
> an extract of the email announcement from the Infrastructure team:
> {quote}As I'm sure most of you are aware, the spam issues on Jira are getting
> worse. We are seeing spam user creation of over 10,000 accounts per year, and
> receive many requests per month from project members for help addressing spam
> complaints. Infra is taking steps to disable public Jira signups.
> Infra has developed a self-service tool by which folks on a PMC can request a
> Jira account for non-ASF contributors...{quote}
> The instruction needs to be added to the following pages:
> * [Contributing to
> Cassandra|https://cassandra.apache.org/_/development/index.html] page
> * [Contributing Code
> Changes|https://cassandra.apache.org/_/development/patches.html] (Patches)
> page
> * [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
--
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-18064) WEBSITE - Add new contributor instruction for provisioning a Jira account
[
https://issues.apache.org/jira/browse/CASSANDRA-18064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18064:
--
Attachment: c18064-04-community.png
c18064-03-patches.png
c18064-02-contributing.png
c18064-01-reporting_bugs.png
> WEBSITE - Add new contributor instruction for provisioning a Jira account
> -
>
> Key: CASSANDRA-18064
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18064
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
> Attachments: c18064-01-reporting_bugs.png,
> c18064-02-contributing.png, c18064-03-patches.png, c18064-04-community.png
>
>
> In an effort to curb spam tickets, there is a new process that new ASF
> contributors must follow in order to get a Jira account provisioned. Here is
> an extract of the email announcement from the Infrastructure team:
> {quote}As I'm sure most of you are aware, the spam issues on Jira are getting
> worse. We are seeing spam user creation of over 10,000 accounts per year, and
> receive many requests per month from project members for help addressing spam
> complaints. Infra is taking steps to disable public Jira signups.
> Infra has developed a self-service tool by which folks on a PMC can request a
> Jira account for non-ASF contributors...{quote}
> The instruction needs to be added to the following pages:
> * [Contributing to
> Cassandra|https://cassandra.apache.org/_/development/index.html] page
> * [Contributing Code
> Changes|https://cassandra.apache.org/_/development/patches.html] (Patches)
> page
> * [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
--
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-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17221:
---
Source Control Link:
https://github.com/apache/cassandra/commit/88dc64d2086c9a91f00ee024b8ef13cb2c193ee6
(was: https://github.com/apache/cassandra/commits/trunk)
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.2
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
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=17639854#comment-17639854 ] Stefan Miklosovic commented on CASSANDRA-18042: --- OK, we will go with default warning and optional failure. Two flags. That translates to this PR (1) [~adelapena] could you please go through it one more time to be sure? I will provide all the builds then. (1) https://github.com/apache/cassandra/pull/2027/commits > 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
