[jira] [Updated] (CASSANDRA-17342) Performance problem for node restart with incremental range repairs

[Marcus Eriksson (Jira)]

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

Marcus Eriksson updated CASSANDRA-17342:

Reviewers: Marcus Eriksson

> Performance problem for node restart with incremental range repairs
> ---
>
> Key: CASSANDRA-17342
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17342
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair
>Reporter: Paul Chandler
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: BulkRepairStateTest.java, 
> IncrementalRepairStartupTest.java, LocalSessions.java, RepairedState.java
>
>
> There is a performance problem when restarting cassandra for clusters doing 
> incremental repairs with range repairs. 
> We have clusters with 16 vnodes per node, and are splitting each vnode into 
> 100 ranges, this causes a node to take over 30 minutes to process the data 
> stored in the system.repairs table before the node can restart. Even when we 
> reduce this to 10 ranges per vnode this still takes 2 minutes to process. The 
> cluster has 22 keyspaces and a rf of 3, this creates around 8100 records in 
> the system.repairs table.
>  
> The problem seems to occur in the 
> org.apache.cassandra.repair.consistent.RepairState class where the add method 
> re processes the complete list, including sorting, every time a new Range is 
> added. This leads is an exponential growth in processing time, this is 
> demonstrated in the attached unit test.
>  
> I have created a change, that collects the data read in from the 
> system.repairs table, in the 
> org.apache.cassandra.repair.consistent.LocalSessions class, before processing 
> it as a group at the end, this reduces the processing time to a couple of 
> seconds even for the 100 range version.
>  
> This is my first attempt at changing the cassandra code, so I am in need of a 
> mentor to help me with the process, and validate what I have done.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Created] (CASSANDRA-17344) Documentation update of virtual table system_views.clients

[Tibor Repasi (Jira)]

Tibor Repasi created CASSANDRA-17344:


 Summary: Documentation update of virtual table system_views.clients
 Key: CASSANDRA-17344
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17344
 Project: Cassandra
  Issue Type: Improvement
  Components: Documentation
Reporter: Tibor Repasi
Assignee: Tibor Repasi


With CASSANDRA-16378 there are changes introduced to virtual table 
system_views.clients. This is updating the documentation page.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-17344) Documentation update of virtual table system_views.clients

[Tibor Repasi (Jira)]

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

Tibor Repasi commented on CASSANDRA-17344:
--

PR [#1435|https://github.com/apache/cassandra/pull/1435] contains the 
documentation updates.

> Documentation update of virtual table system_views.clients
> --
>
> Key: CASSANDRA-17344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17344
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> With CASSANDRA-16378 there are changes introduced to virtual table 
> system_views.clients. This is updating the documentation page.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients

[Tibor Repasi (Jira)]

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

Tibor Repasi commented on CASSANDRA-16378:
--

CASSANDRA-17344 is open and linked to the according PR.

> Expose application_name and application_version in virtual table 
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
>  Labels: AdventCalendar2021, gsoc2021, lhf, mentor
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Recent java-driver's 
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
>  respects properties 
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
>  and 
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table 
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the 
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile 
> fields {{applicationName}} and {{applicationVersion}} need to be added to 
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The  {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be 
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}. 
> The new {{application_name}} and {{application_version}} columns need to be 
> added to the {{system_views.clients}} represented by the {{ClientsTable}} 
> class. The data then need to be retrieved from the {{ClientState}} through 
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic commented on CASSANDRA-16956:
---

The build I got: https://ci-cassandra.apache.org/job/Cassandra-devbranch/1391/

It seems to be just about flakes, upgrade failures are not the unique here, the 
previous build unrelated to this ticket got them too. I ll run another one to 
see if I can get something better if it is not enough.

> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc, 
> signature.asc, signature.asc, signature.asc, signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no 
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-17236) Add support for short form of version to CQLSH

[Yash Ladha (Jira)]

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

Yash Ladha commented on CASSANDRA-17236:


Thanks will take a look into this, sorry for the delayed response.

> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Madhavan
>Assignee: Yash Ladha
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this 
> enhancement Jira is to request that we also offer a shorter version `-v` to 
> cqlsh. This will have consistency benefits with other tools and even match 
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than 
> the single dashed short form that is available at many other tools. Thanks to 
> Ekaterina for finding this. It looks like this is stemming from Python's 
> parse mechanism which is detailed here, 
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>  
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
>                                usage="Usage: %prog [options] [host [port]]",
>                                version='cqlsh ' + version)
> {quote}
>  
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> This looks like a weird implementation at Python. Both (\-\-help) and 
> (\-\-version) options are stemming from here, 
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and 
> they did decide to ignore the short form option for version and it somehow 
> automatically takes the (--v) option to spit the version info.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-17326) Security Bug

[Brandon Williams (Jira)]

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

Brandon Williams commented on CASSANDRA-17326:
--

Our OWASP suppressions are here: 
https://github.com/apache/cassandra/blob/cassandra-3.11/.build/dependency-check-suppressions.xml

> Security Bug
> 
>
> Key: CASSANDRA-17326
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17326
> Project: Cassandra
>  Issue Type: Bug
>  Components: Dependencies
>Reporter: Ori Prog
>Priority: Normal
>
> The Cassandra 3.11.11 uses _netty-all-4.0.44.Final.jar_
> This library has the following CVEs. {*}Part of these CVEs are critical{*}!
> Please upgrade to 4.1.71.Final
> CVE-2019-20445
> CVE-2019-20444
> CVE-2019-16869
> CVE-2020-7238
> CVE-2021-37136
> CVE-2021-37137
> CVE-2021-21409
> CVE-2021-43797
> CVE-2021-21295
> CVE-2021-21290



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-17031) Add support for PEM based key material for SSL

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic commented on CASSANDRA-17031:
---

https://ci-cassandra.apache.org/job/Cassandra-devbranch/1393/

> Add support for PEM based key material for SSL
> --
>
> Key: CASSANDRA-17031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17031
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Internode
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1
>
>  Time Spent: 7h 10m
>  Remaining Estimate: 0h
>
> h1. Scope
> Currently Cassandra supports standard keystore types for SSL 
> keys/certificates. The scope of this enhancement is to add support for PEM 
> based key material (keys/certificate) given that PEM is widely used common 
> format for the same. We intend to add support for Unencrypted and Password 
> Based Encrypted (PBE) PKCS#8 formatted Private Keys in PEM format with 
> standard algorithms (RSA, DSA and EC) along with the certificate chain for 
> the private key and PEM based X509 certificates. The work here is going to be 
> built on top of [CEP-9: Make SSLContext creation 
> pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable]
>  for which the code is merged for Apache Cassandra 4.1 release.
> We intend to support the key material be configured as direct PEM values 
> input OR via the file (configured with keystore and truststore configurations 
> today). We are not going to model PEM as a valid 'store_type' given that 
> 'store_type' has a [specific 
> definition|https://docs.oracle.com/en/java/javase/11/security/java-cryptography-architecture-jca-reference-guide.html#GUID-AB51DEFD-5238-4F96-967F-082F6D34FBEA].
>  
> h1. Approach
> Create an implementation for 
> [ISslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/ISslContextFactory.java]
>  extending 
> [FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java]
>  implementation to add PEM formatted key/certificates.
> h1. Motivation
> PEM is a widely used format for encoding Private Keys and X.509 Certificates 
> and Apache Cassandra's current implementation lacks the support for 
> specifying the PEM formatted key material for SSL configurations. This means 
> operators have to re-create the key material to comply to the supported 
> formats (using key/trust store types - jks, pkcs12 etc) and deal with an 
> operational task for managing it. This is an operational overhead we can 
> avoid by supporting the PEM format making Apache Cassandra even more customer 
> friendly and drive more adoption.
> h1. Proposed Changes
>  # A new implementation for ISslContextFactory - PEMBasedSslContextFactory 
> with the following supported configuration
> {panel:title=New configurations}
> {panel}
> |{{encryption_options:  }}
>  {{}}{{ssl_context_factory:}}
>  {{}}{{class_name: 
> org.apache.cassandra.security.PEMBasedSslContextFactory}}
>  {{}}{{parameters:}}
>  {{  }}{{private_key:  certificate chain>}}
>  {{  }}{{private_key_password:  }}{{private}} {{key }}{{if}} {{it is encrypted>}}
>  {{  }}{{trusted_certificates: }}|
> *NOTE:* We could reuse 'keystore_password' instead of the 
> 'private_key_password'. However PEM encoded private key is not a 'keystore' 
> in itself hence it would be inappropriate to piggyback on that other than 
> avoid duplicating similar fields.
>  # The PEMBasedSslContextFactory will also support file based key material 
> (and the corresponding HOT Reloading based on file timestamp updates) for the 
> PEM format via existing  'keystore' and 'truststore' encryption options. 
> However in that case the 'truststore_password' configuration won't be used 
> since generally PEM formatted certificates for truststore don't get encrypted 
> with a password.
>  # The PEMBasedSslContextFactory will internally create PKCS12 keystore for 
> private key and the trusted certificates. However, this doesn't impact the 
> user of the implementation in anyway and it is mentioned for clarity only.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Comment Edited] (CASSANDRA-17031) Add support for PEM based key material for SSL

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-17031 at 2/3/22, 2:48 PM:


Hi [~maulin.vasavada],

I am running the build here:

https://ci-cassandra.apache.org/job/Cassandra-devbranch/1394/

I fixed few minor things and I noticed your branch likely does not compile on 
Java 8 because you used "Set.of" which is not there yet, in Pem reader.  I have 
fixed that, squashed all commits and I am running the build as I write this.

The branch I am building is here: (1). You can either cherry-pick or just leave 
it to me to take care of that, I ll move it over the line if we are really 
done, examples tested and so on.

(1) 
https://github.com/instaclustr/cassandra/commit/7e80c8a5f3bf027b4e24684c337c98a78b41830a


was (Author: smiklosovic):
https://ci-cassandra.apache.org/job/Cassandra-devbranch/1393/

