[jira] [Commented] (CASSANDRASC-45) Delegate methods to the RateLimiter
[
https://issues.apache.org/jira/browse/CASSANDRASC-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17619153#comment-17619153
]
Dinesh Joshi commented on CASSANDRASC-45:
-
+1
> Delegate methods to the RateLimiter
> ---
>
> Key: CASSANDRASC-45
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-45
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> Sidecar offers a {{SidecarRateLimiter}} class that internally uses the
> {{com.google.common.util.concurrent.RateLimiter}}. We need to expose public
> methods of the {{RateLimiter}} class using the delegate pattern. These
> methods will allow us to tweak the settings of the {{RateLimiter}} that are
> available to us
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-43) Introduce new handler for schema retrieval operations
[ https://issues.apache.org/jira/browse/CASSANDRASC-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17619141#comment-17619141 ] Dinesh Joshi commented on CASSANDRASC-43: - +1, thanks for addressing my comments! > Introduce new handler for schema retrieval operations > - > > Key: CASSANDRASC-43 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-43 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > Schema information is used when performing bulk reads/writes from Cassandra. > The information retrieved is used to map datatypes to other systems such as > Spark. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-44) Use vertx periodicTimer for health checks
[
https://issues.apache.org/jira/browse/CASSANDRASC-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17619102#comment-17619102
]
Dinesh Joshi commented on CASSANDRASC-44:
-
+1, thanks for the patch!
> Use vertx periodicTimer for health checks
> -
>
> Key: CASSANDRASC-44
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-44
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Rest API
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> Align Sidecar to vertx best practices by using vertx's periodic timer instead
> of using the {{Executors.newSingleThreadScheduledExecutor}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-46) Migrate minikube to testcontainers for integration tests
[
https://issues.apache.org/jira/browse/CASSANDRASC-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17619098#comment-17619098
]
Dinesh Joshi commented on CASSANDRASC-46:
-
+1, thanks for the patch!
> Migrate minikube to testcontainers for integration tests
>
>
> Key: CASSANDRASC-46
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-46
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> The existing Cassandra Sidecar integration testing suite uses Minikube to
> provision a Cassandra service and it performs tests against the running
> database. This database runs on Minikube.
> A new alternative is to use [testcontainers|https://www.testcontainers.org],
> which requires Docker to run tests. The concept is similar, but the benefit
> is that *testcontainers* is well integrated into the java ecosystem and it
> works well with junit5. By replacing Minikube with {{testcontainers}} we can
> simplify the setup process and reduce the complexity of the setup.
> Additionally, {{testcontainers}} is supported as part of the testing
> infrastructure inside
> [CircleCI|https://www.testcontainers.org/supported_docker_environment/continuous_integration/circle_ci/].
> Currently, our Minikube tests are broken both locally and in CircleCI.
> Moving to {{testcontainers}} would also unblock us for further development.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-41) Implement toString for Range in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579965#comment-17579965 ] Dinesh Joshi commented on CASSANDRASC-41: - +1 > Implement toString for Range in Sidecar > --- > > Key: CASSANDRASC-41 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-41 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Rest API >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Labels: pull-request-available > > The toString method for Range is not implemented, leading to the ranges > objects being logged incorrectly. We should add the toString implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-40) Fix search in list snapshot endpoint
[
https://issues.apache.org/jira/browse/CASSANDRASC-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570074#comment-17570074
]
Dinesh Joshi commented on CASSANDRASC-40:
-
+1 thanks for your contribution.
> Fix search in list snapshot endpoint
>
>
> Key: CASSANDRASC-40
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-40
> Project: Sidecar for Apache Cassandra
> Issue Type: Bug
> Components: Rest API
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> The test setup in {{SnapshotUtils}} is incorrect. Because of the incorrect
> test setup
> the execution is providing incorrect results. For example, assume the
> following path
> {{/cassandra-test/data/ks/tbl/snapshots/test-snapshot}}
> The test is configuring data directories as {{["/cassandra-test/data"]}}, but
> in a real
> execution data directories are provided as {{["/cassandra-test"]}}. This is
> causing the
> endpoint to return incorrect values in the JSON payload.
> Additionally, the response is providing the port for Cassandra and not the
> Sidecar
> port.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-39) Allow for configuring Cassandra input validation parameters
[
https://issues.apache.org/jira/browse/CASSANDRASC-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRASC-39:
Status: Ready to Commit (was: Review In Progress)
+1 thanks for the patch.
> Allow for configuring Cassandra input validation parameters
> ---
>
> Key: CASSANDRASC-39
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-39
> Project: Sidecar for Apache Cassandra
> Issue Type: New Feature
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
>
> Currently, Cassandra input is validated using the
> {{org.apache.cassandra.sidecar.common.utils.ValidationUtils}} class. This
> class is a static class with hard-coded values for validation. It does not
> allow for configuring different versions of Cassandra, or customizing the set
> of forbidden keyspaces, the allowed characters for a keyspace / table, or the
> allowed characters for a component.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-38) Introduce new handler to list Cassandra snapshot files
[
https://issues.apache.org/jira/browse/CASSANDRASC-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRASC-38:
Status: Ready to Commit (was: Review In Progress)
> Introduce new handler to list Cassandra snapshot files
> --
>
> Key: CASSANDRASC-38
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-38
> Project: Sidecar for Apache Cassandra
> Issue Type: New Feature
> Components: Rest API
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> Cassandra snapshots are used widely to support different use cases. The
> {{StreamSSTableComponentHandler}} allows for streaming snapshot components.
> The new endpoint will allow getting a list of SSTableComponents to be
> streamed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-38) Introduce new handler to list Cassandra snapshot files
[
https://issues.apache.org/jira/browse/CASSANDRASC-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17564461#comment-17564461
]
Dinesh Joshi commented on CASSANDRASC-38:
-
+1 LGTM
> Introduce new handler to list Cassandra snapshot files
> --
>
> Key: CASSANDRASC-38
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-38
> Project: Sidecar for Apache Cassandra
> Issue Type: New Feature
> Components: Rest API
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> Cassandra snapshots are used widely to support different use cases. The
> {{StreamSSTableComponentHandler}} allows for streaming snapshot components.
> The new endpoint will allow getting a list of SSTableComponents to be
> streamed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17724) Remove commons-lang dependency during build runtime
[
https://issues.apache.org/jira/browse/CASSANDRA-17724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-17724:
-
Mentor: Yifan Cai
Status: Ready to Commit (was: Review In Progress)
> Remove commons-lang dependency during build runtime
> ---
>
> Key: CASSANDRA-17724
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17724
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{commons-lang}} is not a runtime dependency and a
> {{java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils}}
> exception is encountered during startup when hitting the codepath in
> {{{}StartupClusterConnectivityChecker{}}}.
> This error is encountered very infrequently, but it has the potential of
> preventing the {{CassandraDaemon}} from starting up.
> Currently, the Cassandra project allows developers to import the
> {{org.apache.commons.lang.\*}} namespace. The Cassandra build process should
> fail when {{org.apache.commons.lang.\*}} namespace imports are added to the
> code. This will prevent anyone from adding a build runtime library that is
> not available during runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17724) Remove commons-lang dependency during build runtime
[
https://issues.apache.org/jira/browse/CASSANDRA-17724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563425#comment-17563425
]
Dinesh Joshi commented on CASSANDRA-17724:
--
+1 LGTM. thank you for the patch.
> Remove commons-lang dependency during build runtime
> ---
>
> Key: CASSANDRA-17724
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17724
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{commons-lang}} is not a runtime dependency and a
> {{java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils}}
> exception is encountered during startup when hitting the codepath in
> {{{}StartupClusterConnectivityChecker{}}}.
> This error is encountered very infrequently, but it has the potential of
> preventing the {{CassandraDaemon}} from starting up.
> Currently, the Cassandra project allows developers to import the
> {{org.apache.commons.lang.\*}} namespace. The Cassandra build process should
> fail when {{org.apache.commons.lang.\*}} namespace imports are added to the
> code. This will prevent anyone from adding a build runtime library that is
> not available during runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-37) Optimize file path builder and have a new handler for streaming files
[ https://issues.apache.org/jira/browse/CASSANDRASC-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17558250#comment-17558250 ] Dinesh Joshi commented on CASSANDRASC-37: - +1 > Optimize file path builder and have a new handler for streaming files > - > > Key: CASSANDRASC-37 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-37 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > This patch optimizes file path builder and creates a new handler for > streaming files. This handler is chained along with validation handlers for > an endpoint > PR: https://github.com/apache/cassandra-sidecar/pull/29 -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-37) Optimize file path builder and have a new handler for streaming files
[ https://issues.apache.org/jira/browse/CASSANDRASC-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17555709#comment-17555709 ] Dinesh Joshi commented on CASSANDRASC-37: - [~saranya_k] Could you please post the CI run? > Optimize file path builder and have a new handler for streaming files > - > > Key: CASSANDRASC-37 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-37 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > This patch optimizes file path builder and creates a new handler for > streaming files. This handler is chained along with validation handlers for > an endpoint > PR: https://github.com/apache/cassandra-sidecar/pull/29 -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-36) Support for ErrorHandler route in Sidecar
[
https://issues.apache.org/jira/browse/CASSANDRASC-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRASC-36:
Reviewers: Dinesh Joshi, Saranya Krishnakumar, Yifan Cai (was: Saranya
Krishnakumar, Yifan Cai)
> Support for ErrorHandler route in Sidecar
> -
>
> Key: CASSANDRASC-36
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-36
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> Add a default {{Route#failureHandler()}} that returns a {{JSON}}
> representation of the error for {{io.vertx.ext.web.handler.HttpException}}
> as well as {{REQUEST_TIMEOUT}} errors.
> Additionally, we need to allow for custom implementations of the
> {{ErrorHandler}} interface to be injected. Downstream projects can provide
> custom implementations of the {{ErrorHandler}} to fit the needs of the
> project.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-36) Support for ErrorHandler route in Sidecar
[
https://issues.apache.org/jira/browse/CASSANDRASC-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRASC-36:
Status: Ready to Commit (was: Review In Progress)
> Support for ErrorHandler route in Sidecar
> -
>
> Key: CASSANDRASC-36
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-36
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> Add a default {{Route#failureHandler()}} that returns a {{JSON}}
> representation of the error for {{io.vertx.ext.web.handler.HttpException}}
> as well as {{REQUEST_TIMEOUT}} errors.
> Additionally, we need to allow for custom implementations of the
> {{ErrorHandler}} interface to be injected. Downstream projects can provide
> custom implementations of the {{ErrorHandler}} to fit the needs of the
> project.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-36) Support for ErrorHandler route in Sidecar
[
https://issues.apache.org/jira/browse/CASSANDRASC-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17533111#comment-17533111
]
Dinesh Joshi commented on CASSANDRASC-36:
-
+1, thanks for the patch and resolving the PR feedback.
> Support for ErrorHandler route in Sidecar
> -
>
> Key: CASSANDRASC-36
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-36
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Labels: pull-request-available
>
> Add a default {{Route#failureHandler()}} that returns a {{JSON}}
> representation of the error for {{io.vertx.ext.web.handler.HttpException}}
> as well as {{REQUEST_TIMEOUT}} errors.
> Additionally, we need to allow for custom implementations of the
> {{ErrorHandler}} interface to be injected. Downstream projects can provide
> custom implementations of the {{ErrorHandler}} to fit the needs of the
> project.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Adding support for TLS client authentication for internode communication
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529594#comment-17529594 ] Dinesh Joshi commented on CASSANDRA-17513: -- Yes, you're understanding is correct. > Adding support for TLS client authentication for internode communication > > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 3h 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Adding support for TLS client authentication for internode communication
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529594#comment-17529594 ] Dinesh Joshi edited comment on CASSANDRA-17513 at 4/28/22 6:57 PM: --- Yes, your understanding is correct. was (Author: djoshi3): Yes, you're understanding is correct. > Adding support for TLS client authentication for internode communication > > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 3h 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Adding support for TLS client authentication for internode communication
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524704#comment-17524704 ] Dinesh Joshi commented on CASSANDRA-17513: -- Hi [~maulin.vasavada] I've updated the title to reflect more clearly as per your recommendation. My preference is to stick to explicit vs implicit. This makes things very clear for operators. There are no magical assumptions hidden in the code. So, currently we have connection settings for native protocol and internode communication. The native protocol further splits the settings into server and client settings. I believe we should keep the same pattern as it maintains consistency in the configuration. We could certainly use the same server/client truststore/keystore across both native and internode configuration. Nothing preventing us from doing that. So, at best the operator deals with one truststore and one keystore across both settings blocks. This is no worse than today. Now, if the operator can choose to generate a unique truststore and keystore for native and internode configuration. In this situation its by choice and nothing in Cassandra should force them to do this. On the extendedKeyUsage, one big downside is that the server and client certificates are stored in the same file on disk. Client certificates can expire rather quickly and this will translate into more frequent updates to the server certificates due to hot reloading. We will need to add additional logic to the hot reloading code path to ensure we do not reload the server certificate when the client certificate changes. This is undesirable behavior IMHO. A number of systems may not support packing server and client certificates into the same store file. We may actually cause additional burden in that situation by requiring operators to write scripts to package both server and client certificates in the same store file. This is unnecessary. I am open to considering implementing this idea if we don't force operators to explicitly a single store file i.e. maintain backward compatibility with what we have. However, it feels like this should be out of scope here and we can create a separate ticket to address it across both native and internode configurations. WDYT? > Adding support for TLS client authentication for internode communication > > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 1h 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17513) Adding support for TLS client authentication for internode communication
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17513: - Summary: Adding support for TLS client authentication for internode communication (was: Add new property to pass keystore for outbound connections) > Adding support for TLS client authentication for internode communication > > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 1h 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[
https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522642#comment-17522642
]
Dinesh Joshi commented on CASSANDRA-17513:
--
For internode communication, currently it is not possible for the server to
identify itself using a client certificate. By adding this option we will be
able to present a client identity to other nodes. The nodes can use this client
certificate to authenticate the node. This makes it possible to implement
mutual TLS which is currently not possible.
{quote}The way I think is - A node has an identity that it uses to-be trusted-
be it a client or server mode with the same peer.
{quote}
You cannot use the same certificate as a client certificate and a server
certificate. They are distinct. You cannot use a client certificate as a server
certificate and vice-versa.
As far as operational overhead is concerned, this is not a required
configuration item. It is optional and won't cause "overhead" unless it is
actually used by the operator.
> Add new property to pass keystore for outbound connections
> --
>
> Key: CASSANDRA-17513
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17513
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Same keystore is being set for both Inbound and outbound connections but we
> should use a keystore with server certificate for Inbound connections and a
> keystore with client certificates for outbound connections. So we should add
> a new property in Cassandra.yaml to pass outbound keystore and use it in
> SSLContextFactory for creating outbound SSL context.
--
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] (CASSANDRASC-35) Document the contribution guidelines and best practices for the project
[ https://issues.apache.org/jira/browse/CASSANDRASC-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-35: Reviewers: Dinesh Joshi, Yifan Cai (was: Dinesh Joshi) > Document the contribution guidelines and best practices for the project > --- > > Key: CASSANDRASC-35 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-35 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Documentation >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > We need a document that lays out the contribution guidelines, source code > best practices, and source code style -- 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] (CASSANDRASC-35) Document the contribution guidelines and best practices for the project
[ https://issues.apache.org/jira/browse/CASSANDRASC-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-35: Reviewers: Dinesh Joshi Status: Review In Progress (was: Patch Available) > Document the contribution guidelines and best practices for the project > --- > > Key: CASSANDRASC-35 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-35 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Documentation >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > We need a document that lays out the contribution guidelines, source code > best practices, and source code style -- 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] (CASSANDRASC-35) Document the contribution guidelines and best practices for the project
[ https://issues.apache.org/jira/browse/CASSANDRASC-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-35: Status: Ready to Commit (was: Review In Progress) +1 > Document the contribution guidelines and best practices for the project > --- > > Key: CASSANDRASC-35 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-35 > Project: Sidecar for Apache Cassandra > Issue Type: Task > Components: Documentation >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > We need a document that lays out the contribution guidelines, source code > best practices, and source code style -- 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] (CASSANDRASC-34) Allow injecting a LoggerHandler to vertxRouter
[
https://issues.apache.org/jira/browse/CASSANDRASC-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRASC-34:
Status: Review In Progress (was: Patch Available)
Hi Francisco, the patch looks good. The only thing I would recommend is adding
an automated test if its possible. If its too complicated its OK.
> Allow injecting a LoggerHandler to vertxRouter
> --
>
> Key: CASSANDRASC-34
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-34
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
>
> Currently, {{vertxRouter}} _creates_ an instance of {{LoggerHandler}} to the
> top level route. This is prescriptive and it doesn't allow for a different
> implementation of the {{LoggerHandler}} to be injected.
--
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] (CASSANDRASC-34) Allow injecting a LoggerHandler to vertxRouter
[
https://issues.apache.org/jira/browse/CASSANDRASC-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRASC-34:
Status: Changes Suggested (was: Review In Progress)
> Allow injecting a LoggerHandler to vertxRouter
> --
>
> Key: CASSANDRASC-34
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-34
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
>
> Currently, {{vertxRouter}} _creates_ an instance of {{LoggerHandler}} to the
> top level route. This is prescriptive and it doesn't allow for a different
> implementation of the {{LoggerHandler}} to be injected.
--
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] (CASSANDRASC-34) Allow injecting a LoggerHandler to vertxRouter
[
https://issues.apache.org/jira/browse/CASSANDRASC-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRASC-34:
Authors: Francisco Guerrero
Test and Documentation Plan: Manual testing
Status: Patch Available (was: In Progress)
> Allow injecting a LoggerHandler to vertxRouter
> --
>
> Key: CASSANDRASC-34
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-34
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
>
> Currently, {{vertxRouter}} _creates_ an instance of {{LoggerHandler}} to the
> top level route. This is prescriptive and it doesn't allow for a different
> implementation of the {{LoggerHandler}} to be injected.
--
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-17390) Expose streaming as a vtable
[ https://issues.apache.org/jira/browse/CASSANDRA-17390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17390: - Reviewers: Dinesh Joshi Status: Review In Progress (was: Patch Available) > Expose streaming as a vtable > - > > Key: CASSANDRA-17390 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17390 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Streaming, Feature/Virtual Tables >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > Time Spent: 2h 20m > Remaining Estimate: 0h > > CASSANDRA-15399 is exposing repair state as a vtable, but repair relies on > streaming so needs streaming table as well. -- 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-17390) Expose streaming as a vtable
[ https://issues.apache.org/jira/browse/CASSANDRA-17390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17390: - Status: Ready to Commit (was: Review In Progress) +1 > Expose streaming as a vtable > - > > Key: CASSANDRA-17390 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17390 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Streaming, Feature/Virtual Tables >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > Time Spent: 2h 20m > Remaining Estimate: 0h > > CASSANDRA-15399 is exposing repair state as a vtable, but repair relies on > streaming so needs streaming table as well. -- 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] (CASSANDRASC-33) Optionally support multiple Cassandra instances in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-33: Status: Ready to Commit (was: Review In Progress) > Optionally support multiple Cassandra instances in Sidecar > -- > > Key: CASSANDRASC-33 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-33 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Currently Sidecar supports only one Cassandra instance, we want to optionally > support multiple Cassandra instances -- 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] (CASSANDRASC-33) Optionally support multiple Cassandra instances in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-33: Status: Review In Progress (was: Patch Available) > Optionally support multiple Cassandra instances in Sidecar > -- > > Key: CASSANDRASC-33 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-33 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Currently Sidecar supports only one Cassandra instance, we want to optionally > support multiple Cassandra instances -- 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] (CASSANDRASC-33) Optionally support multiple Cassandra instances in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-33: Status: Patch Available (was: In Progress) > Optionally support multiple Cassandra instances in Sidecar > -- > > Key: CASSANDRASC-33 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-33 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Currently Sidecar supports only one Cassandra instance, we want to optionally > support multiple Cassandra instances -- 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] (CASSANDRASC-33) Optionally support multiple Cassandra instances in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17494112#comment-17494112 ] Dinesh Joshi commented on CASSANDRASC-33: - +1 > Optionally support multiple Cassandra instances in Sidecar > -- > > Key: CASSANDRASC-33 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-33 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Currently Sidecar supports only one Cassandra instance, we want to optionally > support multiple Cassandra instances -- 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] (CASSANDRASC-33) Optionally support multiple Cassandra instances in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-33: Status: In Progress (was: Patch Available) > Optionally support multiple Cassandra instances in Sidecar > -- > > Key: CASSANDRASC-33 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-33 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Currently Sidecar supports only one Cassandra instance, we want to optionally > support multiple Cassandra instances -- 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-17142) Limit the maximum hints size per host
[ https://issues.apache.org/jira/browse/CASSANDRA-17142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490572#comment-17490572 ] Dinesh Joshi commented on CASSANDRA-17142: -- +1 > Limit the maximum hints size per host > - > > Key: CASSANDRA-17142 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17142 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Hints >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Time Spent: 2h 10m > Remaining Estimate: 0h > > The hints system defines a time window, i.e. max_hint_window_in_ms, to store > the hints. > It defines no limit on how much data can be kept during the time window. The > hints can grow excessively and make the node running out of disk. In such > scenario, the operators have to truncate the hints manually. > I'd propose that in addition to the conventional hints window, operators > should be able to define the maximum hints size per host, i.e. > max_hints_size_per_host_in_mb, to provide an another layer of protection. A > node stops to store hints for the down node whenever it reaches to the time > cap or the size cap. In order to not surprise the users, the config should be > disabled by default. It should also be configurable via JMX. -- 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-17142) Limit the maximum hints size per host
[ https://issues.apache.org/jira/browse/CASSANDRA-17142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17142: - Status: Ready to Commit (was: Review In Progress) > Limit the maximum hints size per host > - > > Key: CASSANDRA-17142 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17142 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Hints >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Time Spent: 2h 10m > Remaining Estimate: 0h > > The hints system defines a time window, i.e. max_hint_window_in_ms, to store > the hints. > It defines no limit on how much data can be kept during the time window. The > hints can grow excessively and make the node running out of disk. In such > scenario, the operators have to truncate the hints manually. > I'd propose that in addition to the conventional hints window, operators > should be able to define the maximum hints size per host, i.e. > max_hints_size_per_host_in_mb, to provide an another layer of protection. A > node stops to store hints for the down node whenever it reaches to the time > cap or the size cap. In order to not surprise the users, the config should be > disabled by default. It should also be configurable via JMX. -- 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-17019) JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17019: - Since Version: 4.1 Source Control Link: https://github.com/apache/cassandra/commit/2043cb9fb6b25ff34afb90467b9476a09acc3933 Resolution: Fixed Status: Resolved (was: Ready to Commit) > JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-17019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17019 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Igamr Palsenberg >Assignee: Yuqi Gu >Priority: Normal > Fix For: 4.1 > > Attachments: UTs_snappy_upgrading.txt, cassandra_UTs.txt > > > Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native > binding into the C library. > JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing > cassandra to fail on bootstrap. > Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the > dependency be acceptable ? -- 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-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-17040:
-
Source Control Link:
https://github.com/apache/cassandra/commit/2043cb9fb6b25ff34afb90467b9476a09acc3933
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Compression
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt, UTs_2.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
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-17019) JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17019: - Status: Ready to Commit (was: Review In Progress) +1 lgtm > JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-17019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17019 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Igamr Palsenberg >Assignee: Yuqi Gu >Priority: Normal > Fix For: 4.1 > > Attachments: UTs_snappy_upgrading.txt, cassandra_UTs.txt > > > Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native > binding into the C library. > JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing > cassandra to fail on bootstrap. > Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the > dependency be acceptable ? -- 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-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-17040:
-
Status: Ready to Commit (was: Review In Progress)
Looks like this resolves issues on M1.
+1 lgtm.
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Compression
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt, UTs_2.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
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-17121) Allow column_index_size_in_kb to be configurable through nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-17121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17121: - Status: Ready to Commit (was: Review In Progress) +1 > Allow column_index_size_in_kb to be configurable through nodetool > - > > Key: CASSANDRA-17121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17121 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > > Configuring the column_index_size_in_kb setting requires a cassandra.yaml > change and bouncing the instance. > Allowing column_index_size_in_kb to be configurable through nodetool can help > in the operational landscape. -- 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-17116) When zero-copy-streaming sees a channel close this triggers the disk failure policy
[
https://issues.apache.org/jira/browse/CASSANDRA-17116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445541#comment-17445541
]
Dinesh Joshi edited comment on CASSANDRA-17116 at 11/17/21, 11:07 PM:
--
I think with the introduction of {{COMPLETE_ACK}}, we would need to also
introduce a timeout after the {{COMPLETE}} message is transmitted but before
the sender closes the Channel. This would give the receiving peer time to
consume all the data and the {{COMPLETE}} message. This would not only solve
the issue but also be backward compatible as we could send {{COMPLETE_ACK}} to
peers that support the message and not to other peers.
was (Author: djoshi3):
I think with the introduction of {{COMPLETE_ACK}}, we would need to also
introduce a timeout after the {{COMPLETE}} message is transmitted but before
the sender closes the Channel. This would give the receiving peer time to
consume all the data and the `COMPLETE` message. This would also be backward
compatible as we could send {{COMPLETE_ACK}} to peers that support the message
and not to other peers.
> When zero-copy-streaming sees a channel close 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
>
>
> 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 zero-copy-streaming sees a channel close this triggers the disk failure policy
[
https://issues.apache.org/jira/browse/CASSANDRA-17116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445541#comment-17445541
]
Dinesh Joshi commented on CASSANDRA-17116:
--
I think with the introduction of {{COMPLETE_ACK}}, we would need to also
introduce a timeout after the {{COMPLETE}} message is transmitted but before
the sender closes the Channel. This would give the receiving peer time to
consume all the data and the `COMPLETE` message. This would also be backward
compatible as we could send {{COMPLETE_ACK}} to peers that support the message
and not to other peers.
> When zero-copy-streaming sees a channel close 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
>
>
> 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 zero-copy-streaming sees a channel close this triggers the disk failure policy
[
https://issues.apache.org/jira/browse/CASSANDRA-17116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-17116:
-
Reviewers: Dinesh Joshi
> When zero-copy-streaming sees a channel close 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
>
>
> 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.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-32) Sidecar health checks are failing since CassandraAdaptorDelegate is not started
[ https://issues.apache.org/jira/browse/CASSANDRASC-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-32: Status: Ready to Commit (was: Review In Progress) > Sidecar health checks are failing since CassandraAdaptorDelegate is not > started > --- > > Key: CASSANDRASC-32 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-32 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > CassandraAdaptorDelegate class in Sidecar periodically checks if it is able > to connect to Cassandra instance. Currently we are not starting this delegate > and hence Sidecar health checks are failing. We need to start the delegate > while starting the server > > https://github.com/apache/cassandra-sidecar/pull/24 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-32) Sidecar health checks are failing since CassandraAdaptorDelegate is not started
[ https://issues.apache.org/jira/browse/CASSANDRASC-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17437115#comment-17437115 ] Dinesh Joshi commented on CASSANDRASC-32: - +1 > Sidecar health checks are failing since CassandraAdaptorDelegate is not > started > --- > > Key: CASSANDRASC-32 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-32 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > CassandraAdaptorDelegate class in Sidecar periodically checks if it is able > to connect to Cassandra instance. Currently we are not starting this delegate > and hence Sidecar health checks are failing. We need to start the delegate > while starting the server > > https://github.com/apache/cassandra-sidecar/pull/24 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16967) Probabilistic diff to sample partitions for diff testing based on probability.
[ https://issues.apache.org/jira/browse/CASSANDRA-16967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-16967: - Status: Ready to Commit (was: Review In Progress) +1 > Probabilistic diff to sample partitions for diff testing based on probability. > -- > > Key: CASSANDRA-16967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16967 > Project: Cassandra > Issue Type: New Feature > Components: Tool/diff >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > > Probabilistic diff allows us to sample partitions randomly while running diff > tests. It takes new config parameter `partition_sampling_probability ` that > ranges between (0-1) and samples partitions based on this probability. The > default value for this config property is 1 which means that all the > partitions will be diffed. The partitions that are selected are also based on > the JobId, for a given sampling probability and JobId we always diff on same > partitions.This helps in reproducing any issues that one might run into. > Probabilistic diff allows us to run diff jobs on large clusters by sampling > some partitions. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430807#comment-17430807 ] Dinesh Joshi commented on CASSANDRA-17019: -- I am not sure if we need two different tickets (CASSANDRA-17040 and this) here as I don't think we can run the tests successfully without both Snappy and JNA being upgraded. > JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-17019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17019 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Igamr Palsenberg >Assignee: Yuqi Gu >Priority: Normal > Fix For: 4.1 > > Attachments: UTs_snappy_upgrading.txt, cassandra_UTs.txt > > > Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native > binding into the C library. > JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing > cassandra to fail on bootstrap. > Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the > dependency be acceptable ? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430805#comment-17430805
]
Dinesh Joshi commented on CASSANDRA-17040:
--
I had to upgrade JNA to 5.9.0 on top of your Snappy patch. I ran all the unit
tests. There were 3 failures but rest of them passed. Upon rerunning the failed
tests individually they passed. I am going to poke around a little before
approving this patch. We can get this into trunk certainly but I don't think
we'll backport it to any of the release branches.
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Compression
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt, UTs_2.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-17040:
-
Issue Type: Improvement (was: Task)
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Compression
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt, UTs_2.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430683#comment-17430683
]
Dinesh Joshi commented on CASSANDRA-17040:
--
[~yqGu] did your JVM crash? Can you post details about the build environment
and how you ran the unit tests?
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Compression
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt, UTs_2.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17002) Cassandra Ring state transitions should be available through a Virtual Table
[ https://issues.apache.org/jira/browse/CASSANDRA-17002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17002: - Authors: (was: Francisco Guerrero) > Cassandra Ring state transitions should be available through a Virtual Table > > > Key: CASSANDRA-17002 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17002 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables >Reporter: Dinesh Joshi >Assignee: Yifan Cai >Priority: Normal > > In many situations it is beneficial to see the last N Gossip state > transitions for debugging and other purposes. We should expose the last N > state transitions through a bounded Virtual Table. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17002) Cassandra Ring state transitions should be available through a Virtual Table
[ https://issues.apache.org/jira/browse/CASSANDRA-17002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi reassigned CASSANDRA-17002: Assignee: Francisco Guerrero (was: Yifan Cai) > Cassandra Ring state transitions should be available through a Virtual Table > > > Key: CASSANDRA-17002 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17002 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables >Reporter: Dinesh Joshi >Assignee: Francisco Guerrero >Priority: Normal > > In many situations it is beneficial to see the last N Gossip state > transitions for debugging and other purposes. We should expose the last N > state transitions through a bounded Virtual Table. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17002) Cassandra Ring state transitions should be available through a Virtual Table
[ https://issues.apache.org/jira/browse/CASSANDRA-17002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17002: - Authors: Francisco Guerrero (was: Yifan Cai) > Cassandra Ring state transitions should be available through a Virtual Table > > > Key: CASSANDRA-17002 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17002 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables >Reporter: Dinesh Joshi >Assignee: Yifan Cai >Priority: Normal > > In many situations it is beneficial to see the last N Gossip state > transitions for debugging and other purposes. We should expose the last N > state transitions through a bounded Virtual Table. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17019: - Reviewers: Dinesh Joshi, Stefan Miklosovic (was: Dinesh Joshi) > JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-17019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17019 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Igamr Palsenberg >Assignee: Yuqi Gu >Priority: Normal > Fix For: 4.1 > > Attachments: UTs_snappy_upgrading.txt, cassandra_UTs.txt > > > Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native > binding into the C library. > JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing > cassandra to fail on bootstrap. > Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the > dependency be acceptable ? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi reassigned CASSANDRA-17019: Assignee: Yuqi Gu (was: Stefan Miklosovic) > JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-17019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17019 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Igamr Palsenberg >Assignee: Yuqi Gu >Priority: Normal > Fix For: 4.1 > > Attachments: UTs_snappy_upgrading.txt, cassandra_UTs.txt > > > Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native > binding into the C library. > JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing > cassandra to fail on bootstrap. > Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the > dependency be acceptable ? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17019: - Status: Review In Progress (was: Needs Committer) > JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-17019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17019 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Igamr Palsenberg >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Attachments: UTs_snappy_upgrading.txt, cassandra_UTs.txt > > > Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native > binding into the C library. > JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing > cassandra to fail on bootstrap. > Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the > dependency be acceptable ? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-17040:
-
Status: Review In Progress (was: Patch Available)
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Compression
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428626#comment-17428626
]
Dinesh Joshi commented on CASSANDRA-17040:
--
[~yqGu] thanks for the patch. I've kicked off CI
[here.|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1207/]
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Compression
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-17040:
-
Component/s: (was: CI)
Feature/Compression
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Compression
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-17040:
-
Change Category: (was: Quality Assurance)
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Compression
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-17040:
-
Reviewers: Dinesh Joshi
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[
https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428616#comment-17428616
]
Dinesh Joshi edited comment on CASSANDRA-17019 at 10/14/21, 6:10 AM:
-
[~yqGu] this is expected in macOS. You'll need to manually create aliases for
127.0.0.1 to fix this failing unit test like this:
{code:java}
sudo ifconfig lo0 alias 127.0.0.2 up
sudo ifconfig lo0 alias 127.0.0.3 up
...
{code}
You may need to create more than just 3.
As part of this patch, please update Cassandra's README to reflect these
instructions.
was (Author: djoshi3):
[~yqGu] this is expected in macOS. You'll need to manually create aliases for
127.0.0.1 to fix this failing unit test like this:
{code:java}
sudo ifconfig lo0 alias 127.0.0.2 up
sudo ifconfig lo0 alias 127.0.0.3 up
...
{code}
You may need to create more than just 3.
> JNA 5.6.0 does not support arm64
>
>
> Key: CASSANDRA-17019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17019
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Igamr Palsenberg
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs_snappy_upgrading.txt, cassandra_UTs.txt
>
>
> Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native
> binding into the C library.
> JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing
> cassandra to fail on bootstrap.
> Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the
> dependency be acceptable ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[
https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428616#comment-17428616
]
Dinesh Joshi commented on CASSANDRA-17019:
--
[~yqGu] this is expected in macOS. You'll need to manually create aliases for
127.0.0.1 to fix this failing unit test like this:
{code:java}
sudo ifconfig lo0 alias 127.0.0.2 up
sudo ifconfig lo0 alias 127.0.0.3 up
...
{code}
You may need to create more than just 3.
> JNA 5.6.0 does not support arm64
>
>
> Key: CASSANDRA-17019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17019
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Igamr Palsenberg
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs_snappy_upgrading.txt, cassandra_UTs.txt
>
>
> Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native
> binding into the C library.
> JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing
> cassandra to fail on bootstrap.
> Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the
> dependency be acceptable ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428554#comment-17428554 ] Dinesh Joshi commented on CASSANDRA-17019: -- It looks like snappy lacks support for M1 Mac. However, it is expected to fall back on a pure Java implementation. > JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-17019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17019 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Igamr Palsenberg >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Attachments: cassandra_UTs.txt > > > Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native > binding into the C library. > JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing > cassandra to fail on bootstrap. > Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the > dependency be acceptable ? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17001) Optionally prune CDC segments if consumer fails to consume them fast enough
[ https://issues.apache.org/jira/browse/CASSANDRA-17001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17001: - Change Category: Operability Complexity: Normal Component/s: Local/Commit Log Status: Open (was: Triage Needed) > Optionally prune CDC segments if consumer fails to consume them fast enough > --- > > Key: CASSANDRA-17001 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17001 > Project: Cassandra > Issue Type: Improvement > Components: Local/Commit Log >Reporter: Dinesh Joshi >Assignee: Yifan Cai >Priority: Normal > > Current CDC implementation blocks writes if the CDC segments have filled up. > This makes sense for some use-cases. In other cases it would be beneficial > for C* to prune the CDC segments if they haven't been consumed. This will > prevent blocking of writes. With this change we will introduce a flag to > prune CDC segments much like a circular buffer. This will prevent the writes > being blocked. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17002) Cassandra Ring state transitions should be available through a Virtual Table
[ https://issues.apache.org/jira/browse/CASSANDRA-17002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17002: - Change Category: Operability Complexity: Normal Component/s: Feature/Virtual Tables Reviewers: Dinesh Joshi Status: Open (was: Triage Needed) > Cassandra Ring state transitions should be available through a Virtual Table > > > Key: CASSANDRA-17002 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17002 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables >Reporter: Dinesh Joshi >Assignee: Yifan Cai >Priority: Normal > > In many situations it is beneficial to see the last N Gossip state > transitions for debugging and other purposes. We should expose the last N > state transitions through a bounded Virtual Table. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17021) Enhance Zstd support in Cassandra with dictionaries
[ https://issues.apache.org/jira/browse/CASSANDRA-17021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17021: - Change Category: Performance Complexity: Normal Reviewers: Dinesh Joshi Status: Open (was: Triage Needed) > Enhance Zstd support in Cassandra with dictionaries > --- > > Key: CASSANDRA-17021 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17021 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Compression >Reporter: Dinesh Joshi >Assignee: Yifan Cai >Priority: Normal > > Currently Cassandra supports zstd compression. However, Zstd also supports > dictionaries to enhance not only the compression ratio but also the speed. > Dictionaries can show 3-4x savings. We should add support to train > dictionaries, ideally per SSTable this will yield the maximum gains. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17002) Cassandra Ring state transitions should be available through a Virtual Table
[ https://issues.apache.org/jira/browse/CASSANDRA-17002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17002: - Summary: Cassandra Ring state transitions should be available through a Virtual Table (was: Gossip state transitions should be available through a Virtual Table) > Cassandra Ring state transitions should be available through a Virtual Table > > > Key: CASSANDRA-17002 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17002 > Project: Cassandra > Issue Type: Improvement >Reporter: Dinesh Joshi >Assignee: Yifan Cai >Priority: Normal > > In many situations it is beneficial to see the last N Gossip state > transitions for debugging and other purposes. We should expose the last N > state transitions through a bounded Virtual Table. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-30) Sidecar API to allow Zero Copy streaming of CDC segments
[ https://issues.apache.org/jira/browse/CASSANDRASC-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-30: Change Category: Performance Complexity: Normal Component/s: Rest API Reviewers: Dinesh Joshi Status: Open (was: Triage Needed) > Sidecar API to allow Zero Copy streaming of CDC segments > > > Key: CASSANDRASC-30 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-30 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Dinesh Joshi >Assignee: Saranya Krishnakumar >Priority: Normal > > Sidecar should allow us to stream CDC segments. This would be a great way to > scalably copy CDC segments. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17030) Allow to GRANT or REVOKE multiple permissions in a single statement
[
https://issues.apache.org/jira/browse/CASSANDRA-17030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi reassigned CASSANDRA-17030:
Assignee: Francisco Guerrero
> Allow to GRANT or REVOKE multiple permissions in a single statement
> ---
>
> Key: CASSANDRA-17030
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17030
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Francisco Guerrero
>Priority: Normal
>
> In order to GRANT or REVOKE multiple permissions we are currently forced to
> execute multiple requests. For example:
> {code}
> GRANT MODIFY ON KEYSPACE field TO manager;
> GRANT SELECT ON KEYSPACE field TO manager;
> {code}
> We should be able to perform the same operations on a single request
> {code}
> GRANT MODIFY, SELECT ON KEYSPACE field TO manager;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17019) JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-17019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-17019: - Reviewers: Dinesh Joshi > JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-17019 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17019 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Igamr Palsenberg >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > > Cassandra depends on net.java.dev.jna.jna version 5.6.0 to do the native > binding into the C library. > JNA 5.6.0 does not support arm64 architecture (Apple M1 devices), causing > cassandra to fail on bootstrap. > Bumping the dependency to 5.9.0 adds arm64 support. Will a PR to bump the > dependency be acceptable ? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425358#comment-17425358 ] Dinesh Joshi commented on CASSANDRA-16983: -- +1 on removing vestiges of Windows support. If someone is really interested in using cqlsh on Windows, they can explore using Windows Subsystem for Linux which should work pretty well. > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17021) Enhance Zstd support in Cassandra with dictionaries
Dinesh Joshi created CASSANDRA-17021: Summary: Enhance Zstd support in Cassandra with dictionaries Key: CASSANDRA-17021 URL: https://issues.apache.org/jira/browse/CASSANDRA-17021 Project: Cassandra Issue Type: Improvement Components: Feature/Compression Reporter: Dinesh Joshi Assignee: Yifan Cai Currently Cassandra supports zstd compression. However, Zstd also supports dictionaries to enhance not only the compression ratio but also the speed. Dictionaries can show 3-4x savings. We should add support to train dictionaries, ideally per SSTable this will yield the maximum gains. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-29) Avoid having sidecar's health response code depend on Cassandra's health information
[ https://issues.apache.org/jira/browse/CASSANDRASC-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-29: Fix Version/s: 1.0 Source Control Link: https://github.com/apache/cassandra-sidecar/commit/1012c0dac56b64599d06815b500d4e7d41d34f03 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed. Thank you for the patch [~saranya_k]! > Avoid having sidecar's health response code depend on Cassandra's health > information > > > Key: CASSANDRASC-29 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-29 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > Fix For: 1.0 > > > Currently sidecar's health endpoint throws 503 status code if cassandra > instance is not up. This should not be the case, sidecar should return 200 if > sidecar is healthy and running and should give a detailed error message > saying connected cassandra instance is not up > > https://github.com/apache/cassandra-sidecar/pull/21 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-29) Avoid having sidecar's health response code depend on Cassandra's health information
[ https://issues.apache.org/jira/browse/CASSANDRASC-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-29: Status: Review In Progress (was: Patch Available) > Avoid having sidecar's health response code depend on Cassandra's health > information > > > Key: CASSANDRASC-29 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-29 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Currently sidecar's health endpoint throws 503 status code if cassandra > instance is not up. This should not be the case, sidecar should return 200 if > sidecar is healthy and running and should give a detailed error message > saying connected cassandra instance is not up > > https://github.com/apache/cassandra-sidecar/pull/21 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-29) Avoid having sidecar's health response code depend on Cassandra's health information
[ https://issues.apache.org/jira/browse/CASSANDRASC-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-29: Status: Ready to Commit (was: Review In Progress) +1 > Avoid having sidecar's health response code depend on Cassandra's health > information > > > Key: CASSANDRASC-29 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-29 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Currently sidecar's health endpoint throws 503 status code if cassandra > instance is not up. This should not be the case, sidecar should return 200 if > sidecar is healthy and running and should give a detailed error message > saying connected cassandra instance is not up > > https://github.com/apache/cassandra-sidecar/pull/21 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9384) Update jBCrypt dependency to version 0.4
[ https://issues.apache.org/jira/browse/CASSANDRA-9384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17422258#comment-17422258 ] Dinesh Joshi commented on CASSANDRA-9384: - LGTM +1 > Update jBCrypt dependency to version 0.4 > > > Key: CASSANDRA-9384 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9384 > Project: Cassandra > Issue Type: Bug >Reporter: Sam Tunnicliffe >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.26, 3.11.12, 4.0.2, 4.1 > > Time Spent: 10m > Remaining Estimate: 0h > > https://bugzilla.mindrot.org/show_bug.cgi?id=2097 > Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 > indicate that this is now fixed, so we should update. > Thanks to [~Bereng] for identifying the issue. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-31) Fix broken sidecar gradle configuration
[ https://issues.apache.org/jira/browse/CASSANDRASC-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-31: Status: Ready to Commit (was: Review In Progress) +1 > Fix broken sidecar gradle configuration > --- > > Key: CASSANDRASC-31 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-31 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Configuration >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > > Sidecar gradle configuration still uses Cassandra 4.0-beta1 to build > containers. The cassandra version no longer exists, and build fails at the > downloading step. > The version needs to be updated and configurable. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-9384) Update jBCrypt dependency to version 0.4
[ https://issues.apache.org/jira/browse/CASSANDRA-9384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17421554#comment-17421554 ] Dinesh Joshi commented on CASSANDRA-9384: - [~stefan.miklosovic] thank you for picking up this patch. For the tiny percentage of users, if there are any, using salting rounds 31 there is no path to upgrade to the latest release without first reducing the rounds on their existing deployment. Could you also add the patches for 3.11 and 4.0 branches? I only see the 3.0 patch which I am +1 on. > Update jBCrypt dependency to version 0.4 > > > Key: CASSANDRA-9384 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9384 > Project: Cassandra > Issue Type: Bug >Reporter: Sam Tunnicliffe >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > https://bugzilla.mindrot.org/show_bug.cgi?id=2097 > Although the bug tracker lists it as NEW/OPEN, the release notes for 0.4 > indicate that this is now fixed, so we should update. > Thanks to [~Bereng] for identifying the issue. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-28) Add Stream SSTable API to Sidecar to stream SSTable components through zero copy streaming
[ https://issues.apache.org/jira/browse/CASSANDRASC-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-28: Status: Ready to Commit (was: Review In Progress) +1 > Add Stream SSTable API to Sidecar to stream SSTable components through zero > copy streaming > -- > > Key: CASSANDRASC-28 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-28 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature > Components: Rest API >Reporter: Saranya Krishnakumar >Assignee: Saranya Krishnakumar >Priority: Normal > > Create an API for streaming SSTable components using Vertx’s zero copy > sendFile API > https://github.com/apache/cassandra-sidecar/pull/20 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRASC-30) Sidecar API to allow Zero Copy streaming of CDC segments
Dinesh Joshi created CASSANDRASC-30: --- Summary: Sidecar API to allow Zero Copy streaming of CDC segments Key: CASSANDRASC-30 URL: https://issues.apache.org/jira/browse/CASSANDRASC-30 Project: Sidecar for Apache Cassandra Issue Type: Improvement Reporter: Dinesh Joshi Assignee: Saranya Krishnakumar Sidecar should allow us to stream CDC segments. This would be a great way to scalably copy CDC segments. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17002) Gossip state transitions should be available through a Virtual Table
Dinesh Joshi created CASSANDRA-17002: Summary: Gossip state transitions should be available through a Virtual Table Key: CASSANDRA-17002 URL: https://issues.apache.org/jira/browse/CASSANDRA-17002 Project: Cassandra Issue Type: Improvement Reporter: Dinesh Joshi Assignee: Yifan Cai In many situations it is beneficial to see the last N Gossip state transitions for debugging and other purposes. We should expose the last N state transitions through a bounded Virtual Table. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17001) Optionally prune CDC segments if consumer fails to consume them fast enough
Dinesh Joshi created CASSANDRA-17001: Summary: Optionally prune CDC segments if consumer fails to consume them fast enough Key: CASSANDRA-17001 URL: https://issues.apache.org/jira/browse/CASSANDRA-17001 Project: Cassandra Issue Type: Improvement Reporter: Dinesh Joshi Assignee: Yifan Cai Current CDC implementation blocks writes if the CDC segments have filled up. This makes sense for some use-cases. In other cases it would be beneficial for C* to prune the CDC segments if they haven't been consumed. This will prevent blocking of writes. With this change we will introduce a flag to prune CDC segments much like a circular buffer. This will prevent the writes being blocked. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419490#comment-17419490 ] Dinesh Joshi commented on CASSANDRA-16456: -- [~dchenbecker] Agreed. The CEP looks good. I'll go over it again if there are any comments, I'll add to it. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16968) Diff Job retry bug fixes in reading previous run's job parameters & marking the job status
[ https://issues.apache.org/jira/browse/CASSANDRA-16968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418652#comment-17418652 ] Dinesh Joshi commented on CASSANDRA-16968: -- [~yifanc] do you want to commit this? > Diff Job retry bug fixes in reading previous run's job parameters & marking > the job status > -- > > Key: CASSANDRA-16968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16968 > Project: Cassandra > Issue Type: New Feature > Components: Tool/diff >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > > Diff job retry with same jobId should avoid running diffs on the partitions > that were successfully diffed previously. The retry failed because previous > run failed to mark the job as not running on exit. This is due to a bug in > the resource try catch block where session object Is closed before marking > the job as not running. Also there is another bug in the way we get job > parameters during rerun of a failed diff job. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16968) Diff Job retry bug fixes in reading previous run's job parameters & marking the job status
[ https://issues.apache.org/jira/browse/CASSANDRA-16968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-16968: - Status: Ready to Commit (was: Review In Progress) +1 > Diff Job retry bug fixes in reading previous run's job parameters & marking > the job status > -- > > Key: CASSANDRA-16968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16968 > Project: Cassandra > Issue Type: New Feature > Components: Tool/diff >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > > Diff job retry with same jobId should avoid running diffs on the partitions > that were successfully diffed previously. The retry failed because previous > run failed to mark the job as not running on exit. This is due to a bug in > the resource try catch block where session object Is closed before marking > the job as not running. Also there is another bug in the way we get job > parameters during rerun of a failed diff job. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-16983: - Complexity: Low Hanging Fruit (was: Normal) > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14612) Please add OWASP Dependency Check to the build (pom.xml)
[ https://issues.apache.org/jira/browse/CASSANDRA-14612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418641#comment-17418641 ] Dinesh Joshi commented on CASSANDRA-14612: -- [~rustyrazorblade] [~cnlwsu] please chime in about gradle :) > Please add OWASP Dependency Check to the build (pom.xml) > > > Key: CASSANDRA-14612 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14612 > Project: Cassandra > Issue Type: New Feature > Components: Build > Environment: All development, build, test, environments. >Reporter: Albert Baker >Assignee: Stefan Miklosovic >Priority: Normal > Labels: build, easyfix, security > Fix For: 3.11.x, 4.x > > Original Estimate: 1h > Remaining Estimate: 1h > > Please add OWASP Dependency Check to the build (pom.xml). OWASP DC makes an > outbound REST call to MITRE Common Vulnerabilities & Exposures (CVE) to > perform a lookup for each dependant .jar to list any/all known > vulnerabilities for each jar. This step is needed because a manual MITRE CVE > lookup/check on the main component does not include checking for > vulnerabilities in components or in dependant libraries. > OWASP Dependency check : > https://www.owasp.org/index.php/OWASP_Dependency_Check has plug-ins for most > Java build/make types (ant, maven, ivy, gradle). > Also, add the appropriate command to the nightly build to generate a report > of all known vulnerabilities in any/all third party libraries/dependencies > that get pulled in. example : mvn -Powasp -Dtest=false -DfailIfNoTests=false > clean aggregate > Generating this report nightly/weekly will help inform the project's > development team if any dependant libraries have a reported known > vulnerailities. Project teams that keep up with removing vulnerabilities on a > weekly basis will help protect businesses that rely on these open source > componets. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-16983: - Labels: lhf (was: ) > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > Labels: lhf > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418640#comment-17418640 ] Dinesh Joshi commented on CASSANDRA-16983: -- [~Bowen Song] I have tentatively assigned the ticket to you. Like Brandon said, please reach out over email / slack if you have questions on working on a patch for this ticket. The good news is cqlsh is written in Python and uses Python driver. > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi reassigned CASSANDRA-16983: Assignee: Bowen Song > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Assignee: Bowen Song >Priority: Normal > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16983) Separating CQLSH credentials from the cqlshrc file
[ https://issues.apache.org/jira/browse/CASSANDRA-16983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418204#comment-17418204 ] Dinesh Joshi commented on CASSANDRA-16983: -- +1 on this idea. My personal preference would be to default to failing on detecting weak security practices. Introducing a flag to allow insecure practices could go back to the current behavior. I realize this would be breaking some users that call cqlsh in scripts but I think its worth it. > Separating CQLSH credentials from the cqlshrc file > -- > > Key: CASSANDRA-16983 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16983 > Project: Cassandra > Issue Type: Improvement > Components: Tool/cqlsh >Reporter: Bowen Song >Priority: Normal > > Currently, the CQLSH tool accepts credentials (username & password) from the > following 3 places: > 1. the command line parameter "-p" > 2. the cqlshrc file > 3. prompt the user > This is not ideal. > Credentials in the command line is a security risk, because it could be see > by other users on a shared system. > The cqlshrc file is better, but still not good enough. Because the cqlshrc > file is a config file, it's often acceptable to have it as a world readable > file, and share it with other users. It also prevents user from having > multiple sets of credentials, either for the same Cassandra cluster or > different clusters. > To improve the security of CQLSH and make it secure by design, I purpose the > following changes: > * Warn the user if a password is giving in the command line, and recommend > them to use a credential file instead > * Warn the user if credentials are present in the cqlshrc file and the > cqlshrc file is not secure (e.g.: world readable or owned by a different user) > * Deprecate credentials in the cqlshrc, and recommend the user to move them > to a separate credential file. The aim is to not break anything at the > moment, but eventually stop accepting credentials from the cqlshrc file. > * Reject the credentials file if it's not secure, and tell the user how to > secure it. Optionally, prompt the user for password if it's an interactive > session. (Think how does OpenSSH handle insecure credential files) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-16456: - Reviewers: Dinesh Joshi, Paulo Motta, Stefan Miklosovic (was: Paulo Motta, Stefan Miklosovic) > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418173#comment-17418173 ] Dinesh Joshi commented on CASSANDRA-16456: -- This is a good initiative. I'm +1 on extending the auth providers that cqlsh support. I wanted to add a couple thoughts - 1. CQLSH also supports certificate based authentication by providing client certificates in cqlshrc. https://github.com/apache/cassandra/blob/trunk/conf/cqlshrc.sample#L109 This can be used to implement "mutual TLS" authentication. With short lived certificates this can be a great way to authenticate clients. 2. We may need to also extend the CQL protocol. We can extend the current SASL implementation that can negotiate various authentication mechanisms. This was discussed in https://issues.apache.org/jira/browse/CASSANDRA-11471 Check it out and lets see if there is a good approach to achieve your goal. [~samt] WDYT? > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16436) Add startup check for large read_ahead_kb setting
[
https://issues.apache.org/jira/browse/CASSANDRA-16436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi reassigned CASSANDRA-16436:
Assignee: Owen Qian
> Add startup check for large read_ahead_kb setting
> -
>
> Key: CASSANDRA-16436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16436
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Startup and Shutdown
>Reporter: Paulo Motta
>Assignee: Owen Qian
>Priority: Normal
> Labels: lhf
>
> A well known production tuning recommendation is to dial back the
> {{read_ahead_kb}} Linux setting from the default of 4096 in most
> distributions as this can cause high IO usage and cache churn on
> read-intensive workloads.
> We should add a startup warning to detect when a high {{read_ahead_kb}} is
> used and recommend the user to dial back to a reasonable value, which varies
> according to the workload but a general guideline is to tune this to 8kb.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16884) Bump zstd-jni version to 1.5.0-4
[ https://issues.apache.org/jira/browse/CASSANDRA-16884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-16884: - Status: Review In Progress (was: Patch Available) > Bump zstd-jni version to 1.5.0-4 > > > Key: CASSANDRA-16884 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16884 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: High > > The current zstd-jni version (1.3.8-5) was released in 04/12/2019. There has > been a lot of development on the zstd library and the jni binding during the > 2.5 years, including a fuzzer which detected a handful of corruption bugs and > performance improvements. > The version of zstd-jni maps with the one of the native library. The current > native lib version is 1.5.0, hence 1.5.0-4 for zstd-jni. > I am proposing bumping the zstd-jni version to the current. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16884) Bump zstd-jni version to 1.5.0-4
[ https://issues.apache.org/jira/browse/CASSANDRA-16884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-16884: - Status: Patch Available (was: In Progress) > Bump zstd-jni version to 1.5.0-4 > > > Key: CASSANDRA-16884 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16884 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: High > > The current zstd-jni version (1.3.8-5) was released in 04/12/2019. There has > been a lot of development on the zstd library and the jni binding during the > 2.5 years, including a fuzzer which detected a handful of corruption bugs and > performance improvements. > The version of zstd-jni maps with the one of the native library. The current > native lib version is 1.5.0, hence 1.5.0-4 for zstd-jni. > I am proposing bumping the zstd-jni version to the current. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16884) Bump zstd-jni version to 1.5.0-4
[ https://issues.apache.org/jira/browse/CASSANDRA-16884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-16884: - Status: In Progress (was: Patch Available) > Bump zstd-jni version to 1.5.0-4 > > > Key: CASSANDRA-16884 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16884 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: High > > The current zstd-jni version (1.3.8-5) was released in 04/12/2019. There has > been a lot of development on the zstd library and the jni binding during the > 2.5 years, including a fuzzer which detected a handful of corruption bugs and > performance improvements. > The version of zstd-jni maps with the one of the native library. The current > native lib version is 1.5.0, hence 1.5.0-4 for zstd-jni. > I am proposing bumping the zstd-jni version to the current. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16884) Bump zstd-jni version to 1.5.0-4
[ https://issues.apache.org/jira/browse/CASSANDRA-16884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-16884: - Status: Ready to Commit (was: Review In Progress) +1 > Bump zstd-jni version to 1.5.0-4 > > > Key: CASSANDRA-16884 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16884 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: High > > The current zstd-jni version (1.3.8-5) was released in 04/12/2019. There has > been a lot of development on the zstd library and the jni binding during the > 2.5 years, including a fuzzer which detected a handful of corruption bugs and > performance improvements. > The version of zstd-jni maps with the one of the native library. The current > native lib version is 1.5.0, hence 1.5.0-4 for zstd-jni. > I am proposing bumping the zstd-jni version to the current. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