> Add support for PEM based key material for SSL
> --
>
> Key: CASSANDRA-17031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17031
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Internode
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1
>
>  Time Spent: 7.5h
>  Remaining Estimate: 0h
>
> h1. Scope
> Currently Cassandra supports standard keystore types for SSL 
> keys/certificates. The scope of this enhancement is to add support for PEM 
> based key material (keys/certificate) given that PEM is widely used common 
> format for the same. We intend to add support for Unencrypted and Password 
> Based Encrypted (PBE) PKCS#8 formatted Private Keys in PEM format with 
> standard algorithms (RSA, DSA and EC) along with the certificate chain for 
> the private key and PEM based X509 certificates. The work here is going to be 
> built on top of [CEP-9: Make SSLContext creation 
> pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable]
>  for which the code is merged for Apache Cassandra 4.1 release.
> We intend to support the key material be configured as direct PEM values 
> input OR via the file (configured with keystore and truststore configurations 
> today). We are not going to model PEM as a valid 'store_type' given that 
> 'store_type' has a [specific 
> definition|https://docs.oracle.com/en/java/javase/11/security/java-cryptography-architecture-jca-reference-guide.html#GUID-AB51DEFD-5238-4F96-967F-082F6D34FBEA].
>  
> h1. Approach
> Create an implementation for 
> [ISslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/ISslContextFactory.java]
>  extending 
> [FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java]
>  implementation to add PEM formatted key/certificates.
> h1. Motivation
> PEM is a widely used format for encoding Private Keys and X.509 Certificates 
> and Apache Cassandra's current implementation lacks the support for 
> specifying the PEM formatted key material for SSL configurations. This means 
> operators have to re-create the key material to comply to the supported 
> formats (using key/trust store types - jks, pkcs12 etc) and deal with an 
> operational task for managing it. This is an operational overhead we can 
> avoid by supporting the PEM format making Apache Cassandra even more customer 
> friendly and drive more adoption.
> h1. Proposed Changes
>  # A new implementation for ISslContextFactory - PEMBasedSslContextFactory 
> with the following supported configuration
> {panel:title=New configurations}
> {panel}
> |{{encryption_options:  }}
>  {{}}{{ssl_context_factory:}}
>  {{}}{{class_name: 
> org.apache.cassandra.security.PEMBasedSslContextFactory}}
>  {{}}{{parameters:}}
>  {{  }}{{private_key:  certificate chain>}}
>  {{  }}{{private_key_password:  }}{{private}} {{key }}{{if}} {{it is encrypted>}}
>  {{  }}{{trusted_certificates: }}|
> *NOTE:* We could reuse 'keystore_password' instead of the 
> 'private_key_password'. However PEM encoded private key is not a 'keystore' 
> in itself hence it would be inappropriate to piggyback on that other than 
> avoid duplicating similar fields.
>  # The PEMBasedSslContextFactory will also support file based key material 
> (and the corresponding HOT Reloading based on file timestamp updates) for the 
> PEM format via existing  'keystore' and 'truststore' encryption options. 
> However in that case the 'truststore_password' configuration won't be used 
> since generally PEM formatted certificates for truststore don't get encrypted 
> with a password.
>  # 

[jira] [Commented] (CASSANDRA-17342) Performance problem for node restart with incremental range repairs

[Paul Chandler (Jira)]

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

Paul Chandler commented on CASSANDRA-17342:
---

I have created a pull request here: 
[https://github.com/paulchandler/cassandra/pull/1/files]



This is the first time for me doing this, so not sure if I have done it 
correctly, if not, I welcome any guidance to improve. 

> Performance problem for node restart with incremental range repairs
> ---
>
> Key: CASSANDRA-17342
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17342
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair
>Reporter: Paul Chandler
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: BulkRepairStateTest.java, 
> IncrementalRepairStartupTest.java, LocalSessions.java, RepairedState.java
>
>
> There is a performance problem when restarting cassandra for clusters doing 
> incremental repairs with range repairs. 
> We have clusters with 16 vnodes per node, and are splitting each vnode into 
> 100 ranges, this causes a node to take over 30 minutes to process the data 
> stored in the system.repairs table before the node can restart. Even when we 
> reduce this to 10 ranges per vnode this still takes 2 minutes to process. The 
> cluster has 22 keyspaces and a rf of 3, this creates around 8100 records in 
> the system.repairs table.
>  
> The problem seems to occur in the 
> org.apache.cassandra.repair.consistent.RepairState class where the add method 
> re processes the complete list, including sorting, every time a new Range is 
> added. This leads is an exponential growth in processing time, this is 
> demonstrated in the attached unit test.
>  
> I have created a change, that collects the data read in from the 
> system.repairs table, in the 
> org.apache.cassandra.repair.consistent.LocalSessions class, before processing 
> it as a group at the end, this reduces the processing time to a couple of 
> seconds even for the 100 range version.
>  
> This is my first attempt at changing the cassandra code, so I am in need of a 
> mentor to help me with the process, and validate what I have done.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-17266) DESCRIBE KEYSPACE / MATERIALIZED VIEW generates invalid CQL for views

[Yash Ladha (Jira)]

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

Yash Ladha commented on CASSANDRA-17266:


Sure [~blerer] let me take a look at this, sorry for the delayed response 
wasn't able to look into this.

> DESCRIBE KEYSPACE / MATERIALIZED VIEW generates invalid CQL for views
> -
>
> Key: CASSANDRA-17266
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17266
> Project: Cassandra
>  Issue Type: Bug
>  Components: CQL/Syntax
>Reporter: Oleg Zhovtanyuk
>Assignee: Yash Ladha
>Priority: Normal
>  Labels: lhf
> Fix For: 4.0.x
>
>
> Materialized views do not allow default_time_to_live option in CQL (see 
> CASSANDRA-12868).
> But, if the MV was created without this option, DESCRIBE KEYSPACE / 
> MATERIALIZED VIEW command generates CQL that includes it.
> E.g.
> {code:java}
> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> USE test;
> CREATE TABLE test_table(
>   id text,
>   date text,
>   col1 text,
>   col2 text,
>   PRIMARY KEY(id,date)
> ) WITH default_time_to_live = 60 AND CLUSTERING ORDER BY (date DESC);
> CREATE MATERIALIZED VIEW test_view AS
> SELECT id, date, col1
> FROM test_table
> WHERE id IS NOT NULL AND date IS NOT NULL
> PRIMARY KEY(id, date);{code}
> It is OK. 
> {code:java}
> DESCRIBE MATERIALIZED VIEW test_view; {code}
> returns the same CQL + all default options:
> {code:java}
> CREATE MATERIALIZED VIEW test.test_view AS
>     SELECT id, date, col1
>     FROM test.test_table
>     WHERE id IS NOT NULL AND date IS NOT NULL
>     PRIMARY KEY (id, date)
>  WITH CLUSTERING ORDER BY (date ASC)
>     AND additional_write_policy = '99p'
>     AND bloom_filter_fp_chance = 0.01
>     AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
>     AND cdc = false
>     AND comment = ''
>     AND compaction = {'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32', 'min_threshold': '4'}
>     AND compression = {'chunk_length_in_kb': '16', 'class': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
>     AND crc_check_chance = 1.0
>     AND default_time_to_live = 0
>     AND extensions = {}
>     AND gc_grace_seconds = 864000
>     AND max_index_interval = 2048
>     AND memtable_flush_period_in_ms = 0
>     AND min_index_interval = 128
>     AND read_repair = 'BLOCKING'
>     AND speculative_retry = '99p';
> {code}
> Note the 'default_time_to_live = 0' clause! If this veiw is dropped, 
> re-creating it using DESCRIBE output would fail with 
> {noformat}
> Cannot set default_time_to_live for a materialized view. Data in a 
> materialized view always expire at the same time than the corresponding data 
> in the parent table.{noformat}
> +Additional Information for newcomers:+
> The code writting the table parameters is in {{TableParams.appendCqlTo}} and 
> is called through {{TableMetadata.appendTableOptions}}. Those method will 
> need to have a new parameter specifying if the call is for a table or a 
> materialized view.
> Some unit test need to be adapted in {{DescribeStatementTest}} 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-17293) Update python test framework from nose to nose2

[Yash Ladha (Jira)]

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

Yash Ladha commented on CASSANDRA-17293:


Sure [~bschoeni] doing that.

> Update python test framework from nose to nose2
> ---
>
> Key: CASSANDRA-17293
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17293
> Project: Cassandra
>  Issue Type: Task
>  Components: CQL/Interpreter
>Reporter: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
>
> I had trouble trying to install and run the python nose test from pip 
> (nosetest not found).
> According to the homepage of nose at [https://nose.readthedocs.io/en/latest/]
> h1. _Note to Users_
> _Nose has been in maintenance mode for the past several years and will likely 
> cease without a new person/team to take over maintainership. New projects 
> should consider using [Nose2|https://github.com/nose-devs/nose2], 
> [py.test|http://pytest.org/], or just plain unittest/unittest2._
>  
> Upgrading to nose2 is likely the least effort. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Assigned] (CASSANDRA-17293) Update python test framework from nose to nose2

[Yash Ladha (Jira)]

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

Yash Ladha reassigned CASSANDRA-17293:
--

Assignee: Yash Ladha

> Update python test framework from nose to nose2
> ---
>
> Key: CASSANDRA-17293
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17293
> Project: Cassandra
>  Issue Type: Task
>  Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Yash Ladha
>Priority: Normal
> Fix For: 4.x
>
>
> I had trouble trying to install and run the python nose test from pip 
> (nosetest not found).
> According to the homepage of nose at [https://nose.readthedocs.io/en/latest/]
> h1. _Note to Users_
> _Nose has been in maintenance mode for the past several years and will likely 
> cease without a new person/team to take over maintainership. New projects 
> should consider using [Nose2|https://github.com/nose-devs/nose2], 
> [py.test|http://pytest.org/], or just plain unittest/unittest2._
>  
> Upgrading to nose2 is likely the least effort. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-17342) Performance problem for node restart with incremental range repairs

[Marcus Eriksson (Jira)]

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

Marcus Eriksson commented on CASSANDRA-17342:
-

Tracking them in a {{Map> initialLevels = 
new HashMap<>();}} in the {{start()}} method is a bit clearer to me, and it 
avoids adding that list in RepairedState which is only used during startup

> Performance problem for node restart with incremental range repairs
> ---
>
> Key: CASSANDRA-17342
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17342
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair
>Reporter: Paul Chandler
>Assignee: Paul Chandler
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: BulkRepairStateTest.java, 
> IncrementalRepairStartupTest.java, LocalSessions.java, RepairedState.java
>
>
> There is a performance problem when restarting cassandra for clusters doing 
> incremental repairs with range repairs. 
> We have clusters with 16 vnodes per node, and are splitting each vnode into 
> 100 ranges, this causes a node to take over 30 minutes to process the data 
> stored in the system.repairs table before the node can restart. Even when we 
> reduce this to 10 ranges per vnode this still takes 2 minutes to process. The 
> cluster has 22 keyspaces and a rf of 3, this creates around 8100 records in 
> the system.repairs table.
>  
> The problem seems to occur in the 
> org.apache.cassandra.repair.consistent.RepairState class where the add method 
> re processes the complete list, including sorting, every time a new Range is 
> added. This leads is an exponential growth in processing time, this is 
> demonstrated in the attached unit test.
>  
> I have created a change, that collects the data read in from the 
> system.repairs table, in the 
> org.apache.cassandra.repair.consistent.LocalSessions class, before processing 
> it as a group at the end, this reduces the processing time to a couple of 
> seconds even for the 100 range version.
>  
> This is my first attempt at changing the cassandra code, so I am in need of a 
> mentor to help me with the process, and validate what I have done.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-17342) Performance problem for node restart with incremental range repairs

[Paul Chandler (Jira)]

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

Paul Chandler commented on CASSANDRA-17342:
---

Thanks Marcus,

I will take a look at the style issues.

I did think about doing it as an addAll method, I can't remember what stopped 
me, so I will revisit it.

> Performance problem for node restart with incremental range repairs
> ---
>
> Key: CASSANDRA-17342
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17342
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair
>Reporter: Paul Chandler
>Assignee: Paul Chandler
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: BulkRepairStateTest.java, 
> IncrementalRepairStartupTest.java, LocalSessions.java, RepairedState.java
>
>
> There is a performance problem when restarting cassandra for clusters doing 
> incremental repairs with range repairs. 
> We have clusters with 16 vnodes per node, and are splitting each vnode into 
> 100 ranges, this causes a node to take over 30 minutes to process the data 
> stored in the system.repairs table before the node can restart. Even when we 
> reduce this to 10 ranges per vnode this still takes 2 minutes to process. The 
> cluster has 22 keyspaces and a rf of 3, this creates around 8100 records in 
> the system.repairs table.
>  
> The problem seems to occur in the 
> org.apache.cassandra.repair.consistent.RepairState class where the add method 
> re processes the complete list, including sorting, every time a new Range is 
> added. This leads is an exponential growth in processing time, this is 
> demonstrated in the attached unit test.
>  
> I have created a change, that collects the data read in from the 
> system.repairs table, in the 
> org.apache.cassandra.repair.consistent.LocalSessions class, before processing 
> it as a group at the end, this reduces the processing time to a couple of 
> seconds even for the 100 range version.
>  
> This is my first attempt at changing the cassandra code, so I am in need of a 
> mentor to help me with the process, and validate what I have done.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-17236) Add support for short form of version to CQLSH

[Brandon Williams (Jira)]

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

Brandon Williams commented on CASSANDRA-17236:
--

no apology necessary, feel free to work at your own pace, there is no rush. :)

> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Semantics
>Reporter: Madhavan
>Assignee: Yash Ladha
>Priority: Low
>  Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this 
> enhancement Jira is to request that we also offer a shorter version `-v` to 
> cqlsh. This will have consistency benefits with other tools and even match 
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than 
> the single dashed short form that is available at many other tools. Thanks to 
> Ekaterina for finding this. It looks like this is stemming from Python's 
> parse mechanism which is detailed here, 
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>  
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
>                                usage="Usage: %prog [options] [host [port]]",
>                                version='cqlsh ' + version)
> {quote}
>  
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> This looks like a weird implementation at Python. Both (\-\-help) and 
> (\-\-version) options are stemming from here, 
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and 
> they did decide to ignore the short form option for version and it somehow 
> automatically takes the (--v) option to spit the version info.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-16378) Expose application_name and application_version in virtual table system_views.clients

[Benjamin Lerer (Jira)]

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

Benjamin Lerer commented on CASSANDRA-16378:


We can do a separate ticket for the documentation :-)

> Expose application_name and application_version in virtual table 
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
>  Labels: AdventCalendar2021, gsoc2021, lhf, mentor
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Recent java-driver's 
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
>  respects properties 
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
>  and 
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to exposed this information via virtual table 
> {{system_views.clients}} and with {{nodetool clientstats}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the 
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. To new volatile 
> fields {{applicationName}} and {{applicationVersion}} need to be added to 
> {{ClientState}} in a similar way to {{driverName}} and {{driverVersion}}.
> The  {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} optionsneed to be 
> retrieved in {{StartupMessage#execute}} and passed to the {{ClientState}}. 
> The new {{application_name}} and {{application_version}} columns need to be 
> added to the {{system_views.clients}} represented by the {{ClientsTable}} 
> class. The data then need to be retrieved from the {{ClientState}} through 
> {{ConnectedClient}}.
> Some unit tests similat to {{SettingsTableTest}} should be added. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic commented on CASSANDRA-16956:
---

* yeah I ll do that
* it is already in NEWS.txt here (1), I dont find any added value in repeating 
that information.
* Yes, removed
* I have grepped the docs and I have fixed it where Windows is mentioned. There 
is also mention about Docker on Windows, I kept it there.
* I fixed few comments explicitly mentioning that Windows was dropped.

As a side-effect of dropping the Windows support completely, I would like to 
dedicate yet another ticket for resolving this "issue" (2). Basically, we are 
not limited to having file names of some pre-defined max length. However I 
consider this to be outside of the scope and it can be treated in a separate 
ticket in the future, not going too deep into the rabbit hole for now. I am not 
sure what other consequencies it might have to suddently not be limited on file 
name lenghts in that particular case.

(1) https://github.com/apache/cassandra/blob/trunk/NEWS.txt#L397-L401
(2) 
https://github.com/instaclustr/cassandra/blob/CASSANDRA-16956/src/java/org/apache/cassandra/schema/SchemaConstants.java#L56-L62

Branch: 
https://github.com/apache/cassandra/compare/trunk...instaclustr:CASSANDRA-16956

I ll provide build soonish, hopefully. We got some problems in Circle so trying 
my luck in Jenkins.

> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc, 
> signature.asc, signature.asc, signature.asc, signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no 
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-17342) Performance problem for node restart with incremental range repairs

[Paul Chandler (Jira)]

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

Paul Chandler commented on CASSANDRA-17342:
---

If I create a Level object in the LocalSessions class, that needs to be passed 
to multiple RepairedState objects, one per table ( this is currently done in 
the maybeUpdateRepairedState method ) So if I was storing the Level object in a 
collection this would need to be a collection of collections, one for each 
table/RepairedState. Which seems to add extra complexity to the LocalSessions, 
when it is simpler to directly store them in the RepairedState class. 

If you think this is the right way to go, then I am happy to do that, or if 
there is a different way I am happy to hear it. My Java skills are rather 
rusty, I did send 15 years writing demand forecasting algorithms, but stopped 
that 10 years ago!

> Performance problem for node restart with incremental range repairs
> ---
>
> Key: CASSANDRA-17342
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17342
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair
>Reporter: Paul Chandler
>Assignee: Paul Chandler
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: BulkRepairStateTest.java, 
> IncrementalRepairStartupTest.java, LocalSessions.java, RepairedState.java
>
>
> There is a performance problem when restarting cassandra for clusters doing 
> incremental repairs with range repairs. 
> We have clusters with 16 vnodes per node, and are splitting each vnode into 
> 100 ranges, this causes a node to take over 30 minutes to process the data 
> stored in the system.repairs table before the node can restart. Even when we 
> reduce this to 10 ranges per vnode this still takes 2 minutes to process. The 
> cluster has 22 keyspaces and a rf of 3, this creates around 8100 records in 
> the system.repairs table.
>  
> The problem seems to occur in the 
> org.apache.cassandra.repair.consistent.RepairState class where the add method 
> re processes the complete list, including sorting, every time a new Range is 
> added. This leads is an exponential growth in processing time, this is 
> demonstrated in the attached unit test.
>  
> I have created a change, that collects the data read in from the 
> system.repairs table, in the 
> org.apache.cassandra.repair.consistent.LocalSessions class, before processing 
> it as a group at the end, this reduces the processing time to a couple of 
> seconds even for the 100 range version.
>  
> This is my first attempt at changing the cassandra code, so I am in need of a 
> mentor to help me with the process, and validate what I have done.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17295) Make vtables accessible via internode messaging

[Aleksey Yeschenko (Jira)]

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

Aleksey Yeschenko updated CASSANDRA-17295:
--
Status: Review In Progress  (was: Patch Available)

> Make vtables accessible via internode messaging
> ---
>
> Key: CASSANDRA-17295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17295
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/Virtual Tables
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> As an extension of CASSANDRA-15399 and needed to solve CASSANDRA-15566, we 
> need the ability to perform queries against vtables using internode 
> messaging; currently this is limited to CQL which isn’t exposed in internode



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Comment Edited] (CASSANDRA-16956) Remove windows-specific classes

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-16956 at 2/3/22, 10:44 AM:
-

* yeah I ll do that
* it is already in NEWS.txt here (1), I dont find any added value in repeating 
that information.
* Yes, removed
* I have grepped the docs and I have fixed it where Windows is mentioned. There 
is also mention about Docker on Windows, I kept it there.
* I fixed few comments explicitly mentioning that Windows was dropped.

As a side-effect of dropping the Windows support completely, I would like to 
dedicate yet another ticket for resolving this "issue" (2). Basically, we are 
not limited to having file names of some pre-defined max length. However I 
consider this to be outside of the scope and it can be treated in a separate 
ticket in the future, not going too deep into the rabbit hole for now. I am not 
sure what other consequencies it might have to suddently not be limited on file 
name lenghts in that particular case.

(1) https://github.com/apache/cassandra/blob/trunk/NEWS.txt#L397-L401
(2) 
https://github.com/instaclustr/cassandra/blob/CASSANDRA-16956/src/java/org/apache/cassandra/schema/SchemaConstants.java#L56-L62

Branch: 
https://github.com/apache/cassandra/compare/trunk...instaclustr:CASSANDRA-16956
PR: https://github.com/apache/cassandra/pull/1249

I ll provide build soonish, hopefully. We got some problems in Circle so trying 
my luck in Jenkins.


was (Author: smiklosovic):
* yeah I ll do that
* it is already in NEWS.txt here (1), I dont find any added value in repeating 
that information.
* Yes, removed
* I have grepped the docs and I have fixed it where Windows is mentioned. There 
is also mention about Docker on Windows, I kept it there.
* I fixed few comments explicitly mentioning that Windows was dropped.

As a side-effect of dropping the Windows support completely, I would like to 
dedicate yet another ticket for resolving this "issue" (2). Basically, we are 
not limited to having file names of some pre-defined max length. However I 
consider this to be outside of the scope and it can be treated in a separate 
ticket in the future, not going too deep into the rabbit hole for now. I am not 
sure what other consequencies it might have to suddently not be limited on file 
name lenghts in that particular case.

(1) https://github.com/apache/cassandra/blob/trunk/NEWS.txt#L397-L401
(2) 
https://github.com/instaclustr/cassandra/blob/CASSANDRA-16956/src/java/org/apache/cassandra/schema/SchemaConstants.java#L56-L62

Branch: 
https://github.com/apache/cassandra/compare/trunk...instaclustr:CASSANDRA-16956

I ll provide build soonish, hopefully. We got some problems in Circle so trying 
my luck in Jenkins.

> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc, 
> signature.asc, signature.asc, signature.asc, signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no 
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-17342) Performance problem for node restart with incremental range repairs

[Brandon Williams (Jira)]

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

Brandon Williams commented on CASSANDRA-17342:
--

That's perfect.  I've moved this to Patch Available to signal it is ready to be 
reviewed.  Thanks Paul!

> Performance problem for node restart with incremental range repairs
> ---
>
> Key: CASSANDRA-17342
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17342
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair
>Reporter: Paul Chandler
>Assignee: Paul Chandler
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: BulkRepairStateTest.java, 
> IncrementalRepairStartupTest.java, LocalSessions.java, RepairedState.java
>
>
> There is a performance problem when restarting cassandra for clusters doing 
> incremental repairs with range repairs. 
> We have clusters with 16 vnodes per node, and are splitting each vnode into 
> 100 ranges, this causes a node to take over 30 minutes to process the data 
> stored in the system.repairs table before the node can restart. Even when we 
> reduce this to 10 ranges per vnode this still takes 2 minutes to process. The 
> cluster has 22 keyspaces and a rf of 3, this creates around 8100 records in 
> the system.repairs table.
>  
> The problem seems to occur in the 
> org.apache.cassandra.repair.consistent.RepairState class where the add method 
> re processes the complete list, including sorting, every time a new Range is 
> added. This leads is an exponential growth in processing time, this is 
> demonstrated in the attached unit test.
>  
> I have created a change, that collects the data read in from the 
> system.repairs table, in the 
> org.apache.cassandra.repair.consistent.LocalSessions class, before processing 
> it as a group at the end, this reduces the processing time to a couple of 
> seconds even for the 100 range version.
>  
> This is my first attempt at changing the cassandra code, so I am in need of a 
> mentor to help me with the process, and validate what I have done.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Assigned] (CASSANDRA-17342) Performance problem for node restart with incremental range repairs

[Brandon Williams (Jira)]

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

Brandon Williams reassigned CASSANDRA-17342:


Assignee: Paul Chandler  (was: Brandon Williams)

> Performance problem for node restart with incremental range repairs
> ---
>
> Key: CASSANDRA-17342
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17342
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair
>Reporter: Paul Chandler
>Assignee: Paul Chandler
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: BulkRepairStateTest.java, 
> IncrementalRepairStartupTest.java, LocalSessions.java, RepairedState.java
>
>
> There is a performance problem when restarting cassandra for clusters doing 
> incremental repairs with range repairs. 
> We have clusters with 16 vnodes per node, and are splitting each vnode into 
> 100 ranges, this causes a node to take over 30 minutes to process the data 
> stored in the system.repairs table before the node can restart. Even when we 
> reduce this to 10 ranges per vnode this still takes 2 minutes to process. The 
> cluster has 22 keyspaces and a rf of 3, this creates around 8100 records in 
> the system.repairs table.
>  
> The problem seems to occur in the 
> org.apache.cassandra.repair.consistent.RepairState class where the add method 
> re processes the complete list, including sorting, every time a new Range is 
> added. This leads is an exponential growth in processing time, this is 
> demonstrated in the attached unit test.
>  
> I have created a change, that collects the data read in from the 
> system.repairs table, in the 
> org.apache.cassandra.repair.consistent.LocalSessions class, before processing 
> it as a group at the end, this reduces the processing time to a couple of 
> seconds even for the 100 range version.
>  
> This is my first attempt at changing the cassandra code, so I am in need of a 
> mentor to help me with the process, and validate what I have done.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Assigned] (CASSANDRA-17342) Performance problem for node restart with incremental range repairs

[Brandon Williams (Jira)]

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

Brandon Williams reassigned CASSANDRA-17342:


Assignee: Brandon Williams

> Performance problem for node restart with incremental range repairs
> ---
>
> Key: CASSANDRA-17342
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17342
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair
>Reporter: Paul Chandler
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: BulkRepairStateTest.java, 
> IncrementalRepairStartupTest.java, LocalSessions.java, RepairedState.java
>
>
> There is a performance problem when restarting cassandra for clusters doing 
> incremental repairs with range repairs. 
> We have clusters with 16 vnodes per node, and are splitting each vnode into 
> 100 ranges, this causes a node to take over 30 minutes to process the data 
> stored in the system.repairs table before the node can restart. Even when we 
> reduce this to 10 ranges per vnode this still takes 2 minutes to process. The 
> cluster has 22 keyspaces and a rf of 3, this creates around 8100 records in 
> the system.repairs table.
>  
> The problem seems to occur in the 
> org.apache.cassandra.repair.consistent.RepairState class where the add method 
> re processes the complete list, including sorting, every time a new Range is 
> added. This leads is an exponential growth in processing time, this is 
> demonstrated in the attached unit test.
>  
> I have created a change, that collects the data read in from the 
> system.repairs table, in the 
> org.apache.cassandra.repair.consistent.LocalSessions class, before processing 
> it as a group at the end, this reduces the processing time to a couple of 
> seconds even for the 100 range version.
>  
> This is my first attempt at changing the cassandra code, so I am in need of a 
> mentor to help me with the process, and validate what I have done.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17342) Performance problem for node restart with incremental range repairs

[Brandon Williams (Jira)]

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

Brandon Williams updated CASSANDRA-17342:
-
Test and Documentation Plan: run CI
 Status: Patch Available  (was: Open)

> Performance problem for node restart with incremental range repairs
> ---
>
> Key: CASSANDRA-17342
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17342
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair
>Reporter: Paul Chandler
>Assignee: Paul Chandler
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: BulkRepairStateTest.java, 
> IncrementalRepairStartupTest.java, LocalSessions.java, RepairedState.java
>
>
> There is a performance problem when restarting cassandra for clusters doing 
> incremental repairs with range repairs. 
> We have clusters with 16 vnodes per node, and are splitting each vnode into 
> 100 ranges, this causes a node to take over 30 minutes to process the data 
> stored in the system.repairs table before the node can restart. Even when we 
> reduce this to 10 ranges per vnode this still takes 2 minutes to process. The 
> cluster has 22 keyspaces and a rf of 3, this creates around 8100 records in 
> the system.repairs table.
>  
> The problem seems to occur in the 
> org.apache.cassandra.repair.consistent.RepairState class where the add method 
> re processes the complete list, including sorting, every time a new Range is 
> added. This leads is an exponential growth in processing time, this is 
> demonstrated in the attached unit test.
>  
> I have created a change, that collects the data read in from the 
> system.repairs table, in the 
> org.apache.cassandra.repair.consistent.LocalSessions class, before processing 
> it as a group at the end, this reduces the processing time to a couple of 
> seconds even for the 100 range version.
>  
> This is my first attempt at changing the cassandra code, so I am in need of a 
> mentor to help me with the process, and validate what I have done.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-17342) Performance problem for node restart with incremental range repairs

[Marcus Eriksson (Jira)]

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

Marcus Eriksson commented on CASSANDRA-17342:
-

Hi, thanks fro the patch and welcome to the project

I just had a quick pass over the patch and it looks like a good approach

There are some code style issues in the patch, see 
https://cassandra.apache.org/_/development/index.html for information on how to 
set up your IDE etc

Then, I wonder if it would be better to add an {{addAll(Collection 
...)}} method on {{RepairedState}} and then collect the initial Levels in a 
local list in LocalSessions#start() instead of using {{initialLevels}} in 
{{RepairedState}}?

> Performance problem for node restart with incremental range repairs
> ---
>
> Key: CASSANDRA-17342
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17342
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Repair
>Reporter: Paul Chandler
>Assignee: Paul Chandler
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: BulkRepairStateTest.java, 
> IncrementalRepairStartupTest.java, LocalSessions.java, RepairedState.java
>
>
> There is a performance problem when restarting cassandra for clusters doing 
> incremental repairs with range repairs. 
> We have clusters with 16 vnodes per node, and are splitting each vnode into 
> 100 ranges, this causes a node to take over 30 minutes to process the data 
> stored in the system.repairs table before the node can restart. Even when we 
> reduce this to 10 ranges per vnode this still takes 2 minutes to process. The 
> cluster has 22 keyspaces and a rf of 3, this creates around 8100 records in 
> the system.repairs table.
>  
> The problem seems to occur in the 
> org.apache.cassandra.repair.consistent.RepairState class where the add method 
> re processes the complete list, including sorting, every time a new Range is 
> added. This leads is an exponential growth in processing time, this is 
> demonstrated in the attached unit test.
>  
> I have created a change, that collects the data read in from the 
> system.repairs table, in the 
> org.apache.cassandra.repair.consistent.LocalSessions class, before processing 
> it as a group at the end, this reduces the processing time to a couple of 
> seconds even for the 100 range version.
>  
> This is my first attempt at changing the cassandra code, so I am in need of a 
> mentor to help me with the process, and validate what I have done.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Comment Edited] (CASSANDRA-17031) Add support for PEM based key material for SSL

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-17031 at 2/3/22, 8:05 PM:


Hi [~maulin.vasavada],

I am running the build here:

https://ci-cassandra.apache.org/job/Cassandra-devbranch/1396/

I fixed few minor things and I noticed your branch likely does not compile on 
Java 8 because you used "Set.of" which is not there yet, in Pem reader.  I have 
fixed that, squashed all commits and I am running the build as I write this.

The branch I am building is here: (1). You can either cherry-pick or just leave 
it to me to take care of that, I ll move it over the line if we are really 
done, examples tested and so on.

(1) https://github.com/instaclustr/cassandra/tree/CASSANDRA-17031


was (Author: smiklosovic):
Hi [~maulin.vasavada],

I am running the build here:

https://ci-cassandra.apache.org/job/Cassandra-devbranch/1395/

I fixed few minor things and I noticed your branch likely does not compile on 
Java 8 because you used "Set.of" which is not there yet, in Pem reader.  I have 
fixed that, squashed all commits and I am running the build as I write this.

The branch I am building is here: (1). You can either cherry-pick or just leave 
it to me to take care of that, I ll move it over the line if we are really 
done, examples tested and so on.

(1) https://github.com/instaclustr/cassandra/tree/CASSANDRA-17031-squashed

> Add support for PEM based key material for SSL
> --
>
> Key: CASSANDRA-17031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17031
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Internode
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1
>
>  Time Spent: 7.5h
>  Remaining Estimate: 0h
>
> h1. Scope
> Currently Cassandra supports standard keystore types for SSL 
> keys/certificates. The scope of this enhancement is to add support for PEM 
> based key material (keys/certificate) given that PEM is widely used common 
> format for the same. We intend to add support for Unencrypted and Password 
> Based Encrypted (PBE) PKCS#8 formatted Private Keys in PEM format with 
> standard algorithms (RSA, DSA and EC) along with the certificate chain for 
> the private key and PEM based X509 certificates. The work here is going to be 
> built on top of [CEP-9: Make SSLContext creation 
> pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable]
>  for which the code is merged for Apache Cassandra 4.1 release.
> We intend to support the key material be configured as direct PEM values 
> input OR via the file (configured with keystore and truststore configurations 
> today). We are not going to model PEM as a valid 'store_type' given that 
> 'store_type' has a [specific 
> definition|https://docs.oracle.com/en/java/javase/11/security/java-cryptography-architecture-jca-reference-guide.html#GUID-AB51DEFD-5238-4F96-967F-082F6D34FBEA].
>  
> h1. Approach
> Create an implementation for 
> [ISslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/ISslContextFactory.java]
>  extending 
> [FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java]
>  implementation to add PEM formatted key/certificates.
> h1. Motivation
> PEM is a widely used format for encoding Private Keys and X.509 Certificates 
> and Apache Cassandra's current implementation lacks the support for 
> specifying the PEM formatted key material for SSL configurations. This means 
> operators have to re-create the key material to comply to the supported 
> formats (using key/trust store types - jks, pkcs12 etc) and deal with an 
> operational task for managing it. This is an operational overhead we can 
> avoid by supporting the PEM format making Apache Cassandra even more customer 
> friendly and drive more adoption.
> h1. Proposed Changes
>  # A new implementation for ISslContextFactory - PEMBasedSslContextFactory 
> with the following supported configuration
> {panel:title=New configurations}
> {panel}
> |{{encryption_options:  }}
>  {{}}{{ssl_context_factory:}}
>  {{}}{{class_name: 
> org.apache.cassandra.security.PEMBasedSslContextFactory}}
>  {{}}{{parameters:}}
>  {{  }}{{private_key:  certificate chain>}}
>  {{  }}{{private_key_password:  }}{{private}} {{key }}{{if}} {{it is encrypted>}}
>  {{  }}{{trusted_certificates: }}|
> *NOTE:* We could reuse 'keystore_password' instead of the 
> 'private_key_password'. However PEM encoded private key is not a 'keystore' 

[cassandra-website] branch asf-site updated (3bee802 -> 29d1de4)

[mck]

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

mck pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.


 discard 3bee802  generate docs for 395d33b7
 add 4ca2e24  Update the "maintained until" dates on the download page
 add 29d1de4  generate docs for 4ca2e248

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   (3bee802)
\
 N -- N -- N   refs/heads/asf-site (29d1de4)

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/_/download.html|   5 -
 content/doc/4.1/cassandra/new/virtualtables.html   |  23 +
 .../doc/latest/cassandra/new/virtualtables.html|  23 +
 content/doc/trunk/cassandra/new/virtualtables.html |  23 +
 content/search-index.js|   2 +-
 .../source/modules/ROOT/pages/download.adoc|  10 ++---
 site-ui/build/ui-bundle.zip| Bin 4740084 -> 4740084 
bytes
 7 files changed, 81 insertions(+), 5 deletions(-)

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

[jira] [Created] (CASSANDRA-17345) Fix flaky NetstatsBootstrapWithEntireSSTablesCompressionStreamingTest.testWithStreamingEntireSSTablesWithoutCompression

[Brandon Williams (Jira)]

Brandon Williams created CASSANDRA-17345:


 Summary: Fix flaky 
NetstatsBootstrapWithEntireSSTablesCompressionStreamingTest.testWithStreamingEntireSSTablesWithoutCompression
 
 Key: CASSANDRA-17345
 URL: https://issues.apache.org/jira/browse/CASSANDRA-17345
 Project: Cassandra
  Issue Type: Bug
Reporter: Brandon Williams


Failed 4 times in the last 30 runs. Flakiness: 17%, Stability: 86%

Error Message

Timeout occurred. Please note the time in the report does not reflect the time 
until the timeout.

Stacktrace

junit.framework.AssertionFailedError: Timeout occurred. Please note the time in 
the report does not reflect the time until the timeout.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17078) Fix failing test: SSTableReaderTest.testPersistentStatistics

[Josh McKenzie (Jira)]

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

Josh McKenzie updated CASSANDRA-17078:
--
   Complexity: Normal
Discovered By: Unit Test
 Severity: Low
   Status: Open  (was: Triage Needed)

> Fix failing test: SSTableReaderTest.testPersistentStatistics
> 
>
> Key: CASSANDRA-17078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17078
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
>
> JDK8 unit test failure
> See it on CircleCI but not on Jenkins ASF infra right now.
> {code:java}
> java.lang.RuntimeException: Failed importing sstables
>   at 
> org.apache.cassandra.db.SSTableImporter.importNewSSTables(SSTableImporter.java:164)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.loadNewSSTables(ColumnFamilyStore.java:734)
>   at 
> org.apache.cassandra.io.sstable.SSTableReaderTest.clearAndLoad(SSTableReaderTest.java:222)
>   at 
> org.apache.cassandra.io.sstable.SSTableReaderTest.testPersistentStatistics(SSTableReaderTest.java:215)
> Caused by: java.lang.RuntimeException: Failed to rename 
> /tmp/cassandra/build/test/cassandra/data/SSTableReaderTest/Standard1-da581e50380611ecaad41173773221f9/nb-9-big-Digest.crc32
>  to 
> /tmp/cassandra/build/test/cassandra/data/SSTableReaderTest/Standard1-da581e50380611ecaad41173773221f9/nb-13-big-Digest.crc32
>   at org.apache.cassandra.io.util.PathUtils.rename(PathUtils.java:385)
>   at org.apache.cassandra.io.util.File.move(File.java:227)
>   at 
> org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.java:704)
>   at 
> org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.java:698)
>   at 
> org.apache.cassandra.io.sstable.format.SSTableWriter.rename(SSTableWriter.java:337)
>   at 
> org.apache.cassandra.io.sstable.format.SSTableReader.moveAndOpenSSTable(SSTableReader.java:2339)
>   at 
> org.apache.cassandra.db.SSTableImporter.importNewSSTables(SSTableImporter.java:139)
> Caused by: java.nio.file.NoSuchFileException: 
> /tmp/cassandra/build/test/cassandra/data/SSTableReaderTest/Standard1-da581e50380611ecaad41173773221f9/nb-9-big-Digest.crc32
>  -> 
> /tmp/cassandra/build/test/cassandra/data/SSTableReaderTest/Standard1-da581e50380611ecaad41173773221f9/nb-13-big-Digest.crc32
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:396)
>   at 
> sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262)
>   at java.nio.file.Files.move(Files.java:1395)
>   at 
> org.apache.cassandra.io.util.PathUtils.atomicMoveWithFallback(PathUtils.java:396)
>   at org.apache.cassandra.io.util.PathUtils.rename(PathUtils.java:377)
> {code}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Assigned] (CASSANDRA-17187) Guardrail for SELECT IN terms and their cartesian product

[Jira]

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

Andres de la Peña reassigned CASSANDRA-17187:
-

Assignee: Andres de la Peña

> Guardrail for SELECT IN terms and their cartesian product
> -
>
> Key: CASSANDRA-17187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17187
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>  Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> Add a guardrail to limit the number restrictions generated by the cartesian 
> product of the {{IN}} restrictions of a {{SELECT}} query, for example:
> {code}
> # Guardrail to warn or abort when IN query creates a cartesian product with a 
> # size exceeding threshold, eg. "a in (1,2,...10) and b in (1,2...10)" 
> results in 
> # cartesian product of 100.
> # The two thresholds default to -1 to disable. 
> in_select_cartesian_product:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> As an example of why this guardrails is proposed, these queries bring a C* 
> instance to its knees even before the query starts executing: 
> {code}
> @Test
> public void testPartitionKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, pk3 int, pk4 int, pk5 
> int, pk6 int, pk7 int, pk8 int, pk9 int, " +
>"PRIMARY KEY((pk1, pk2, pk3, pk4, pk5, pk6, pk7, pk8, pk9)))");
> execute("SELECT * FROM %s WHERE pk1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> @Test
> public void testClusteringKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk int ,ck1 int, ck2 int, ck3 int, ck4 int, 
> ck5 int, ck6 int, ck7 int, ck8 int, ck9 int, " +
> "PRIMARY KEY(pk, ck1, ck2, ck3, ck4, ck5, ck6, ck7, ck8, ck9))");
> execute("SELECT * FROM %s WHERE pk = 1 " +
> "AND ck1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> {code}
> +Additional information for newcomers:+
> # Add the configuration for the new guardrail on cartesian product in the 
> guardrails section of cassandra.yaml.
> # Add a {{getInCartesianProduct}} method in {{GuardrailsConfig}} returning a 
> {{Threshold.Config}} object
> # Implement that method in {{GuardrailsOptions}}, which is the default 
> yaml-based implementation of {{GuardrailsConfig}}
> # Add a Threshold guardrail named {{inCartesianProduct}} in Guardrails, using 
> the previously created config
> # Define JMX-friendly getters and setters for the previously created config 
> in {{GuardrailsMBean}}
> # Implement the JMX-friendly getters and setters in Guardrails
> # Now that we have the guardrail ready, it’s time to use it. We should search 
> for a place to invoke the Guardrails#inCartesianProduct guard method. The 
> {{MultiCBuilder}} look like good candidates for this.
> # Finally, add some tests for the new guardrail. Given that the new guardrail 
> is a Threshold, our new test should probably extend {{ThresholdTester}}.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-17116) When streaming sees a ClosedChannelException this triggers the disk failure policy

[David Capwell (Jira)]

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

David Capwell commented on CASSANDRA-17116:
---

[~djoshi] approved in GH, so 2 +1s

> When streaming sees a ClosedChannelException this triggers the disk failure 
> policy
> --
>
> Key: CASSANDRA-17116
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17116
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Streaming
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Found in CASSANDRA-17085.
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7264
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7256
> {code}
> ERROR [Stream-Deserializer-/127.0.0.1:7000-f2eb1a15] 2021-11-02 21:35:40,983 
> DefaultFSErrorHandler.java:104 - Exiting forcefully due to file system 
> exception on startup, disk failure policy "stop"
> org.apache.cassandra.io.FSWriteError: java.nio.channels.ClosedChannelException
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:227)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.writeComponent(BigTableZeroCopyWriter.java:206)
>   at 
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:125)
>   at 
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:84)
>   at 
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:51)
>   at 
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:37)
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)
>   at 
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:62)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.channels.ClosedChannelException: null
>   at 
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:136)
>   at 
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:155)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:217)
>   ... 9 common frames omitted
> {code}
> When bootstrap fails and streaming is closed, this triggers the disk failure 
> policy which causes the JVM to halt by default (if this happens outside of 
> bootstrap, then we stop transports and keep the JVM up).
> org.apache.cassandra.streaming.StreamDeserializingTask attempts to handle 
> this by ignoring this exception, but the call to 
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize
>  Does try/catch and inspects exception; triggering this condition.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Comment Edited] (CASSANDRA-17031) Add support for PEM based key material for SSL

[Stefan Miklosovic (Jira)]

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

Stefan Miklosovic edited comment on CASSANDRA-17031 at 2/3/22, 5:22 PM:


Hi [~maulin.vasavada],

I am running the build here:

https://ci-cassandra.apache.org/job/Cassandra-devbranch/1395/

I fixed few minor things and I noticed your branch likely does not compile on 
Java 8 because you used "Set.of" which is not there yet, in Pem reader.  I have 
fixed that, squashed all commits and I am running the build as I write this.

The branch I am building is here: (1). You can either cherry-pick or just leave 
it to me to take care of that, I ll move it over the line if we are really 
done, examples tested and so on.

(1) https://github.com/instaclustr/cassandra/tree/CASSANDRA-17031-squashed


was (Author: smiklosovic):
Hi [~maulin.vasavada],

I am running the build here:

https://ci-cassandra.apache.org/job/Cassandra-devbranch/1394/

I fixed few minor things and I noticed your branch likely does not compile on 
Java 8 because you used "Set.of" which is not there yet, in Pem reader.  I have 
fixed that, squashed all commits and I am running the build as I write this.

The branch I am building is here: (1). You can either cherry-pick or just leave 
it to me to take care of that, I ll move it over the line if we are really 
done, examples tested and so on.

(1) 
https://github.com/instaclustr/cassandra/commit/7e80c8a5f3bf027b4e24684c337c98a78b41830a

> Add support for PEM based key material for SSL
> --
>
> Key: CASSANDRA-17031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17031
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Internode
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1
>
>  Time Spent: 7.5h
>  Remaining Estimate: 0h
>
> h1. Scope
> Currently Cassandra supports standard keystore types for SSL 
> keys/certificates. The scope of this enhancement is to add support for PEM 
> based key material (keys/certificate) given that PEM is widely used common 
> format for the same. We intend to add support for Unencrypted and Password 
> Based Encrypted (PBE) PKCS#8 formatted Private Keys in PEM format with 
> standard algorithms (RSA, DSA and EC) along with the certificate chain for 
> the private key and PEM based X509 certificates. The work here is going to be 
> built on top of [CEP-9: Make SSLContext creation 
> pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable]
>  for which the code is merged for Apache Cassandra 4.1 release.
> We intend to support the key material be configured as direct PEM values 
> input OR via the file (configured with keystore and truststore configurations 
> today). We are not going to model PEM as a valid 'store_type' given that 
> 'store_type' has a [specific 
> definition|https://docs.oracle.com/en/java/javase/11/security/java-cryptography-architecture-jca-reference-guide.html#GUID-AB51DEFD-5238-4F96-967F-082F6D34FBEA].
>  
> h1. Approach
> Create an implementation for 
> [ISslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/ISslContextFactory.java]
>  extending 
> [FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java]
>  implementation to add PEM formatted key/certificates.
> h1. Motivation
> PEM is a widely used format for encoding Private Keys and X.509 Certificates 
> and Apache Cassandra's current implementation lacks the support for 
> specifying the PEM formatted key material for SSL configurations. This means 
> operators have to re-create the key material to comply to the supported 
> formats (using key/trust store types - jks, pkcs12 etc) and deal with an 
> operational task for managing it. This is an operational overhead we can 
> avoid by supporting the PEM format making Apache Cassandra even more customer 
> friendly and drive more adoption.
> h1. Proposed Changes
>  # A new implementation for ISslContextFactory - PEMBasedSslContextFactory 
> with the following supported configuration
> {panel:title=New configurations}
> {panel}
> |{{encryption_options:  }}
>  {{}}{{ssl_context_factory:}}
>  {{}}{{class_name: 
> org.apache.cassandra.security.PEMBasedSslContextFactory}}
>  {{}}{{parameters:}}
>  {{  }}{{private_key:  certificate chain>}}
>  {{  }}{{private_key_password:  }}{{private}} {{key }}{{if}} {{it is encrypted>}}
>  {{  }}{{trusted_certificates: }}|
> *NOTE:* We could reuse 'keystore_password' instead of the 
> 'private_key_password'. However PEM encoded 

[jira] [Assigned] (CASSANDRA-17286) Test Failure: org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc

[Josh McKenzie (Jira)]

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

Josh McKenzie reassigned CASSANDRA-17286:
-

Assignee: Josh McKenzie

> Test Failure: 
> org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion-cdc
> ---
>
> Key: CASSANDRA-17286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17286
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
>
> Looks like it's a straight up flaky test:
>  
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/899/testReport/org.apache.cassandra.db.lifecycle/LogTransactionTest/testGetTemporaryFilesSafeAfterObsoletion_cdc/]
>  
> Failed 3 times in the last 17 runs. Flakiness: 31%, Stability: 82%
> h3. Error Message
> java.nio.file.NoSuchFileException: 
> /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db
> h3. Stacktrace
> java.io.UncheckedIOException: java.nio.file.NoSuchFileException: 
> /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db
>  at 
> org.apache.cassandra.io.util.PathUtils.propagateUnchecked(PathUtils.java:695) 
> at org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:514) at 
> org.apache.cassandra.io.util.PathUtils.toCanonicalPath(PathUtils.java:502) at 
> org.apache.cassandra.io.util.File.toCanonical(File.java:411) at 
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
>  at 
> java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
>  at 
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>  at 
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>  at 
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
>  at 
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>  at 
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
>  at 
> org.apache.cassandra.db.lifecycle.LogTransactionTest.listFiles(LogTransactionTest.java:1333)
>  at 
> org.apache.cassandra.db.lifecycle.LogTransactionTest.getTemporaryFiles(LogTransactionTest.java:1317)
>  at 
> org.apache.cassandra.db.lifecycle.LogTransactionTest.testGetTemporaryFilesSafeAfterObsoletion(LogTransactionTest.java:1182)
>  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method) at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  Caused by: java.nio.file.NoSuchFileException: 
> /home/cassandra/cassandra/build/test/cassandra/data/TransactionLogsTest/mockcf33-ed510f6070ca11ecbc8a25a710ea09dc/nb-0-big-Data.db
>  at 
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
>  at 
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
>  at 
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
>  at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:860) at 
> org.apache.cassandra.io.util.PathUtils.toRealPath(PathUtils.java:510)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[cassandra-website] branch trunk updated (395d33b -> 4ca2e24)

[mck]

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

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


from 395d33b  January 2022 blog "Tightening Security for Apache Cassandra 
Part: 1"
 add 4ca2e24  Update the "maintained until" dates on the download page

No new revisions were added by this update.

Summary of changes:
 site-content/source/modules/ROOT/pages/download.adoc | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

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

[jira] [Commented] (CASSANDRA-17187) Guardrail for SELECT IN terms and their cartesian product

[Jira]

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

Andres de la Peña commented on CASSANDRA-17187:
---

There was an old patch by [~Ge] for this, I'll post it here as soon as I 
adapt it to the last changes.

> Guardrail for SELECT IN terms and their cartesian product
> -
>
> Key: CASSANDRA-17187
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17187
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>  Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> Add a guardrail to limit the number restrictions generated by the cartesian 
> product of the {{IN}} restrictions of a {{SELECT}} query, for example:
> {code}
> # Guardrail to warn or abort when IN query creates a cartesian product with a 
> # size exceeding threshold, eg. "a in (1,2,...10) and b in (1,2...10)" 
> results in 
> # cartesian product of 100.
> # The two thresholds default to -1 to disable. 
> in_select_cartesian_product:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> As an example of why this guardrails is proposed, these queries bring a C* 
> instance to its knees even before the query starts executing: 
> {code}
> @Test
> public void testPartitionKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk1 int, pk2 int, pk3 int, pk4 int, pk5 
> int, pk6 int, pk7 int, pk8 int, pk9 int, " +
>"PRIMARY KEY((pk1, pk2, pk3, pk4, pk5, pk6, pk7, pk8, pk9)))");
> execute("SELECT * FROM %s WHERE pk1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND pk9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> @Test
> public void testClusteringKeyTerms() throws Throwable
> {
> createTable("CREATE TABLE %s (pk int ,ck1 int, ck2 int, ck3 int, ck4 int, 
> ck5 int, ck6 int, ck7 int, ck8 int, ck9 int, " +
> "PRIMARY KEY(pk, ck1, ck2, ck3, ck4, ck5, ck6, ck7, ck8, ck9))");
> execute("SELECT * FROM %s WHERE pk = 1 " +
> "AND ck1 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck2 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck3 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck4 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck5 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck6 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck7 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck8 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10) " +
> "AND ck9 in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);");
> }
> {code}
> +Additional information for newcomers:+
> # Add the configuration for the new guardrail on cartesian product in the 
> guardrails section of cassandra.yaml.
> # Add a {{getInCartesianProduct}} method in {{GuardrailsConfig}} returning a 
> {{Threshold.Config}} object
> # Implement that method in {{GuardrailsOptions}}, which is the default 
> yaml-based implementation of {{GuardrailsConfig}}
> # Add a Threshold guardrail named {{inCartesianProduct}} in Guardrails, using 
> the previously created config
> # Define JMX-friendly getters and setters for the previously created config 
> in {{GuardrailsMBean}}
> # Implement the JMX-friendly getters and setters in Guardrails
> # Now that we have the guardrail ready, it’s time to use it. We should search 
> for a place to invoke the Guardrails#inCartesianProduct guard method. The 
> {{MultiCBuilder}} look like good candidates for this.
> # Finally, add some tests for the new guardrail. Given that the new guardrail 
> is a Threshold, our new test should probably extend {{ThresholdTester}}.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-17078) Fix failing test: SSTableReaderTest.testPersistentStatistics

[Josh McKenzie (Jira)]

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

Josh McKenzie commented on CASSANDRA-17078:
---

Got a prelim branch 
[here|https://github.com/apache/cassandra/compare/trunk...josh-mckenzie:cassandra-17078?expand=1]
 that does a few things in SSTableReaderTest:
1. Removes duplication on the CF SSTable discarding at the start of many tests
2. Isolates the test w/the intermittent failure in circle to its own CF instead 
of sharing w/other tests
3. Isolates the test that has a couple potentially troublesome calls 
(.deleteOnExit, etc) that may be leading to ordering and timing issues between 
tests.

A lot of these tests are mucking around directly with SSTable files, deleting 
things, moving things, deleting directories and files with hooks, you name it. 
A lot of stuff that's risky when it comes to consistency if the parallelization 
of your test running infra doesn't have deterministic test ordering. 

Not sure if I can repro the original problem locally; going to give it a solid 
soak and if it doesn't repro try it on circle for a multiplex run as well.

> Fix failing test: SSTableReaderTest.testPersistentStatistics
> 
>
> Key: CASSANDRA-17078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17078
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
>
> JDK8 unit test failure
> See it on CircleCI but not on Jenkins ASF infra right now.
> {code:java}
> java.lang.RuntimeException: Failed importing sstables
>   at 
> org.apache.cassandra.db.SSTableImporter.importNewSSTables(SSTableImporter.java:164)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.loadNewSSTables(ColumnFamilyStore.java:734)
>   at 
> org.apache.cassandra.io.sstable.SSTableReaderTest.clearAndLoad(SSTableReaderTest.java:222)
>   at 
> org.apache.cassandra.io.sstable.SSTableReaderTest.testPersistentStatistics(SSTableReaderTest.java:215)
> Caused by: java.lang.RuntimeException: Failed to rename 
> /tmp/cassandra/build/test/cassandra/data/SSTableReaderTest/Standard1-da581e50380611ecaad41173773221f9/nb-9-big-Digest.crc32
>  to 
> /tmp/cassandra/build/test/cassandra/data/SSTableReaderTest/Standard1-da581e50380611ecaad41173773221f9/nb-13-big-Digest.crc32
>   at org.apache.cassandra.io.util.PathUtils.rename(PathUtils.java:385)
>   at org.apache.cassandra.io.util.File.move(File.java:227)
>   at 
> org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.java:704)
>   at 
> org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.java:698)
>   at 
> org.apache.cassandra.io.sstable.format.SSTableWriter.rename(SSTableWriter.java:337)
>   at 
> org.apache.cassandra.io.sstable.format.SSTableReader.moveAndOpenSSTable(SSTableReader.java:2339)
>   at 
> org.apache.cassandra.db.SSTableImporter.importNewSSTables(SSTableImporter.java:139)
> Caused by: java.nio.file.NoSuchFileException: 
> /tmp/cassandra/build/test/cassandra/data/SSTableReaderTest/Standard1-da581e50380611ecaad41173773221f9/nb-9-big-Digest.crc32
>  -> 
> /tmp/cassandra/build/test/cassandra/data/SSTableReaderTest/Standard1-da581e50380611ecaad41173773221f9/nb-13-big-Digest.crc32
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:396)
>   at 
> sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262)
>   at java.nio.file.Files.move(Files.java:1395)
>   at 
> org.apache.cassandra.io.util.PathUtils.atomicMoveWithFallback(PathUtils.java:396)
>   at org.apache.cassandra.io.util.PathUtils.rename(PathUtils.java:377)
> {code}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17345) Fix flaky NetstatsBootstrapWithEntireSSTablesCompressionStreamingTest.testWithStreamingEntireSSTablesWithoutCompression

[Brandon Williams (Jira)]

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

Brandon Williams updated CASSANDRA-17345:
-
 Bug Category: Parent values: Correctness(12982)Level 1 values: Test 
Failure(12990)
   Complexity: Normal
  Component/s: Consistency/Streaming
Discovered By: DTest
Fix Version/s: 4.x
 Severity: Normal
   Status: Open  (was: Triage Needed)

> Fix flaky 
> NetstatsBootstrapWithEntireSSTablesCompressionStreamingTest.testWithStreamingEntireSSTablesWithoutCompression
>  
> 
>
> Key: CASSANDRA-17345
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17345
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Streaming
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> Failed 4 times in the last 30 runs. Flakiness: 17%, Stability: 86%
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the 
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time 
> in the report does not reflect the time until the timeout.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes

[Josh McKenzie (Jira)]

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

Josh McKenzie commented on CASSANDRA-16956:
---

Left some comments on the PR and a few suggestions of other things to remove.

Once that's done, +1 here.

> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
>  Issue Type: Task
>  Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc, 
> signature.asc, signature.asc, signature.asc, signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no 
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
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 (3bee802 -> 29d1de4)

[git-site-role]

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

git-site-role pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.


omit 3bee802  generate docs for 395d33b7
 add 4ca2e24  Update the "maintained until" dates on the download page
 new 29d1de4  generate docs for 4ca2e248

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   (3bee802)
\
 N -- N -- N   refs/heads/asf-staging (29d1de4)

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/_/download.html|   5 -
 content/doc/4.1/cassandra/new/virtualtables.html   |  23 +
 .../doc/latest/cassandra/new/virtualtables.html|  23 +
 content/doc/trunk/cassandra/new/virtualtables.html |  23 +
 content/search-index.js|   2 +-
 .../source/modules/ROOT/pages/download.adoc|  10 ++---
 site-ui/build/ui-bundle.zip| Bin 4740084 -> 4740084 
bytes
 7 files changed, 81 insertions(+), 5 deletions(-)

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

[jira] [Commented] (CASSANDRA-17287) Replace cqlshlib/wcwidth.py with pypi module 'wcwidth'

[Brandon Williams (Jira)]

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

Brandon Williams commented on CASSANDRA-17287:
--

I'm not sure why that change doesn't seem to take effect in circle, but jenkins 
is faring better. 
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1397/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1397/pipeline]


> Replace cqlshlib/wcwidth.py with pypi module 'wcwidth'
> --
>
> Key: CASSANDRA-17287
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17287
> Project: Cassandra
>  Issue Type: Task
>  Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CQLSH sample query.jpg
>
>
> The module wcwidth implements the same Markus Kuhn algorithm defined in 
> POSIX.1-2008 to return the number of cells a unicode string is expected to 
> occupy.
> The module wcwidth is used by hundreds of libraries including pytest and 
> prompt-toolkit (used in ipython).  It replaces 379 lines of bespoke code in 
> cqlshlib.
> {quote}from wcwidth import wcswidth   # at [https://pypi.org/project/wcwidth/]
> print(wcswidth('コンニチハ'))
> 10
> {{from cqlshlib.wcwidth import wcswidth as cql_wcswidth}}
> print(cql_wcswidth('コンニチハ'))
> 10
> {quote}
> wcwidth appears to be used only by one line in formatting.py:
>  return bval if colormap is NO_COLOR_MAP else color_text(bval, colormap, 
> wcwidth.wcswidth(bval))



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-14328) Invalid metadata has been detected for role

[Jai Bheemsen Rao Dhanwada (Jira)]

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

Jai Bheemsen Rao Dhanwada commented on CASSANDRA-14328:
---

[~tania.en...@quest.com] [~prnvjndl] were you able to figure out why the node 
got into this state? it looks like this is a side effect of bootstrapping 
process not streaming all the data 
(https://issues.apache.org/jira/browse/CASSANDRA-14006). I see a similar issue 
and just wondering if you have any more details and workaround on this issue?

> Invalid metadata has been detected for role
> ---
>
> Key: CASSANDRA-14328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14328
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/CQL
>Reporter: Pranav Jindal
>Priority: Normal
>
> Cassandra Version : 3.10
> One node was replaced and was successfully up and working but CQL-SH fails 
> with error.
>  
> CQL-SH error:
>  
> {code:java}
> Connection error: ('Unable to connect to any servers', {'10.180.0.150': 
> AuthenticationFailed('Failed to authenticate to 10.180.0.150: Error from 
> server: code= [Server error] message="java.lang.RuntimeException: Invalid 
> metadata has been detected for role utorjwcnruzzlzafxffgyqmlvkxiqcgb"',)})
> {code}
>  
> Cassandra server ERROR:
> {code:java}
> WARN [Native-Transport-Requests-1] 2018-03-20 13:37:17,894 
> CassandraRoleManager.java:96 - An invalid value has been detected in the 
> roles table for role utorjwcnruzzlzafxffgyqmlvkxiqcgb. If you are unable to 
> login, you may need to disable authentication and confirm that values in that 
> table are accurate
> ERROR [Native-Transport-Requests-1] 2018-03-20 13:37:17,895 Message.java:623 
> - Unexpected exception during request; channel = [id: 0xdfc3604f, 
> L:/10.180.0.150:9042 - R:/10.180.0.150:51668]
> java.lang.RuntimeException: Invalid metadata has been detected for role 
> utorjwcnruzzlzafxffgyqmlvkxiqcgb
> at 
> org.apache.cassandra.auth.CassandraRoleManager$1.apply(CassandraRoleManager.java:99)
>  ~[apache-cassandra-3.10.jar:3.10]
> at 
> org.apache.cassandra.auth.CassandraRoleManager$1.apply(CassandraRoleManager.java:82)
>  ~[apache-cassandra-3.10.jar:3.10]
> at 
> org.apache.cassandra.auth.CassandraRoleManager.getRoleFromTable(CassandraRoleManager.java:528)
>  ~[apache-cassandra-3.10.jar:3.10]
> at 
> org.apache.cassandra.auth.CassandraRoleManager.getRole(CassandraRoleManager.java:503)
>  ~[apache-cassandra-3.10.jar:3.10]
> at 
> org.apache.cassandra.auth.CassandraRoleManager.canLogin(CassandraRoleManager.java:310)
>  ~[apache-cassandra-3.10.jar:3.10]
> at org.apache.cassandra.service.ClientState.login(ClientState.java:271) 
> ~[apache-cassandra-3.10.jar:3.10]
> at 
> org.apache.cassandra.transport.messages.AuthResponse.execute(AuthResponse.java:80)
>  ~[apache-cassandra-3.10.jar:3.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:517)
>  [apache-cassandra-3.10.jar:3.10]
> at 
> org.apache.cassandra.transport.Message$Dispatcher.channelRead0(Message.java:410)
>  [apache-cassandra-3.10.jar:3.10]
> at 
> io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:35)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:357)
>  [netty-all-4.0.39.Final.jar:4.0.39.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_121]
> at 
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
>  [apache-cassandra-3.10.jar:3.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) 
> [apache-cassandra-3.10.jar:3.10]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> Caused by: java.lang.NullPointerException: null
> at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getBoolean(UntypedResultSet.java:273)
>  ~[apache-cassandra-3.10.jar:3.10]
> at 
> org.apache.cassandra.auth.CassandraRoleManager$1.apply(CassandraRoleManager.java:88)
>  ~[apache-cassandra-3.10.jar:3.10]
> ... 16 common frames omitted
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Assigned] (CASSANDRA-17078) Fix failing test: SSTableReaderTest.testPersistentStatistics

[Josh McKenzie (Jira)]

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

Josh McKenzie reassigned CASSANDRA-17078:
-

Assignee: Josh McKenzie

> Fix failing test: SSTableReaderTest.testPersistentStatistics
> 
>
> Key: CASSANDRA-17078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17078
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
>
> JDK8 unit test failure
> See it on CircleCI but not on Jenkins ASF infra right now.
> {code:java}
> java.lang.RuntimeException: Failed importing sstables
>   at 
> org.apache.cassandra.db.SSTableImporter.importNewSSTables(SSTableImporter.java:164)
>   at 
> org.apache.cassandra.db.ColumnFamilyStore.loadNewSSTables(ColumnFamilyStore.java:734)
>   at 
> org.apache.cassandra.io.sstable.SSTableReaderTest.clearAndLoad(SSTableReaderTest.java:222)
>   at 
> org.apache.cassandra.io.sstable.SSTableReaderTest.testPersistentStatistics(SSTableReaderTest.java:215)
> Caused by: java.lang.RuntimeException: Failed to rename 
> /tmp/cassandra/build/test/cassandra/data/SSTableReaderTest/Standard1-da581e50380611ecaad41173773221f9/nb-9-big-Digest.crc32
>  to 
> /tmp/cassandra/build/test/cassandra/data/SSTableReaderTest/Standard1-da581e50380611ecaad41173773221f9/nb-13-big-Digest.crc32
>   at org.apache.cassandra.io.util.PathUtils.rename(PathUtils.java:385)
>   at org.apache.cassandra.io.util.File.move(File.java:227)
>   at 
> org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.java:704)
>   at 
> org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.java:698)
>   at 
> org.apache.cassandra.io.sstable.format.SSTableWriter.rename(SSTableWriter.java:337)
>   at 
> org.apache.cassandra.io.sstable.format.SSTableReader.moveAndOpenSSTable(SSTableReader.java:2339)
>   at 
> org.apache.cassandra.db.SSTableImporter.importNewSSTables(SSTableImporter.java:139)
> Caused by: java.nio.file.NoSuchFileException: 
> /tmp/cassandra/build/test/cassandra/data/SSTableReaderTest/Standard1-da581e50380611ecaad41173773221f9/nb-9-big-Digest.crc32
>  -> 
> /tmp/cassandra/build/test/cassandra/data/SSTableReaderTest/Standard1-da581e50380611ecaad41173773221f9/nb-13-big-Digest.crc32
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:396)
>   at 
> sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262)
>   at java.nio.file.Files.move(Files.java:1395)
>   at 
> org.apache.cassandra.io.util.PathUtils.atomicMoveWithFallback(PathUtils.java:396)
>   at org.apache.cassandra.io.util.PathUtils.rename(PathUtils.java:377)
> {code}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17346) Hint documentation page has a misaligned table of settings / description / default values

[Andrew Hogg (Jira)]

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

Andrew Hogg updated CASSANDRA-17346:

Description: Within the versioned documentation, the page for configuring 
hints contains a misaligned table of hint settings, caused the the 
hinted_handoff_disabled_datacenters row, which shifts all columns 1 further, 
mis-aligning the rest of the content and then removing the final cell. 
Screenshot attached of the current page.  (was: The documentation page for 
configuring hints contains a misaligned table of hint settings, caused the the 
hinted_handoff_disabled_datacenters row, which shifts all columns 1 further, 
mis-aligning the rest of the content and then removing the final cell. 
Screenshot attached of the current page.)

> Hint documentation page has a misaligned table of settings / description / 
> default values
> -
>
> Key: CASSANDRA-17346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17346
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Andrew Hogg
>Assignee: Andrew Hogg
>Priority: Normal
> Attachments: Screenshot 2022-02-03 at 21.17.38.png
>
>
> Within the versioned documentation, the page for configuring hints contains a 
> misaligned table of hint settings, caused the the 
> hinted_handoff_disabled_datacenters row, which shifts all columns 1 further, 
> mis-aligning the rest of the content and then removing the final cell. 
> Screenshot attached of the current page.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17346) Hint documentation page has a misaligned table of settings / description / default values

[Andrew Hogg (Jira)]

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

Andrew Hogg updated CASSANDRA-17346:

Description: Within the versioned documentation, the page for configuring 
hints contains a misaligned table of hint settings, caused the the 
hinted_handoff_disabled_datacenters row, which shifts all columns 1 further, 
mis-aligning the rest of the content and then removing the final cell. 
Screenshot attached of the star of the misalignment on the table.  (was: Within 
the versioned documentation, the page for configuring hints contains a 
misaligned table of hint settings, caused the the 
hinted_handoff_disabled_datacenters row, which shifts all columns 1 further, 
mis-aligning the rest of the content and then removing the final cell. 
Screenshot attached of the current page.)

> Hint documentation page has a misaligned table of settings / description / 
> default values
> -
>
> Key: CASSANDRA-17346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17346
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Andrew Hogg
>Assignee: Andrew Hogg
>Priority: Normal
> Attachments: Screenshot 2022-02-03 at 21.17.38.png
>
>
> Within the versioned documentation, the page for configuring hints contains a 
> misaligned table of hint settings, caused the the 
> hinted_handoff_disabled_datacenters row, which shifts all columns 1 further, 
> mis-aligning the rest of the content and then removing the final cell. 
> Screenshot attached of the star of the misalignment on the table.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17346) Hint documentation page has a misaligned table of settings / description / default values

[Andrew Hogg (Jira)]

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

Andrew Hogg updated CASSANDRA-17346:

Impacts: Docs  (was: None)

> Hint documentation page has a misaligned table of settings / description / 
> default values
> -
>
> Key: CASSANDRA-17346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17346
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Andrew Hogg
>Assignee: Andrew Hogg
>Priority: Normal
> Attachments: Screenshot 2022-02-03 at 21.17.38.png
>
>
> Within the versioned documentation, the page for configuring hints contains a 
> misaligned table of hint settings, caused the the 
> hinted_handoff_disabled_datacenters row, which shifts all columns 1 further, 
> mis-aligning the rest of the content and then removing the final cell. 
> Screenshot attached of the star of the misalignment on the table.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17256) Fixes for intermittent in-JVM dtest failures

[Jon Meredith (Jira)]

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

Jon Meredith updated CASSANDRA-17256:
-
Authors: Benedict Elliott Smith, Caleb Rackliffe, Jon Meredith, 
Marcus Eriksson  (was: Caleb Rackliffe, Jon Meredith, Marcus Eriksson)
  Fix Version/s: 3.0.26
 3.11.12
 4.0.2
 4.1
 (was: 3.0.x)
 (was: 4.x)
 (was: 3.11.x)
 (was: 4.0.x)
  Since Version: 3.0.19
Source Control Link: 
https://github.com/apache/cassandra/commit/1413dbebc398af55df267f92c397d537ee4bef82
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> Fixes for intermittent in-JVM dtest failures
> 
>
> Key: CASSANDRA-17256
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17256
> Project: Cassandra
>  Issue Type: Bug
>  Components: Test/dtest/java
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2, 4.1
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Improvements to StreamingTransferTest, MixedModeMessageForwardTest and 
> SchemaDisagreementTest flakes.
> For 3.0, adopt the ring settling properties used on trunk. For all releases 
> increase to 15s for ring settling.
> For all branches, disable autocompaction during shutdown.
> For 4.0 and up, shut down the scheduled executors a little later.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17090) CEP-15: Accord Prototype

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17090:
---
Epic Name: Accord Prototype

> CEP-15: Accord Prototype
> 
>
> Key: CASSANDRA-17090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17090
> Project: Cassandra
>  Issue Type: Epic
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17090) CEP-15: Accord Prototype

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17090:
---
Issue Type: Epic  (was: New Feature)

> CEP-15: Accord Prototype
> 
>
> Key: CASSANDRA-17090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17090
> Project: Cassandra
>  Issue Type: Epic
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17090) CEP-15: Accord Prototype

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17090:
---
Epic Link: (was: CASSANDRA-17089)

> CEP-15: Accord Prototype
> 
>
> Key: CASSANDRA-17090
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17090
> Project: Cassandra
>  Issue Type: Epic
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Assigned] (CASSANDRA-17346) Hint documentation page has a misaligned table of settings / description / default values

[Andrew Hogg (Jira)]

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

Andrew Hogg reassigned CASSANDRA-17346:
---

Assignee: Andrew Hogg

> Hint documentation page has a misaligned table of settings / description / 
> default values
> -
>
> Key: CASSANDRA-17346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17346
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation/Website
>Reporter: Andrew Hogg
>Assignee: Andrew Hogg
>Priority: Normal
> Attachments: Screenshot 2022-02-03 at 21.17.38.png
>
>
> Within the versioned documentation, the page for configuring hints contains a 
> misaligned table of hint settings, caused the the 
> hinted_handoff_disabled_datacenters row, which shifts all columns 1 further, 
> mis-aligning the rest of the content and then removing the final cell. 
> Screenshot attached of the star of the misalignment on the table.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17092) CEP-15: Accord Beta

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17092:
---
Change Category: Semantic
 Complexity: Byzantine
Component/s: Accord
 Status: Open  (was: Triage Needed)

> CEP-15: Accord Beta
> ---
>
> Key: CASSANDRA-17092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17092
> Project: Cassandra
>  Issue Type: Epic
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Assigned] (CASSANDRA-17092) CEP-15: Accord Beta

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith reassigned CASSANDRA-17092:
--

Assignee: Benedict Elliott Smith

> CEP-15: Accord Beta
> ---
>
> Key: CASSANDRA-17092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17092
> Project: Cassandra
>  Issue Type: Epic
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17092) CEP-15: Accord Beta

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17092:
---
  Epic Name: CEP-15: Accord Beta
Epic Status: To Do
 Issue Type: Epic  (was: New Feature)

> CEP-15: Accord Beta
> ---
>
> Key: CASSANDRA-17092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17092
> Project: Cassandra
>  Issue Type: Epic
>Reporter: Benedict Elliott Smith
>Priority: Normal
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17092) CEP-15: Accord Beta

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17092:
---
Epic Link: (was: CASSANDRA-17089)

> CEP-15: Accord Beta
> ---
>
> Key: CASSANDRA-17092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17092
> Project: Cassandra
>  Issue Type: Epic
>Reporter: Benedict Elliott Smith
>Priority: Normal
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17318) Runtime-configurable YAML option to prohibit USE statements

[Caleb Rackliffe (Jira)]

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

Caleb Rackliffe updated CASSANDRA-17318:

Test and Documentation Plan: 
- new cassandra.yaml option w/ inline documentation
- new metrics around USE statement usage
- new CQLTester tests to verify enable/disable
 Status: Patch Available  (was: In Progress)

trunk PR: https://github.com/apache/cassandra/pull/1437
CircleCI: 
https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-17318-4.1=all

> Runtime-configurable YAML option to prohibit USE statements
> ---
>
> Key: CASSANDRA-17318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17318
> Project: Cassandra
>  Issue Type: Improvement
>  Components: CQL/Syntax
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
>
> The ambiguity around prepared statements without fully qualified table names 
> has led to a number of sub-optimal outcomes for our users. With 
> CASSANDRA-15252 and CASSANDRA-17248 resolved, there aren't any lingering 
> _known_ issues, but operators may still want to cordon {{USE}} statements off 
> completely. This is especially important if we plan to deprecate and remove 
> {{USE}} at some point in the future.
> A couple details...
> 1.) The new option will be opt-in.
> 2.) It will be possible to change at runtime.
> 3.) There will be a new metric for {{USE}} that tells us whether it's been 
> used at all. (This should make it easier to disable {{USE}} for an existing 
> cluster where we don't know a-priori that it isn't in play.)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[cassandra] branch cassandra-4.0 updated (67f913a -> 965fe0d)

[jonmeredith]

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

jonmeredith pushed a change to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git.


from 67f913a  Merge branch 'cassandra-3.11' into cassandra-4.0
 new 9ff28fc  Fixes for intermittent in-JVM dtest failures
 new beb4563  Merge branch 'cassandra-3.0' into cassandra-3.11
 new 965fe0d  Merge branch 'cassandra-3.11' into cassandra-4.0

The 3 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:
 .../apache/cassandra/service/StorageService.java   | 14 --
 .../cassandra/distributed/impl/Instance.java   |  9 ++--
 .../distributed/test/ring/AutoBootstrapTest.java   | 56 ++
 .../distributed/test/ring/BootstrapTest.java   | 20 
 .../cassandra/streaming/StreamingTransferTest.java |  2 +-
 5 files changed, 73 insertions(+), 28 deletions(-)
 create mode 100644 
test/distributed/org/apache/cassandra/distributed/test/ring/AutoBootstrapTest.java

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

[cassandra] branch trunk updated (35dbcc2 -> 6614c08)

[jonmeredith]

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

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


from 35dbcc2  CASSANDRA-15215 Use DataOutputPlus.writeBytes in 
VIntCoding.writeUnsignedVInt
 new 9ff28fc  Fixes for intermittent in-JVM dtest failures
 new beb4563  Merge branch 'cassandra-3.0' into cassandra-3.11
 new 965fe0d  Merge branch 'cassandra-3.11' into cassandra-4.0
 new 6614c08  Merge branch 'cassandra-4.0' into trunk

The 4 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:
 .../org/apache/cassandra/io/util/PathUtils.java| 55 -
 .../apache/cassandra/service/StorageService.java   | 17 +--
 .../cassandra/utils/NativeLibraryDarwin.java   |  1 +
 .../apache/cassandra/utils/NativeLibraryLinux.java |  1 +
 .../cassandra/utils/NativeLibraryWindows.java  |  1 +
 .../cassandra/utils/NativeLibraryWrapper.java  |  3 +-
 .../cassandra/distributed/impl/Instance.java   | 21 +++-
 .../distributed/test/ring/AutoBootstrapTest.java   | 56 ++
 .../distributed/test/ring/BootstrapTest.java   | 20 
 .../cassandra/streaming/StreamingTransferTest.java |  2 +-
 10 files changed, 148 insertions(+), 29 deletions(-)
 create mode 100644 
test/distributed/org/apache/cassandra/distributed/test/ring/AutoBootstrapTest.java

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

[cassandra] branch cassandra-3.11 updated (bfab1fd -> beb4563)

[jonmeredith]

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

jonmeredith pushed a change to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git.


from bfab1fd  Merge branch 'cassandra-3.0' into cassandra-3.11
 new 9ff28fc  Fixes for intermittent in-JVM dtest failures
 new beb4563  Merge branch 'cassandra-3.0' into cassandra-3.11

The 2 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:
 src/java/org/apache/cassandra/service/StorageService.java  | 14 ++
 .../apache/cassandra/distributed/impl/AbstractCluster.java |  8 +++-
 .../org/apache/cassandra/distributed/impl/Instance.java| 10 ++
 .../org/apache/cassandra/distributed/test/GossipTest.java  |  3 ---
 4 files changed, 27 insertions(+), 8 deletions(-)

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

[cassandra] branch cassandra-3.0 updated: Fixes for intermittent in-JVM dtest failures

[jonmeredith]

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

jonmeredith pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git


The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
 new 9ff28fc  Fixes for intermittent in-JVM dtest failures
9ff28fc is described below

commit 9ff28fc717e7926b5cf7c8acc85a35e0cfb43595
Author: Jon Meredith 
AuthorDate: Wed Feb 2 17:09:42 2022 -0700

Fixes for intermittent in-JVM dtest failures

patch by Jon Meredith, Caleb Rackliffe, Marcus Eriksson, Benedict Elliott 
Smith ; reviewed by Caleb Rackliffe for CASSANDRA-17256
---
 src/java/org/apache/cassandra/service/StorageService.java  | 14 ++
 .../apache/cassandra/distributed/impl/AbstractCluster.java |  8 +++-
 .../org/apache/cassandra/distributed/impl/Instance.java| 10 ++
 .../org/apache/cassandra/distributed/test/GossipTest.java  |  3 ---
 .../distributed/upgrade/CompactStorage2to3UpgradeTest.java |  3 ++-
 .../apache/cassandra/streaming/StreamingTransferTest.java  |  2 +-
 6 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/src/java/org/apache/cassandra/service/StorageService.java 
b/src/java/org/apache/cassandra/service/StorageService.java
index 78d1120..22040c1 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -4389,10 +4389,7 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 if (!isFinalShutdown)
 setMode(Mode.DRAINING, "flushing column families", false);
 
-// disable autocompaction - we don't want to start any new 
compactions while we are draining
-for (Keyspace keyspace : Keyspace.all())
-for (ColumnFamilyStore cfs : keyspace.getColumnFamilyStores())
-cfs.disableAutoCompaction();
+disableAutoCompaction();
 
 // count CFs first, since forceFlush could block for the 
flushWriter to get a queue slot empty
 totalCFs = 0;
@@ -4465,6 +4462,15 @@ public class StorageService extends 
NotificationBroadcasterSupport implements IE
 }
 }
 
+@VisibleForTesting
+public void disableAutoCompaction()
+{
+// disable autocompaction - we don't want to start any new compactions 
while we are draining
+for (Keyspace keyspace : Keyspace.all())
+for (ColumnFamilyStore cfs : keyspace.getColumnFamilyStores())
+cfs.disableAutoCompaction();
+}
+
 /**
  * Some services are shutdown during draining and we should not attempt to 
start them again.
  *
diff --git 
a/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java 
b/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java
index ede075f..83dbfbc 100644
--- 
a/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java
+++ 
b/test/distributed/org/apache/cassandra/distributed/impl/AbstractCluster.java
@@ -195,9 +195,15 @@ public abstract class AbstractCluster 
implements ICluster {
 try
 {
+if (config.has(GOSSIP))
+{
+// TODO: hacky
+System.setProperty("cassandra.ring_delay_ms", "15000");
+System.setProperty("cassandra.consistent.rangemovement", 
"false");
+
System.setProperty("cassandra.consistent.simultaneousmoves.allow", "true");
+}
+
 mkdirs();
 
 assert 
config.networkTopology().contains(config.broadcastAddress());
@@ -768,6 +776,8 @@ public class Instance extends IsolatedExecutor implements 
IInvokableInstance
 );
 }
 
+error = parallelRun(error, executor, 
StorageService.instance::disableAutoCompaction);
+
 error = parallelRun(error, executor,
 () -> 
Gossiper.instance.stopShutdownAndWait(1L, MINUTES),
 CompactionManager.instance::forceShutdown,
diff --git 
a/test/distributed/org/apache/cassandra/distributed/test/GossipTest.java 
b/test/distributed/org/apache/cassandra/distributed/test/GossipTest.java
index ba6027b..0cff2b0 100644
--- a/test/distributed/org/apache/cassandra/distributed/test/GossipTest.java
+++ b/test/distributed/org/apache/cassandra/distributed/test/GossipTest.java
@@ -61,9 +61,6 @@ public class GossipTest extends TestBaseImpl
 public void nodeDownDuringMove() throws Throwable
 {
 int liveCount = 1;
-System.setProperty("cassandra.ring_delay_ms", "5000"); // down from 
30s default
-System.setProperty("cassandra.consistent.rangemovement", "false");
-System.setProperty("cassandra.consistent.simultaneousmoves.allow", 
"true");
 try (Cluster cluster = Cluster.build(2 + liveCount)
 

[cassandra] 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0

[jonmeredith]

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

jonmeredith pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git

commit 965fe0decf4a354cafeffc33cddadc6d103de45d
Merge: 67f913a beb4563
Author: Jon Meredith 
AuthorDate: Thu Feb 3 14:26:11 2022 -0700

Merge branch 'cassandra-3.11' into cassandra-4.0

 .../apache/cassandra/service/StorageService.java   | 14 --
 .../cassandra/distributed/impl/Instance.java   |  9 ++--
 .../distributed/test/ring/AutoBootstrapTest.java   | 56 ++
 .../distributed/test/ring/BootstrapTest.java   | 20 
 .../cassandra/streaming/StreamingTransferTest.java |  2 +-
 5 files changed, 73 insertions(+), 28 deletions(-)

diff --cc src/java/org/apache/cassandra/service/StorageService.java
index d78e0e8,49f3835..45fa119
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@@ -4977,10 -4686,7 +4977,8 @@@ public class StorageService extends Not
  if (!isFinalShutdown)
  setMode(Mode.DRAINING, "flushing column families", false);
  
- // disable autocompaction - we don't want to start any new 
compactions while we are draining
- for (Keyspace keyspace : Keyspace.all())
- for (ColumnFamilyStore cfs : keyspace.getColumnFamilyStores())
- cfs.disableAutoCompaction();
++// we don't want to start any new compactions while we are 
draining
+ disableAutoCompaction();
  
  // count CFs first, since forceFlush could block for the 
flushWriter to get a queue slot empty
  totalCFs = 0;
@@@ -5059,6 -4765,6 +5057,14 @@@
  }
  }
  
++@VisibleForTesting
++public void disableAutoCompaction()
++{
++for (Keyspace keyspace : Keyspace.all())
++for (ColumnFamilyStore cfs : keyspace.getColumnFamilyStores())
++cfs.disableAutoCompaction();
++}
++
  /**
   * Add a runnable which will be called before shut down or drain. This is 
useful for other
   * applications running in the same JVM which may want to shut down first 
rather than time
diff --cc test/distributed/org/apache/cassandra/distributed/impl/Instance.java
index 39ba770,1859742..9ea6d01
--- a/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
+++ b/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
@@@ -721,25 -739,19 +723,26 @@@ public class Instance extends IsolatedE
  () -> 
SecondaryIndexManager.shutdownAndWait(1L, MINUTES),
  () -> 
IndexSummaryManager.instance.shutdownAndWait(1L, MINUTES),
  () -> 
ColumnFamilyStore.shutdownExecutorsAndWait(1L, MINUTES),
 -() -> 
PendingRangeCalculatorService.instance.shutdownExecutor(1L, MINUTES),
 -() -> BufferPool.shutdownLocalCleaner(1L, 
MINUTES),
 +() -> 
PendingRangeCalculatorService.instance.shutdownAndWait(1L, MINUTES),
 +() -> BufferPools.shutdownLocalCleaner(1L, 
MINUTES),
  () -> Ref.shutdownReferenceReaper(1L, 
MINUTES),
  () -> 
Memtable.MEMORY_POOL.shutdownAndWait(1L, MINUTES),
 +() -> 
DiagnosticSnapshotService.instance.shutdownAndWait(1L, MINUTES),
 +() -> ScheduledExecutors.shutdownAndWait(1L, 
MINUTES),
  () -> SSTableReader.shutdownBlocking(1L, 
MINUTES),
- () -> 
shutdownAndWait(Collections.singletonList(ActiveRepairService.repairCommandExecutor())),
- () -> ScheduledExecutors.shutdownAndWait(1L, 
MINUTES)
 -() -> 
DiagnosticSnapshotService.instance.shutdownAndWait(1L, MINUTES)
++() -> 
shutdownAndWait(Collections.singletonList(ActiveRepairService.repairCommandExecutor()))
  );
 +
++error = parallelRun(error, executor, () -> 
ScheduledExecutors.shutdownAndWait(1L, MINUTES));
++
  error = parallelRun(error, executor,
 -() -> ScheduledExecutors.shutdownAndWait(1L, 
MINUTES),
 -(IgnoreThrowingRunnable) 
MessagingService.instance()::shutdown
 +CommitLog.instance::shutdownBlocking,
 +// can only shutdown message once, so if the 
test shutsdown an instance, then ignore the failure
 +(IgnoreThrowingRunnable) () -> 
MessagingService.instance().shutdown(1L, MINUTES, false, true)
  );
  error = parallelRun(error, executor,
 -() -> 

[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11

[jonmeredith]

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

jonmeredith pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git

commit beb456305af307b20376b0190fea6c33d6b38ac6
Merge: bfab1fd 9ff28fc
Author: Jon Meredith 
AuthorDate: Thu Feb 3 14:22:52 2022 -0700

Merge branch 'cassandra-3.0' into cassandra-3.11

 src/java/org/apache/cassandra/service/StorageService.java  | 14 ++
 .../apache/cassandra/distributed/impl/AbstractCluster.java |  8 +++-
 .../org/apache/cassandra/distributed/impl/Instance.java| 10 ++
 .../org/apache/cassandra/distributed/test/GossipTest.java  |  3 ---
 4 files changed, 27 insertions(+), 8 deletions(-)

diff --cc src/java/org/apache/cassandra/service/StorageService.java
index 1a0d5b0,22040c1..49f3835
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@@ -4760,61 -4460,17 +4757,70 @@@ public class StorageService extends Not
  {
  logger.error("Caught an exception while draining ", t);
  }
 +finally
 +{
 +Throwable postShutdownHookThrowable = Throwables.perform(null, 
postShutdownHooks.stream().map(h -> h::run));
 +if (postShutdownHookThrowable != null)
 +logger.error("Post-shutdown hooks returned exception", 
postShutdownHookThrowable);
 +}
 +}
 +
 +/**
 + * Add a runnable which will be called before shut down or drain. This is 
useful for other
 + * applications running in the same JVM which may want to shut down first 
rather than time
 + * out attempting to use Cassandra calls which will no longer work.
 + * @param hook: the code to run
 + * @return true on success, false if Cassandra is already shutting down, 
in which case the runnable
 + * has NOT been added.
 + */
 +public synchronized boolean addPreShutdownHook(Runnable hook)
 +{
 +if (!isDraining() && !isDrained())
 +return preShutdownHooks.add(hook);
 +
 +return false;
 +}
 +
 +/**
 + * Remove a preshutdown hook
 + */
 +public synchronized boolean removePreShutdownHook(Runnable hook)
 +{
 +return preShutdownHooks.remove(hook);
 +}
 +
 +/**
 + * Add a runnable which will be called after shutdown or drain. This is 
useful for other applications
 + * running in the same JVM that Cassandra needs to work and should shut 
down later.
 + * @param hook: the code to run
 + * @return true on success, false if Cassandra is already shutting down, 
in which case the runnable has NOT been
 + * added.
 + */
 +public synchronized boolean addPostShutdownHook(Runnable hook)
 +{
 +if (!isDraining() && !isDrained())
 +return postShutdownHooks.add(hook);
 +
 +return false;
 +}
 +
 +/**
 + * Remove a postshutdownhook
 + */
 +public synchronized boolean removePostShutdownHook(Runnable hook)
 +{
 +return postShutdownHooks.remove(hook);
  }
  
+ @VisibleForTesting
+ public void disableAutoCompaction()
+ {
+ // disable autocompaction - we don't want to start any new 
compactions while we are draining
+ for (Keyspace keyspace : Keyspace.all())
+ for (ColumnFamilyStore cfs : keyspace.getColumnFamilyStores())
+ cfs.disableAutoCompaction();
+ }
+ 
  /**
   * Some services are shutdown during draining and we should not attempt 
to start them again.
   *
diff --cc test/distributed/org/apache/cassandra/distributed/impl/Instance.java
index 80728e2,776def3..1859742
--- a/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
+++ b/test/distributed/org/apache/cassandra/distributed/impl/Instance.java
@@@ -717,8 -770,14 +725,10 @@@ public class Instance extends IsolatedE
  if (config.has(GOSSIP) || config.has(NETWORK))
  {
  StorageService.instance.shutdownServer();
 -
 -error = parallelRun(error, executor,
 -() -> 
NanoTimeToCurrentTimeMillis.shutdown(MINUTES.toMillis(1L))
 -);
  }
  
+ error = parallelRun(error, executor, 
StorageService.instance::disableAutoCompaction);
+ 
  error = parallelRun(error, executor,
  () -> 
Gossiper.instance.stopShutdownAndWait(1L, MINUTES),
  CompactionManager.instance::forceShutdown,

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

[jira] [Assigned] (CASSANDRA-17346) Hint documentation page has a misaligned table of settings / description / default values

[Andrew Hogg (Jira)]

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

Andrew Hogg reassigned CASSANDRA-17346:
---

Assignee: (was: Andrew Hogg)

> Hint documentation page has a misaligned table of settings / description / 
> default values
> -
>
> Key: CASSANDRA-17346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17346
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation/Website
>Reporter: Andrew Hogg
>Priority: Normal
> Attachments: Screenshot 2022-02-03 at 21.17.38.png
>
>
> Within the versioned documentation, the page for configuring hints contains a 
> misaligned table of hint settings, caused the the 
> hinted_handoff_disabled_datacenters row, which shifts all columns 1 further, 
> mis-aligning the rest of the content and then removing the final cell. 
> Screenshot attached of the star of the misalignment on the table.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] (CASSANDRA-17346) Hint documentation page has a misaligned table of settings / description / default values

[Andrew Hogg (Jira)]

[ https://issues.apache.org/jira/browse/CASSANDRA-17346 ]


Andrew Hogg deleted comment on CASSANDRA-17346:
-

was (Author: JIRAUSER283995):
PR exists : https://github.com/apache/cassandra/pull/1424

> Hint documentation page has a misaligned table of settings / description / 
> default values
> -
>
> Key: CASSANDRA-17346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17346
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation/Website
>Reporter: Andrew Hogg
>Priority: Normal
> Attachments: Screenshot 2022-02-03 at 21.17.38.png
>
>
> Within the versioned documentation, the page for configuring hints contains a 
> misaligned table of hint settings, caused the the 
> hinted_handoff_disabled_datacenters row, which shifts all columns 1 further, 
> mis-aligning the rest of the content and then removing the final cell. 
> Screenshot attached of the star of the misalignment on the table.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17106) CEP-15: (C*) Live migration from Paxos

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17106:
---
Epic Link: CASSANDRA-17089

> CEP-15: (C*) Live migration from Paxos
> --
>
> Key: CASSANDRA-17106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17106
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> We need to support safe live migration from Paxos to Accord



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17112) CEP-15: (C*) Strict Serializability verification

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17112:
---
Parent: (was: CASSANDRA-17092)
Issue Type: New Feature  (was: Sub-task)

> CEP-15: (C*) Strict Serializability verification
> 
>
> Key: CASSANDRA-17112
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17112
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17108) CEP-15: (C*) Integration with Schema

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17108:
---
Epic Link: CASSANDRA-17089

> CEP-15: (C*) Integration with Schema
> 
>
> Key: CASSANDRA-17108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17108
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> This ticket is a placeholder for integrating with future evolution of the 
> Schema layer to determine consistency levels for transactions etc.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17111) CEP-15: (Accord) Transaction dependencies must include at most the txnId

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17111:
---
Parent: (was: CASSANDRA-17092)
Issue Type: New Feature  (was: Sub-task)

> CEP-15: (Accord) Transaction dependencies must include at most the txnId
> 
>
> Key: CASSANDRA-17111
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17111
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> Today we must ship the entire transaction as part of the dependencies we 
> share. This is very costly. We may ship only the {{txnId,primary shard key}} 
> if we modify recovery to first discover the original transaction, or 
> invalidate it if it cannot be found.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17110) CEP-15: (Accord) Transaction outcomes must be replicated to an optimal number of replicas

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17110:
---
Parent: (was: CASSANDRA-17092)
Issue Type: New Feature  (was: Sub-task)

> CEP-15: (Accord) Transaction outcomes must be replicated to an optimal number 
> of replicas
> -
>
> Key: CASSANDRA-17110
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17110
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> Transaction outcomes that are defined by the transaction should not be 
> replicated, and outcomes that are computed from existing records (and as such 
> were not replicated as part of the original transaction) should only be 
> replicated to a single primary shard. This complicates execution, however, 
> without MVCC as the shards from which we had to read the original value 
> cannot delete their state until they know the updated value is replicated 
> durably. One simple option here might be to replicate any new values only to 
> those shards on whom the value's computation depended, so that any shard that 
> receives this new value is safely able to report what the outcome of the 
> transaction is (but is unable to participate in a recomputation of that part 
> of the transaction).



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17106) CEP-15: (C*) Live migration from Paxos

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17106:
---
Parent: (was: CASSANDRA-17092)
Issue Type: New Feature  (was: Sub-task)

> CEP-15: (C*) Live migration from Paxos
> --
>
> Key: CASSANDRA-17106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17106
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> We need to support safe live migration from Paxos to Accord



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17107) CEP-15: (C*/Accord) Reorder Buffer

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17107:
---
Parent: (was: CASSANDRA-17092)
Issue Type: New Feature  (was: Sub-task)

> CEP-15: (C*/Accord) Reorder Buffer
> --
>
> Key: CASSANDRA-17107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17107
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> This work encompasses the one round-trip optimisation outlined in the Accord 
> whitepaper



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17112) CEP-15: (C*) Strict Serializability verification

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17112:
---
Epic Link: CASSANDRA-17089

> CEP-15: (C*) Strict Serializability verification
> 
>
> Key: CASSANDRA-17112
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17112
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17108) CEP-15: (C*) Integration with Schema

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17108:
---
Parent: (was: CASSANDRA-17092)
Issue Type: New Feature  (was: Sub-task)

> CEP-15: (C*) Integration with Schema
> 
>
> Key: CASSANDRA-17108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17108
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> This ticket is a placeholder for integrating with future evolution of the 
> Schema layer to determine consistency levels for transactions etc.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17092) CEP-15: Accord Beta

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17092:
---
Summary: CEP-15: Accord Beta  (was: CEP-15: Beta)

> CEP-15: Accord Beta
> ---
>
> Key: CASSANDRA-17092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17092
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Benedict Elliott Smith
>Priority: Normal
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17111) CEP-15: (Accord) Transaction dependencies must include at most the txnId

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17111:
---
Epic Link: CASSANDRA-17089

> CEP-15: (Accord) Transaction dependencies must include at most the txnId
> 
>
> Key: CASSANDRA-17111
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17111
> Project: Cassandra
>  Issue Type: New Feature
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> Today we must ship the entire transaction as part of the dependencies we 
> share. This is very costly. We may ship only the {{txnId,primary shard key}} 
> if we modify recovery to first discover the original transaction, or 
> invalidate it if it cannot be found.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17109) CEP-15: (Accord) Transactions must be replicated to an optimal number of replicas

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17109:
---
Parent: (was: CASSANDRA-17092)
Issue Type: New Feature  (was: Sub-task)

> CEP-15: (Accord) Transactions must be replicated to an optimal number of 
> replicas
> -
>
> Key: CASSANDRA-17109
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17109
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> Today Accord sends the complete transaction to every shard. This is 
> unnecessary, Accord should instead nominate a single primary shard to 
> replicate the transaction, with the other shards receiving only the 
> {{(txnId,primary shard key)}} tuple as part of PreAccept.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17107) CEP-15: (C*/Accord) Reorder Buffer

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17107:
---
Epic Link: CASSANDRA-17089

> CEP-15: (C*/Accord) Reorder Buffer
> --
>
> Key: CASSANDRA-17107
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17107
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> This work encompasses the one round-trip optimisation outlined in the Accord 
> whitepaper



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-15941) Upgrade to lz4-java 1.8

[Brandon Williams (Jira)]

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

Brandon Williams updated CASSANDRA-15941:
-
Resolution: Duplicate
Status: Resolved  (was: Open)

> Upgrade to lz4-java 1.8
> ---
>
> Key: CASSANDRA-15941
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15941
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: David Capwell
>Assignee: Savni Nagarkar
>Priority: Normal
> Fix For: 4.x
>
>
> After upgrading lz4-java I saw that CentOS 6 was no longer supported via 
> native and filed a ticket https://github.com/lz4/lz4-java/issues/163 on the 
> lz4-java project.  This ticket is now closed and targeted for the next lz4 
> release (assume to be 1.7.2); once this release comes out we should upgrade.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-15941) Upgrade to lz4-java 1.8

[Brandon Williams (Jira)]

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

Brandon Williams updated CASSANDRA-15941:
-
Resolution: (was: Fixed)
Status: Open  (was: Resolved)

> Upgrade to lz4-java 1.8
> ---
>
> Key: CASSANDRA-15941
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15941
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: David Capwell
>Assignee: Savni Nagarkar
>Priority: Normal
> Fix For: 4.x
>
>
> After upgrading lz4-java I saw that CentOS 6 was no longer supported via 
> native and filed a ticket https://github.com/lz4/lz4-java/issues/163 on the 
> lz4-java project.  This ticket is now closed and targeted for the next lz4 
> release (assume to be 1.7.2); once this release comes out we should upgrade.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-17116) When streaming sees a ClosedChannelException this triggers the disk failure policy

[David Capwell (Jira)]

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

David Capwell commented on CASSANDRA-17116:
---

Aborted commit due to change in AbstractCluster breaking a few upgrade tests.  
Also found out that some upgrade tests don't actually test against trunk... so 
fixing...

> When streaming sees a ClosedChannelException this triggers the disk failure 
> policy
> --
>
> Key: CASSANDRA-17116
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17116
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Streaming
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Found in CASSANDRA-17085.
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7264
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7256
> {code}
> ERROR [Stream-Deserializer-/127.0.0.1:7000-f2eb1a15] 2021-11-02 21:35:40,983 
> DefaultFSErrorHandler.java:104 - Exiting forcefully due to file system 
> exception on startup, disk failure policy "stop"
> org.apache.cassandra.io.FSWriteError: java.nio.channels.ClosedChannelException
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:227)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.writeComponent(BigTableZeroCopyWriter.java:206)
>   at 
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:125)
>   at 
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:84)
>   at 
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:51)
>   at 
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:37)
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)
>   at 
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:62)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.channels.ClosedChannelException: null
>   at 
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:136)
>   at 
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:155)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:217)
>   ... 9 common frames omitted
> {code}
> When bootstrap fails and streaming is closed, this triggers the disk failure 
> policy which causes the JVM to halt by default (if this happens outside of 
> bootstrap, then we stop transports and keep the JVM up).
> org.apache.cassandra.streaming.StreamDeserializingTask attempts to handle 
> this by ignoring this exception, but the call to 
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize
>  Does try/catch and inspects exception; triggering this condition.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-17116) When streaming sees a ClosedChannelException this triggers the disk failure policy

[David Capwell (Jira)]

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

David Capwell commented on CASSANDRA-17116:
---

Starting commit

CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-17116-trunk-9F17D44F-1990-4FA1-B04B-B908D0533DF7]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-17116-trunk-9F17D44F-1990-4FA1-B04B-B908D0533DF7]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1398/]|


> When streaming sees a ClosedChannelException this triggers the disk failure 
> policy
> --
>
> Key: CASSANDRA-17116
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17116
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Streaming
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Found in CASSANDRA-17085.
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7264
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7256
> {code}
> ERROR [Stream-Deserializer-/127.0.0.1:7000-f2eb1a15] 2021-11-02 21:35:40,983 
> DefaultFSErrorHandler.java:104 - Exiting forcefully due to file system 
> exception on startup, disk failure policy "stop"
> org.apache.cassandra.io.FSWriteError: java.nio.channels.ClosedChannelException
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:227)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.writeComponent(BigTableZeroCopyWriter.java:206)
>   at 
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:125)
>   at 
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:84)
>   at 
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:51)
>   at 
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:37)
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)
>   at 
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:62)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.channels.ClosedChannelException: null
>   at 
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:136)
>   at 
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:155)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:217)
>   ... 9 common frames omitted
> {code}
> When bootstrap fails and streaming is closed, this triggers the disk failure 
> policy which causes the JVM to halt by default (if this happens outside of 
> bootstrap, then we stop transports and keep the JVM up).
> org.apache.cassandra.streaming.StreamDeserializingTask attempts to handle 
> this by ignoring this exception, but the call to 
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize
>  Does try/catch and inspects exception; triggering this condition.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17116) When streaming sees a ClosedChannelException this triggers the disk failure policy

[David Capwell (Jira)]

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

David Capwell updated CASSANDRA-17116:
--
Status: Ready to Commit  (was: Review In Progress)

> When streaming sees a ClosedChannelException this triggers the disk failure 
> policy
> --
>
> Key: CASSANDRA-17116
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17116
> Project: Cassandra
>  Issue Type: Bug
>  Components: Consistency/Streaming
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Found in CASSANDRA-17085.
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7264
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7256
> {code}
> ERROR [Stream-Deserializer-/127.0.0.1:7000-f2eb1a15] 2021-11-02 21:35:40,983 
> DefaultFSErrorHandler.java:104 - Exiting forcefully due to file system 
> exception on startup, disk failure policy "stop"
> org.apache.cassandra.io.FSWriteError: java.nio.channels.ClosedChannelException
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:227)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.writeComponent(BigTableZeroCopyWriter.java:206)
>   at 
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:125)
>   at 
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:84)
>   at 
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:51)
>   at 
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:37)
>   at 
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)
>   at 
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:62)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.channels.ClosedChannelException: null
>   at 
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:136)
>   at 
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:155)
>   at 
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:217)
>   ... 9 common frames omitted
> {code}
> When bootstrap fails and streaming is closed, this triggers the disk failure 
> policy which causes the JVM to halt by default (if this happens outside of 
> bootstrap, then we stop transports and keep the JVM up).
> org.apache.cassandra.streaming.StreamDeserializingTask attempts to handle 
> this by ignoring this exception, but the call to 
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize
>  Does try/catch and inspects exception; triggering this condition.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17346) Hint documentation page has a misaligned table of settings / description / default values

[Andrew Hogg (Jira)]

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

Andrew Hogg updated CASSANDRA-17346:

 Bug Category: Parent values: Documentation(13562)
   Complexity: Low Hanging Fruit
Discovered By: User Report
Reviewers: Michael Semb Wever
 Severity: Low
   Status: Open  (was: Triage Needed)

> Hint documentation page has a misaligned table of settings / description / 
> default values
> -
>
> Key: CASSANDRA-17346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17346
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Andrew Hogg
>Assignee: Andrew Hogg
>Priority: Normal
> Attachments: Screenshot 2022-02-03 at 21.17.38.png
>
>
> The documentation page for configuring hints contains a misaligned table of 
> hint settings, caused the the hinted_handoff_disabled_datacenters row, which 
> shifts all columns 1 further, mis-aligning the rest of the content and then 
> removing the final cell. Screenshot attached of the current page.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17091) CEP-15: Cassandra Prototype

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17091:
---
  Epic Name: CEP-15: Cassandra Prototype
Epic Status: To Do
 Issue Type: Epic  (was: New Feature)

> CEP-15: Cassandra Prototype
> ---
>
> Key: CASSANDRA-17091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17091
> Project: Cassandra
>  Issue Type: Epic
>Reporter: Benedict Elliott Smith
>Priority: Normal
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17091) CEP-15: Cassandra Prototype

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17091:
---
Epic Link: (was: CASSANDRA-17089)

> CEP-15: Cassandra Prototype
> ---
>
> Key: CASSANDRA-17091
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17091
> Project: Cassandra
>  Issue Type: Epic
>Reporter: Benedict Elliott Smith
>Priority: Normal
>




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17103) CEP-15 (C*): Messaging and storage engine integration

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17103:
---
Epic Link: CASSANDRA-17091  (was: CASSANDRA-17089)

> CEP-15 (C*): Messaging and storage engine integration
> -
>
> Key: CASSANDRA-17103
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17103
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> This work encompasses implementing Accord’s storage and networking interfaces 
> within Cassandra, so that messages may be sent around the cluster and 
> exectuted



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Assigned] (CASSANDRA-15941) Upgrade to lz4-java 1.8

[Savni Nagarkar (Jira)]

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

Savni Nagarkar reassigned CASSANDRA-15941:
--

Assignee: Savni Nagarkar

> Upgrade to lz4-java 1.8
> ---
>
> Key: CASSANDRA-15941
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15941
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Build
>Reporter: David Capwell
>Assignee: Savni Nagarkar
>Priority: Normal
> Fix For: 4.x
>
>
> After upgrading lz4-java I saw that CentOS 6 was no longer supported via 
> native and filed a ticket https://github.com/lz4/lz4-java/issues/163 on the 
> lz4-java project.  This ticket is now closed and targeted for the next lz4 
> release (assume to be 1.7.2); once this release comes out we should upgrade.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Comment Edited] (CASSANDRA-17031) Add support for PEM based key material for SSL

[Maulin Vasavada (Jira)]

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

Maulin Vasavada edited comment on CASSANDRA-17031 at 2/4/22, 1:30 AM:
--

Thanks Stefan. Since I found a unit test failure on your CI which I had to make 
a fix for, I have cherry-picked your changes on my branch and once you see the 
recent change on the PR, I can squash the commits on my branch.

I started the Circle CI for validating unit tests on [Java 11 
|https://app.circleci.com/pipelines/github/maulin-vasavada/cassandra/80/workflows/2e5de77e-b57a-4415-941e-31981df53048]and
 [Java 
8|https://app.circleci.com/pipelines/github/maulin-vasavada/cassandra/80/workflows/2e3484c6-b418-499e-bf5f-c229786fc7df]
 to have good confidence before you run your build. So far Java 11 build has a 
failure unrelated to this changes.


was (Author: maulin.vasavada):
Thanks Stefan. Since I found a unit test failure on your CI which I had to make 
a fix for, I have cherry-picked your changes on my branch and once you see the 
recent change on the PR, I can squash the commits on my branch.

I've started the Circle CI for validating unit tests on [Java 11 
|https://app.circleci.com/pipelines/github/maulin-vasavada/cassandra/80/workflows/2e5de77e-b57a-4415-941e-31981df53048]and
 [Java 
8|https://app.circleci.com/pipelines/github/maulin-vasavada/cassandra/80/workflows/2e3484c6-b418-499e-bf5f-c229786fc7df]
 to have good confidence before you run your build.

> Add support for PEM based key material for SSL
> --
>
> Key: CASSANDRA-17031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17031
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Messaging/Internode
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1
>
>  Time Spent: 7h 50m
>  Remaining Estimate: 0h
>
> h1. Scope
> Currently Cassandra supports standard keystore types for SSL 
> keys/certificates. The scope of this enhancement is to add support for PEM 
> based key material (keys/certificate) given that PEM is widely used common 
> format for the same. We intend to add support for Unencrypted and Password 
> Based Encrypted (PBE) PKCS#8 formatted Private Keys in PEM format with 
> standard algorithms (RSA, DSA and EC) along with the certificate chain for 
> the private key and PEM based X509 certificates. The work here is going to be 
> built on top of [CEP-9: Make SSLContext creation 
> pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable]
>  for which the code is merged for Apache Cassandra 4.1 release.
> We intend to support the key material be configured as direct PEM values 
> input OR via the file (configured with keystore and truststore configurations 
> today). We are not going to model PEM as a valid 'store_type' given that 
> 'store_type' has a [specific 
> definition|https://docs.oracle.com/en/java/javase/11/security/java-cryptography-architecture-jca-reference-guide.html#GUID-AB51DEFD-5238-4F96-967F-082F6D34FBEA].
>  
> h1. Approach
> Create an implementation for 
> [ISslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/ISslContextFactory.java]
>  extending 
> [FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java]
>  implementation to add PEM formatted key/certificates.
> h1. Motivation
> PEM is a widely used format for encoding Private Keys and X.509 Certificates 
> and Apache Cassandra's current implementation lacks the support for 
> specifying the PEM formatted key material for SSL configurations. This means 
> operators have to re-create the key material to comply to the supported 
> formats (using key/trust store types - jks, pkcs12 etc) and deal with an 
> operational task for managing it. This is an operational overhead we can 
> avoid by supporting the PEM format making Apache Cassandra even more customer 
> friendly and drive more adoption.
> h1. Proposed Changes
>  # A new implementation for ISslContextFactory - PEMBasedSslContextFactory 
> with the following supported configuration
> {panel:title=New configurations}
> {panel}
> |{{encryption_options:  }}
>  {{}}{{ssl_context_factory:}}
>  {{}}{{class_name: 
> org.apache.cassandra.security.PEMBasedSslContextFactory}}
>  {{}}{{parameters:}}
>  {{  }}{{private_key:  certificate chain>}}
>  {{  }}{{private_key_password:  }}{{private}} {{key }}{{if}} {{it is encrypted>}}
>  {{  }}{{trusted_certificates: }}|
> *NOTE:* We could reuse 'keystore_password' instead of the 
> 'private_key_password'. However PEM encoded private key 

[jira] [Updated] (CASSANDRA-17346) Hint documentation page has a misaligned table of settings / description / default values

[Andrew Hogg (Jira)]

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

Andrew Hogg updated CASSANDRA-17346:

Component/s: Documentation/Website
 (was: Documentation)

> Hint documentation page has a misaligned table of settings / description / 
> default values
> -
>
> Key: CASSANDRA-17346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17346
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation/Website
>Reporter: Andrew Hogg
>Assignee: Andrew Hogg
>Priority: Normal
> Attachments: Screenshot 2022-02-03 at 21.17.38.png
>
>
> Within the versioned documentation, the page for configuring hints contains a 
> misaligned table of hint settings, caused the the 
> hinted_handoff_disabled_datacenters row, which shifts all columns 1 further, 
> mis-aligning the rest of the content and then removing the final cell. 
> Screenshot attached of the star of the misalignment on the table.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (CASSANDRA-17346) Hint documentation page has a misaligned table of settings / description / default values

[Andrew Hogg (Jira)]

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

Andrew Hogg commented on CASSANDRA-17346:
-

PR exists : https://github.com/apache/cassandra/pull/1424

> Hint documentation page has a misaligned table of settings / description / 
> default values
> -
>
> Key: CASSANDRA-17346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17346
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation/Website
>Reporter: Andrew Hogg
>Assignee: Andrew Hogg
>Priority: Normal
> Attachments: Screenshot 2022-02-03 at 21.17.38.png
>
>
> Within the versioned documentation, the page for configuring hints contains a 
> misaligned table of hint settings, caused the the 
> hinted_handoff_disabled_datacenters row, which shifts all columns 1 further, 
> mis-aligning the rest of the content and then removing the final cell. 
> Screenshot attached of the star of the misalignment on the table.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17097) CEP-15: (Accord) Track timestamp bounds between peers

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17097:
---
Epic Link: CASSANDRA-17090

> CEP-15: (Accord) Track timestamp bounds between peers
> -
>
> Key: CASSANDRA-17097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17097
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> Use Liveness / Repair system to maintain some global bounds on knowledge 
> dissemination to drive state GC, MVCC, and timed-out command invalidation



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17095) CEP-15: (Accord) Do not send redundant dependencies

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17095:
---
Epic Link: CASSANDRA-17090

> CEP-15: (Accord) Do not send redundant dependencies
> ---
>
> Key: CASSANDRA-17095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17095
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> Accord must prune its dependencies, so that only those that are not 
> transitively implied by the newest dependencies are propagated (and are not 
> known to be fully replicated).



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17099) CEP-15: (Accord) Invalidate commands that have not reached consensus

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17099:
---
Epic Link: CASSANDRA-17090

> CEP-15: (Accord) Invalidate commands that have not reached consensus
> 
>
> Key: CASSANDRA-17099
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17099
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> Ensure that commands that have only reached a minority may not re-appear at 
> some future date to be executed after some reasonable grace period has 
> elapsed. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17098) CEP-15: (Accord) Transaction State GC

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17098:
---
Epic Link: CASSANDRA-17090

> CEP-15: (Accord) Transaction State GC
> -
>
> Key: CASSANDRA-17098
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17098
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> Use global bounds on knowledge dissemination to excise data we no longer need



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17346) Hint documentation page has a misaligned table of settings / description / default values

[Andrew Hogg (Jira)]

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

Andrew Hogg updated CASSANDRA-17346:

Fix Version/s: 3.11.x
   4.0.x

> Hint documentation page has a misaligned table of settings / description / 
> default values
> -
>
> Key: CASSANDRA-17346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17346
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation/Website
>Reporter: Andrew Hogg
>Assignee: Andrew Hogg
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
> Attachments: Screenshot 2022-02-03 at 21.17.38.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Within the versioned documentation, the page for configuring hints contains a 
> misaligned table of hint settings, caused the the 
> hinted_handoff_disabled_datacenters row, which shifts all columns 1 further, 
> mis-aligning the rest of the content and then removing the final cell. 
> Screenshot attached of the star of the misalignment on the table.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17101) CEP-15: (C*) Topology integration

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17101:
---
Epic Link: CASSANDRA-17089

> CEP-15: (C*) Topology integration
> -
>
> Key: CASSANDRA-17101
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17101
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> Integrate Accord with Cassandra’s topology system: translate the ring to an 
> Accord topology, and integrate Accord with Bootstrap, Replace and Unbootstrap.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17100) CEP-15: (C*) Unique Per-Node Id for (Time)UUID

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17100:
---
Epic Link: CASSANDRA-17089

> CEP-15: (C*) Unique Per-Node Id for (Time)UUID
> --
>
> Key: CASSANDRA-17100
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17100
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> Negotiate a unique and persistent id for each node on joining the cluster 
> that is sufficiently compact to use for the  node part of a v2, v6 or v8 
> (Time)UUID, i.e. it should be at most 48 bits in length. In practice we 
> should be able to target 7, 14 or 21 bits in length depending on cluster 
> size, permitting more efficient vint encoding over the network and on disk.
> A seemingly simpler option for issuing UUID might be to use the NIC MAC 
> address, but this assumes each C* process has a unique NIC, and that all 
> nodes in the cluster are on the same network. This is likely often true, but 
> may not be universally, so we may need a mechanism for issuing unique IDs 
> when clashes occur, in which case it may be easier to just issue the most 
> compact ID we can in the first place.
> Accord will use this value directly as part of its {{Timestamp}} which is 
> very similar to a UUID but may have additional components. Accord may utilise 
> this ID to uniquely identify the issuing node within the cluster, which the 
> MAC address may not easily achieve as it may vary for the same logical node 
> over time e.g. if the NIC is replaced - though a record of recent MAC 
> addresses could be maintained.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17104) CEP-15: (C*/Accord) Transaction state storage

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17104:
---
Epic Link: CASSANDRA-17089

> CEP-15: (C*/Accord) Transaction state storage
> -
>
> Key: CASSANDRA-17104
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17104
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Accord
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> This work encompasses persistent storage of Accord’s transaction state within 
> Cassandra, including integration with the Commit Log, perhaps the use of 
> SSTables or system tables, and in memory caches. This will entail refactors 
> to Accord to support this.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17346) Hint documentation page has a misaligned table of settings / description / default values

[Andrew Hogg (Jira)]

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

Andrew Hogg updated CASSANDRA-17346:

Test and Documentation Plan: Website was built using : ./run.sh website 
build -g -b cassandra:hint-docs-fix -u cassandra:andrewhogg-cassandra and 
manually inspected.  (was: Website was built using : ./run.sh website build -g 
-b cassandra:hint-docs-fix -u 
cassandra:/Users/andrew.hogg/Code/andrewhogg-cassandra and manually inspected.)

> Hint documentation page has a misaligned table of settings / description / 
> default values
> -
>
> Key: CASSANDRA-17346
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17346
> Project: Cassandra
>  Issue Type: Bug
>  Components: Documentation/Website
>Reporter: Andrew Hogg
>Assignee: Andrew Hogg
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
> Attachments: Screenshot 2022-02-03 at 21.17.38.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Within the versioned documentation, the page for configuring hints contains a 
> misaligned table of hint settings, caused the the 
> hinted_handoff_disabled_datacenters row, which shifts all columns 1 further, 
> mis-aligning the rest of the content and then removing the final cell. 
> Screenshot attached of the star of the misalignment on the table.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (CASSANDRA-17102) CEP-15: (C*) Unified Commit Log

[Benedict Elliott Smith (Jira)]

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

Benedict Elliott Smith updated CASSANDRA-17102:
---
Epic Link: CASSANDRA-17089

> CEP-15: (C*) Unified Commit Log
> ---
>
> Key: CASSANDRA-17102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17102
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Consistency/Hints, Local/Commit Log
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> Create a new data structure and system for combining Commit Log and Hints. 
> This system will support compaction of commit log segments when the commit 
> log is under space pressure, but under normal operation will continue to drop 
> entire log records as soon as they become invalidated. By ensuring compaction 
> only occurs for segments that are under 50% utilised we bound space and 
> bandwidth at 2x optimal (and can tune this trade-off if we prefer, e.g. 
> trading more space for less bandwidth)
> This system will replace the storage layer for Commit Log and Hints, and be 
> used to implement distributed repair for Accord (and perhaps other systems in 
> future)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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