[jira] [Commented] (CASSANDRA-16902) A user should be able to view permissions of role they created
[
https://issues.apache.org/jira/browse/CASSANDRA-16902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428025#comment-17428025
]
Aleksei Zotov commented on CASSANDRA-16902:
---
[~blerer] [~jmckenzie]
Would you mind reviewing this change? I'd like to get it merged to prevent
conflicts with CASSANDRA-16914.
> A user should be able to view permissions of role they created
> --
>
> Key: CASSANDRA-16902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16902
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently users are denied to view permissions to see a role they created:
> {code}
> CREATE ROLE parent WITH PASSWORD = 'x' AND LOGIN = true;
> GRANT CREATE ON ALL ROLES TO parent;
> LOGIN parent;
> CREATE ROLE child WITH PASSWORD = 'x' AND LOGIN = true;
> LIST ALL PERMISSIONS OF 'child'; -- You are not authorized to view child's
> permissions
> {code}
> When a user creates a role they should get the {{DESCRIBE}} permission on
> that role by default.
--
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-16902) A user should be able to view permissions of role they created
[
https://issues.apache.org/jira/browse/CASSANDRA-16902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-16902:
--
Status: Needs Committer (was: Patch Available)
> A user should be able to view permissions of role they created
> --
>
> Key: CASSANDRA-16902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16902
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently users are denied to view permissions to see a role they created:
> {code}
> CREATE ROLE parent WITH PASSWORD = 'x' AND LOGIN = true;
> GRANT CREATE ON ALL ROLES TO parent;
> LOGIN parent;
> CREATE ROLE child WITH PASSWORD = 'x' AND LOGIN = true;
> LIST ALL PERMISSIONS OF 'child'; -- You are not authorized to view child's
> permissions
> {code}
> When a user creates a role they should get the {{DESCRIBE}} permission on
> that role by default.
--
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-17036) Add logging and metrics to Index Summary Redistribution
[ https://issues.apache.org/jira/browse/CASSANDRA-17036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17036: Reviewers: Marcus Eriksson Status: Review In Progress (was: Patch Available) > Add logging and metrics to Index Summary Redistribution > --- > > Key: CASSANDRA-17036 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17036 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Streaming >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > We don't have much visibility into the performance / impact / time taken on > index summary redistribution, either in memory impact or time to execute. We > should add some metrics and slightly tweak the logging around that to make it > more useful. -- 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-17036) Add logging and metrics to Index Summary Redistribution
[ https://issues.apache.org/jira/browse/CASSANDRA-17036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-17036: Status: Ready to Commit (was: Review In Progress) +1 > Add logging and metrics to Index Summary Redistribution > --- > > Key: CASSANDRA-17036 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17036 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Streaming >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > We don't have much visibility into the performance / impact / time taken on > index summary redistribution, either in memory impact or time to execute. We > should add some metrics and slightly tweak the logging around that to make it > more useful. -- 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=17428014#comment-17428014 ] Yuqi Gu commented on CASSANDRA-17019: - The log of unit tests was attached. It seems 19 test cases were failed, which are related to "snappy". > 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-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 ] Yuqi Gu updated CASSANDRA-17019: Attachment: cassandra_UTs.txt > 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-14795) Expose information about stored hints via a nodetool command and a virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-14795:
--
Fix Version/s: (was: 4.x)
4.1
Source Control Link:
https://github.com/apache/cassandra/commit/fc27042f61a6d78ec998a0186a5e97def90fd50a
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed! Thank you [~Ge]!
> Expose information about stored hints via a nodetool command and a virtual
> table
>
>
> Key: CASSANDRA-14795
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14795
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
> Fix For: 4.1
>
> Time Spent: 7h 10m
> Remaining Estimate: 0h
>
> Currently there is no way to determine what kind of hints a node has, apart
> from looking at the filenames (thus host-ids) on disk. Having a way to access
> this information would help with debugging hint creation/replay scenarios.
> In addition to the JMX method, there is a new nodetool command:
> {noformat}$ bin/nodetool -h 127.0.0.1 -p 7100 listendpointspendinghints
> Host ID Address Rack DC Status Total files Newest Oldest
> 5762b140-3fdf-4057-9ca7-05c070ccc9c3 127.0.0.2 rack1 datacenter1 DOWN 2
> 2018-09-18 14:05:18,835 2018-09-18 14:05:08,811
> {noformat}
--
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-14795) Expose information about stored hints via a nodetool command and a virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-14795:
--
Summary: Expose information about stored hints via a nodetool command and a
virtual table (was: Expose information about stored hints via JMX)
> Expose information about stored hints via a nodetool command and a virtual
> table
>
>
> Key: CASSANDRA-14795
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14795
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 7h 10m
> Remaining Estimate: 0h
>
> Currently there is no way to determine what kind of hints a node has, apart
> from looking at the filenames (thus host-ids) on disk. Having a way to access
> this information would help with debugging hint creation/replay scenarios.
> In addition to the JMX method, there is a new nodetool command:
> {noformat}$ bin/nodetool -h 127.0.0.1 -p 7100 listendpointspendinghints
> Host ID Address Rack DC Status Total files Newest Oldest
> 5762b140-3fdf-4057-9ca7-05c070ccc9c3 127.0.0.2 rack1 datacenter1 DOWN 2
> 2018-09-18 14:05:18,835 2018-09-18 14:05:08,811
> {noformat}
--
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
[cassandra] branch trunk updated: Expose information about stored hints via a nodetool command and a virtual table
This is an automated email from the ASF dual-hosted git repository. azotcsit pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/trunk by this push: new fc27042 Expose information about stored hints via a nodetool command and a virtual table fc27042 is described below commit fc27042f61a6d78ec998a0186a5e97def90fd50a Author: Aleksandr Sorokoumov AuthorDate: Fri Aug 6 15:46:50 2021 +0200 Expose information about stored hints via a nodetool command and a virtual table Patch by Aleksandr Sorokoumov; reviewed by Ekaterina Dimitrova, Stefan Miklosovic and Aleksei Zotov for CASSANDRA-14795 --- CHANGES.txt| 1 + NEWS.txt | 2 + .../cassandra/db/virtual/PendingHintsTable.java| 115 .../cassandra/db/virtual/SystemViewsKeyspace.java | 1 + .../cassandra/hints/HintsDispatchExecutor.java | 36 +-- .../org/apache/cassandra/hints/HintsService.java | 26 + .../apache/cassandra/hints/HintsServiceMBean.java | 10 ++ .../org/apache/cassandra/hints/HintsStore.java | 23 .../apache/cassandra/hints/PendingHintsInfo.java | 87 +++ src/java/org/apache/cassandra/tools/NodeProbe.java | 15 +++ src/java/org/apache/cassandra/tools/NodeTool.java | 1 + .../cassandra/tools/nodetool/ListPendingHints.java | 98 + .../cassandra/hints/HintServiceBytemanTest.java| 117 + .../apache/cassandra/hints/HintsServiceTest.java | 98 ++--- .../org/apache/cassandra/hints/HintsStoreTest.java | 23 +++- .../org/apache/cassandra/hints/HintsTestUtil.java | 86 +++ 16 files changed, 639 insertions(+), 100 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 424781c..d910c80 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.1 + * Expose information about stored hints via a nodetool command and a virtual table (CASSANDRA-14795) * Add broadcast_rpc_address to system.local (CASSANDRA-11181) * Add support for type casting in WHERE clause components and in the values of INSERT/UPDATE statements (CASSANDRA-14337) * add credentials file support to CQLSH (CASSANDRA-16983) diff --git a/NEWS.txt b/NEWS.txt index 6121525..0bec628 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -56,6 +56,8 @@ Upgrading confirm it is set to value lower than 31 otherwise Cassandra will fail to start. See CASSANDRA-9384 for further details. You also need to regenerate passwords for users for who the password was created while the above property was set to be more than 30 otherwise they will not be able to log in. +- Information about pending hints is now available through `nodetool listpendinghints` and `pending_hints` virtual + table. Deprecation --- diff --git a/src/java/org/apache/cassandra/db/virtual/PendingHintsTable.java b/src/java/org/apache/cassandra/db/virtual/PendingHintsTable.java new file mode 100644 index 000..55d648c --- /dev/null +++ b/src/java/org/apache/cassandra/db/virtual/PendingHintsTable.java @@ -0,0 +1,115 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.cassandra.db.virtual; + +import java.net.InetAddress; +import java.util.Collections; +import java.util.Date; +import java.util.List; +import java.util.Map; + +import org.apache.cassandra.config.DatabaseDescriptor; +import org.apache.cassandra.db.marshal.InetAddressType; +import org.apache.cassandra.db.marshal.Int32Type; +import org.apache.cassandra.db.marshal.TimestampType; +import org.apache.cassandra.db.marshal.UTF8Type; +import org.apache.cassandra.db.marshal.UUIDType; +import org.apache.cassandra.dht.LocalPartitioner; +import org.apache.cassandra.gms.FailureDetector; +import org.apache.cassandra.gms.FailureDetectorMBean; +import org.apache.cassandra.hints.HintsService; +import org.apache.cassandra.hints.PendingHintsInfo; +import org.apache.cassandra.locator.IEndpointSnitch; +import org.apache.cassandra.locator.InetAddressAndPort; +import org.apache.cassandra.schema.TableMetadata; +import
[jira] [Commented] (CASSANDRA-17031) Add support for PEM based key material for SSL
[
https://issues.apache.org/jira/browse/CASSANDRA-17031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427989#comment-17427989
]
Derek Chen-Becker commented on CASSANDRA-17031:
---
Generally this looks good, but I would call out that I think it would be better
if we followed the example in
https://issues.apache.org/jira/browse/CASSANDRA-16983 and don't put sensitive
material (the private key password) in the config file, but rather in a
separate secured file.
> Add support for PEM based key material for SSL
> --
>
> Key: CASSANDRA-17031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17031
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
>
> h1. Scope
> Currently Cassandra supports standard keystore types for SSL
> keys/certificates. The scope of this enhancement is to add support for PEM
> based key material (keys/certificate) given that PEM is widely used common
> format for the same. We intend to add support for Password Based Encrypted
> (PBE) PEM Private Keys with standard algorithms along with the certificate
> chain for the private key and PEM based certificates. The work here is going
> to be built on top of [CEP-9: Make SSLContext creation
> pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable]
> for which the code is merged for Apache Cassandra 4.1 release.
> We intend to support the key material be configured as direct PEM values
> input OR via the file (configured with keystore and truststore configurations
> today). We are not going to model PEM as a valid 'store_type' given that
> 'store_type' has a [specific
> definition|https://docs.oracle.com/en/java/javase/11/security/java-cryptography-architecture-jca-reference-guide.html#GUID-AB51DEFD-5238-4F96-967F-082F6D34FBEA].
>
> h1. Approach
> Create an implementation for
> [ISslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/ISslContextFactory.java]
> extending
> [FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java]
> implementation to add PEM formatted key/certificates.
> h1. Motivation
> PEM is a widely used format for encoding Private Keys and X.509 Certificates
> and Apache Cassandra's current implementation lacks the support for
> specifying the PEM formatted key material for SSL configurations. This means
> operators have to re-create the key material to comply to the supported
> formats (using key/trust store types - jks, pkcs12 etc) and deal with an
> operational task for managing it. This is an operational overhead we can
> avoid by supporting the PEM format making Apache Cassandra even more customer
> friendly and drive more adoption.
> h1. Proposed Changes
> # A new implementation for ISslContextFactory - PEMBasedSslContextFactory
> with the following supported configuration
> {panel:title=New configurations}
> {panel}
> |{{encryption_options: }}
> {{}}{{ssl_context_factory:}}
> {{}}{{class_name:
> org.apache.cassandra.security.PEMBasedSslContextFactory}}
> {{}}{{parameters:}}
> {{ }}{{private_key: certificate chain>}}
> {{ }}{{private_key_password: {{key }}{{if}} {{it is encrypted>}}
> {{ }}{{trusted_certificates: }}|
> *NOTE:* We could reuse 'keystore_password' instead of the
> 'private_key_password'. However PEM encoded private key is not a 'keystore'
> in itself hence it would be inappropriate to piggyback on that other than
> avoid duplicating similar fields.
> # The PEMBasedSslContextFactory will also support file based key material
> (and the corresponding HOT Reloading based on file timestamp updates) for the
> PEM format via existing 'keystore' and 'truststore' encryption options.
> However in that case the 'truststore_password' configuration won't be used
> since generally PEM formatted certificates for truststore don't get encrypted
> with a password.
> # The PEMBasedSslContextFactory will internally create PKCS12 keystore for
> private key and the trusted certificates. However, this doesn't impact the
> user of the implementation in anyway and it is mentioned for clarity only.
>
--
This message was sent by Atlassian Jira
(v8.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-14557) Add default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427963#comment-17427963
]
Sumanth Pasupuleti commented on CASSANDRA-14557:
I've squashed the changes, ready to be committed
https://github.com/sumanth-pasupuleti/cassandra/tree/14557-trunk
> Add default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.1
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
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-15433) Pending ranges are not recalculated on keyspace creation
[
https://issues.apache.org/jira/browse/CASSANDRA-15433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427960#comment-17427960
]
Sumanth Pasupuleti commented on CASSANDRA-15433:
[~ifesdjeen] curious if you will be able to commit this patch
> Pending ranges are not recalculated on keyspace creation
>
>
> Key: CASSANDRA-15433
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15433
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Josh Snyder
>Assignee: Sumanth Pasupuleti
>Priority: Normal
>
> When a node begins bootstrapping, Cassandra recalculates pending tokens for
> each keyspace that exists when the state change is observed (in
> StorageService:handleState*). When new keyspaces are created, we do not
> recalculate pending ranges (around Schema:merge). As a result, writes for new
> keyspaces are not received by nodes in BOOT or BOOT_REPLACE modes. When
> bootstrapping finishes, the node which just bootstrapped will not have data
> for the newly created keyspace.
> Consider a ring with bootstrapped nodes A, B, and C. Node D is pending, and
> when it finishes bootstrapping, C will cede ownership of some ranges to D. A
> quorum write is acknowledged by C and A. B missed the write, and the
> coordinator didn't send it to D at all. When D finishes bootstrapping, the
> quorum B+D will not contain the mutation.
> Steps to reproduce:
> # Join a node in BOOT mode
> # Create a keyspace
> # Send writes to that keyspace
> # On the joining node, observe that {{nodetool cfstats}} records zero writes
> to the new keyspace
> I have observed this directly in Cassandra 3.0, and based on my reading the
> code, I believe it affects up through trunk.
--
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-16843) auto-snapshots for dropped tables don't appear in nodetool listsnapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta reassigned CASSANDRA-16843:
---
Assignee: Paulo Motta
> auto-snapshots for dropped tables don't appear in nodetool listsnapshots
>
>
> Key: CASSANDRA-16843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16843
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: James Brown
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> Auto snapshots from dropped tables don't seem to show up in {{nodetool
> listsnapshots}} (even though they do get cleared by {{nodetool
> clearsnapshot}}). This makes them kind of annoying to clean up, since you
> need to muck about in the data directory to find them.
> Erick on the mailing list said that this seems to be an oversight and that
> clearsnapshot was fixed by
> [CASSANDRA-6418|https://issues.apache.org/jira/browse/CASSANDRA-6418].
> I reproduced this both on 3.11.11 and 4.0.0.
--
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-17027) Allow to grant permission for all tables in a keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427927#comment-17427927 ] Ekaterina Dimitrova commented on CASSANDRA-17027: - I second [~adelapena], added just a few super nits. I suspect you intentionally didn't add anything to the docs because of the current docs migration? I would like to suggest we open a placeholder ticket to add info to the docs later so we don't forget. At least I will forget probably :D > Allow to grant permission for all tables in a keyspace > --- > > Key: CASSANDRA-17027 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17027 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Syntax, Feature/Authorization >Reporter: Benjamin Lerer >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 4.x > > Time Spent: 40m > Remaining Estimate: 0h > > In some scenario it is useful to prevent users to alter or drop a keyspace > while allowing them to create new tables and user types. -- 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
[cassandra] branch trunk updated (243d220 -> 8f2bf50)
This is an automated email from the ASF dual-hosted git repository. maedhroz pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 243d220 store FBUtilities.getJustBroadcastNativeAddress() in system.local for rpc_address column new 4cc6375 ninja-fix: correct issue reference for CASSANDRA-16883 in ReadCallback comments new d2d5ce8 Merge branch 'cassandra-3.0' into cassandra-3.11 new 96a5e0f Merge branch 'cassandra-3.11' into cassandra-4.0 new 8f2bf50 Merge branch 'cassandra-4.0' into trunk The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. maedhroz pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 8f2bf50abece27432993f312df7ca7e34aff4a76 Merge: 243d220 96a5e0f Author: Caleb Rackliffe AuthorDate: Tue Oct 12 16:47:35 2021 -0500 Merge branch 'cassandra-4.0' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (9d28beb -> d2d5ce8)
This is an automated email from the ASF dual-hosted git repository. maedhroz pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 9d28beb Merge branch 'cassandra-3.0' into cassandra-3.11 new 4cc6375 ninja-fix: correct issue reference for CASSANDRA-16883 in ReadCallback comments new d2d5ce8 Merge branch 'cassandra-3.0' into cassandra-3.11 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: src/java/org/apache/cassandra/service/ReadCallback.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (e57a8dd -> 96a5e0f)
This is an automated email from the ASF dual-hosted git repository. maedhroz pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from e57a8dd Merge branch 'cassandra-3.11' into cassandra-4.0 new 4cc6375 ninja-fix: correct issue reference for CASSANDRA-16883 in ReadCallback comments new d2d5ce8 Merge branch 'cassandra-3.0' into cassandra-3.11 new 96a5e0f Merge branch 'cassandra-3.11' into cassandra-4.0 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository. maedhroz pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 96a5e0feedba067c74f59bf7d71553f9ff318983 Merge: e57a8dd d2d5ce8 Author: Caleb Rackliffe AuthorDate: Tue Oct 12 16:40:59 2021 -0500 Merge branch 'cassandra-3.11' into cassandra-4.0 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated: ninja-fix: correct issue reference for CASSANDRA-16883 in ReadCallback comments
This is an automated email from the ASF dual-hosted git repository.
maedhroz pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
new 4cc6375 ninja-fix: correct issue reference for CASSANDRA-16883 in
ReadCallback comments
4cc6375 is described below
commit 4cc63755564819d68a8b3548a2c8869ed9465b21
Author: Caleb Rackliffe
AuthorDate: Tue Oct 12 16:33:45 2021 -0500
ninja-fix: correct issue reference for CASSANDRA-16883 in ReadCallback
comments
---
src/java/org/apache/cassandra/service/ReadCallback.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/java/org/apache/cassandra/service/ReadCallback.java
b/src/java/org/apache/cassandra/service/ReadCallback.java
index 4dc7b8d..9a632cf 100644
--- a/src/java/org/apache/cassandra/service/ReadCallback.java
+++ b/src/java/org/apache/cassandra/service/ReadCallback.java
@@ -163,7 +163,7 @@ public class ReadCallback implements
IAsyncCallbackWithFailure
* Ensure that data is present and the response accumulator has
properly published the
* responses it has received. This may result in not signaling
immediately when we receive
* the minimum number of required results, but it guarantees at least
the minimum will
- * be accessible when we do signal. (see rdar://77320313)
+ * be accessible when we do signal. (see CASSANDRA-16883)
*/
if (n >= blockfor && resolver.responses.size() >= blockfor &&
resolver.isDataPresent())
{
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. maedhroz pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit d2d5ce855a71291387f16ad1b0283677054948f6 Merge: 9d28beb 4cc6375 Author: Caleb Rackliffe AuthorDate: Tue Oct 12 16:38:16 2021 -0500 Merge branch 'cassandra-3.0' into cassandra-3.11 src/java/org/apache/cassandra/service/ReadCallback.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14557) Add default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-14557:
--
Status: Ready to Commit (was: Review In Progress)
> Add default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.1
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
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-14557) Add default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-14557:
--
Status: Review In Progress (was: Needs Committer)
> Add default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.1
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
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-14557) Add default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-14557:
--
Reviewers: Aleksei Zotov, Stefan Miklosovic (was: Stefan Miklosovic)
> Add default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.1
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
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-17035) Issue num_tokens on cassandra after perform snapshot restore - Cassandra 3.11.10 and 3.11.11
[
https://issues.apache.org/jira/browse/CASSANDRA-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427921#comment-17427921
]
Brandon Williams commented on CASSANDRA-17035:
--
I see new random tokens being generated in this log, so it's not exhibiting the
problem.
> Issue num_tokens on cassandra after perform snapshot restore - Cassandra
> 3.11.10 and 3.11.11
>
>
> Key: CASSANDRA-17035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17035
> Project: Cassandra
> Issue Type: Bug
>Reporter: Igor Marinho
>Priority: Urgent
> Attachments: system.log
>
>
> After upgrading from 3.0.13 to 3.11.10 I'm having issue when I retsore the
> data from the node. After the restore is done it changes the number of tokens
> from 256 to 512.In cassandra.yaml it still num_token: 256, so I have no idea
> what's going on here.
> {code:java}
> cassandra.yaml value -> num_tokens: 256{code}
> These are the steps I'm performing
>
> {code:java}
> rm -rf /var/lib/cassandra/data/*
> rm -rf /var/lib/cassandra/commitlog/*
> rm -rf /var/lib/cassandra/saved_caches/*
> rm -rf /var/lib/cassandra/hints/*
> tar -xvf $BACKUP_LOC/$BACKUP_NAME.tar -C /
> find ${DATA_DIR} -mindepth 2 -path "*/snapshots/${BACKUP_NAME}/*" -type f
> \-exec bash -c 'dir={} && cd ${dir%/*} && mv {} ../..' \;
> nodetool -u $NODETOOL_USR -pw $NODETOOL_PASSWD -h $(hostname) refresh
> $keyspace $table --ssl
> {code}
>
> When I restart the node after perfoming the steps above it changes the tokens
> from 256 to 512.
> ERROR:
>
> {code:java}
> ERROR [main] 2021-10-07 15:16:24,060 CassandraDaemon.java:803 - Fatal
> configuration error org.apache.cassandra.exceptions.ConfigurationException:
> Cannot change the number of tokens from 512 to 256 at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1102)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:760)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:694)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.11.jar:3.11.11] INFO [StorageServiceShutdownHook]
> 2021-10-07 15:16:24,064 HintsService.java:209 - Paused hints dispatch INFO
> [StorageServiceShutdownHook] 2021-10-07 15:16:24,064 Gossiper.java:1683 -
> Announcing shutdown
> {code}
> It happens even in a empty node that I'm not trying to restore data, it
> happens after deleting the data from /var/lib/cassandra and restarting the
> node.
>
> {code:java}
> IINFO [main] 2021-10-12 15:21:23,034 StorageService.java:778 - Loading
> persisted ring state
> INFO [main] 2021-10-12 15:21:23,085 StorageService.java:907 - Starting up
> server gossip
> INFO [main] 2021-10-12 15:21:23,108 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> INFO [main] 2021-10-12 15:21:23,109 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> ERROR [main] 2021-10-12 15:21:23,166 CassandraDaemon.java:803 - Fatal
> configuration error
> org.apache.cassandra.exceptions.ConfigurationException: Cannot change the
> number of tokens from 512 to 256
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1078)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,168
> HintsService.java:209 - Paused hints dispatch
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,169 Gossiper.java:1662
> - Announcing shutdown
> {code}
> Any ideas on it?
> Thanks,
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For
[jira] [Updated] (CASSANDRA-14795) Expose information about stored hints via JMX
[
https://issues.apache.org/jira/browse/CASSANDRA-14795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-14795:
--
Status: Ready to Commit (was: Review In Progress)
I'll get it merged soon (tmrw afternoon my time).
> Expose information about stored hints via JMX
> -
>
> Key: CASSANDRA-14795
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14795
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 7h 10m
> Remaining Estimate: 0h
>
> Currently there is no way to determine what kind of hints a node has, apart
> from looking at the filenames (thus host-ids) on disk. Having a way to access
> this information would help with debugging hint creation/replay scenarios.
> In addition to the JMX method, there is a new nodetool command:
> {noformat}$ bin/nodetool -h 127.0.0.1 -p 7100 listendpointspendinghints
> Host ID Address Rack DC Status Total files Newest Oldest
> 5762b140-3fdf-4057-9ca7-05c070ccc9c3 127.0.0.2 rack1 datacenter1 DOWN 2
> 2018-09-18 14:05:18,835 2018-09-18 14:05:08,811
> {noformat}
--
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-17032) Allow configuring max allowable disk usage quota by keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-17032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427902#comment-17427902 ] Paulo Motta commented on CASSANDRA-17032: - All sounds good to me, except: bq. Maybe a couple JMX hooks to both set quota sizes and to reload quotas from CQL (break glass for operators) Having to broadcast JMX calls across all nodes to enforce a quota change feels less than ideal to me, I wonder if we should not make quotas a keyspace schema option, so quota updates are automatically broadcasted to all nodes? > Allow configuring max allowable disk usage quota by keyspace > > > Key: CASSANDRA-17032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17032 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > This is a similar idea (basically identical idea; didn't want to steamroll > that old ticket w/an update to description etc) to what was raised and closed > in CASSANDRA-5394. In multi-tenant situations it can be very helpful to > provide disk quotas per Keyspaces for users. > We can do this via a low priority background job that periodically checks > disk usage and flips a bit on the Keyspaces when it's over as well as reverts > it when things settle back down to prevent needing the read-before-write a > hard realtime requirement would introduce. While this would of course allow > users to "burst" their usage past that limit in the time window, it would > still be sufficient for many use-cases. -- 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-17035) Issue num_tokens on cassandra after perform snapshot restore - Cassandra 3.11.10 and 3.11.11
[
https://issues.apache.org/jira/browse/CASSANDRA-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Marinho updated CASSANDRA-17035:
-
Attachment: system.log
> Issue num_tokens on cassandra after perform snapshot restore - Cassandra
> 3.11.10 and 3.11.11
>
>
> Key: CASSANDRA-17035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17035
> Project: Cassandra
> Issue Type: Bug
>Reporter: Igor Marinho
>Priority: Urgent
> Attachments: system.log
>
>
> After upgrading from 3.0.13 to 3.11.10 I'm having issue when I retsore the
> data from the node. After the restore is done it changes the number of tokens
> from 256 to 512.In cassandra.yaml it still num_token: 256, so I have no idea
> what's going on here.
> {code:java}
> cassandra.yaml value -> num_tokens: 256{code}
> These are the steps I'm performing
>
> {code:java}
> rm -rf /var/lib/cassandra/data/*
> rm -rf /var/lib/cassandra/commitlog/*
> rm -rf /var/lib/cassandra/saved_caches/*
> rm -rf /var/lib/cassandra/hints/*
> tar -xvf $BACKUP_LOC/$BACKUP_NAME.tar -C /
> find ${DATA_DIR} -mindepth 2 -path "*/snapshots/${BACKUP_NAME}/*" -type f
> \-exec bash -c 'dir={} && cd ${dir%/*} && mv {} ../..' \;
> nodetool -u $NODETOOL_USR -pw $NODETOOL_PASSWD -h $(hostname) refresh
> $keyspace $table --ssl
> {code}
>
> When I restart the node after perfoming the steps above it changes the tokens
> from 256 to 512.
> ERROR:
>
> {code:java}
> ERROR [main] 2021-10-07 15:16:24,060 CassandraDaemon.java:803 - Fatal
> configuration error org.apache.cassandra.exceptions.ConfigurationException:
> Cannot change the number of tokens from 512 to 256 at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1102)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:760)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:694)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.11.jar:3.11.11] INFO [StorageServiceShutdownHook]
> 2021-10-07 15:16:24,064 HintsService.java:209 - Paused hints dispatch INFO
> [StorageServiceShutdownHook] 2021-10-07 15:16:24,064 Gossiper.java:1683 -
> Announcing shutdown
> {code}
> It happens even in a empty node that I'm not trying to restore data, it
> happens after deleting the data from /var/lib/cassandra and restarting the
> node.
>
> {code:java}
> IINFO [main] 2021-10-12 15:21:23,034 StorageService.java:778 - Loading
> persisted ring state
> INFO [main] 2021-10-12 15:21:23,085 StorageService.java:907 - Starting up
> server gossip
> INFO [main] 2021-10-12 15:21:23,108 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> INFO [main] 2021-10-12 15:21:23,109 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> ERROR [main] 2021-10-12 15:21:23,166 CassandraDaemon.java:803 - Fatal
> configuration error
> org.apache.cassandra.exceptions.ConfigurationException: Cannot change the
> number of tokens from 512 to 256
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1078)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,168
> HintsService.java:209 - Paused hints dispatch
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,169 Gossiper.java:1662
> - Announcing shutdown
> {code}
> Any ideas on it?
> Thanks,
--
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-17032) Allow configuring max allowable disk usage quota by keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427898#comment-17427898
]
Josh McKenzie commented on CASSANDRA-17032:
---
{quote}I wonder if we should send quota exceeded warnings at the 65%, 75%, 85%
marks (configurable)
{quote}
Was thinking along the same lines this morning. So if we add:
* A soft cap (configurable per Keyspace)
* A hard cap (configurable per Keyspace) (effectively this is all this first
iteration does)
* More visible behavior when at various caps (log warning, diag event(s),
client warnings)
* Maybe a couple JMX hooks to both set quota sizes and to reload quotas from
CQL (break glass for operators)
That'd make it a much more flexible feature, and also give us the best of both
worlds (lazy reactive eval on the way up so no read-before-write, then ability
to deterministically change it if needed for operators when things are back in
line). wdyt [~paulo]?
> Allow configuring max allowable disk usage quota by keyspace
>
>
> Key: CASSANDRA-17032
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17032
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> This is a similar idea (basically identical idea; didn't want to steamroll
> that old ticket w/an update to description etc) to what was raised and closed
> in CASSANDRA-5394. In multi-tenant situations it can be very helpful to
> provide disk quotas per Keyspaces for users.
> We can do this via a low priority background job that periodically checks
> disk usage and flips a bit on the Keyspaces when it's over as well as reverts
> it when things settle back down to prevent needing the read-before-write a
> hard realtime requirement would introduce. While this would of course allow
> users to "burst" their usage past that limit in the time window, it would
> still be sufficient for many use-cases.
--
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-17035) Issue num_tokens on cassandra after perform snapshot restore - Cassandra 3.11.10 and 3.11.11
[
https://issues.apache.org/jira/browse/CASSANDRA-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427897#comment-17427897
]
Igor Marinho commented on CASSANDRA-17035:
--
During the restore I saw these errors:
{code:java}
nodetool: Unknown keyspace/cf pair (system.schema_keyspaces)
See 'nodetool help' or 'nodetool help '.
nodetool: Unknown keyspace/cf pair (system.schema_columnfamilies)
See 'nodetool help' or 'nodetool help '.
nodetool: Unknown keyspace/cf pair (system.schema_columns)
See 'nodetool help' or 'nodetool help '.
nodetool: Unknown keyspace/cf pair (system.schema_triggers)
See 'nodetool help' or 'nodetool help '.
nodetool: Unknown keyspace/cf pair (system.schema_usertypes)
See 'nodetool help' or 'nodetool help '.
nodetool: Unknown keyspace/cf pair (system.schema_functions)
See 'nodetool help' or 'nodetool help '.
nodetool: Unknown keyspace/cf pair (system.schema_aggregates)
See 'nodetool help' or 'nodetool help '.
{code}
Could this be related to this issue?
> Issue num_tokens on cassandra after perform snapshot restore - Cassandra
> 3.11.10 and 3.11.11
>
>
> Key: CASSANDRA-17035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17035
> Project: Cassandra
> Issue Type: Bug
>Reporter: Igor Marinho
>Priority: Urgent
>
> After upgrading from 3.0.13 to 3.11.10 I'm having issue when I retsore the
> data from the node. After the restore is done it changes the number of tokens
> from 256 to 512.In cassandra.yaml it still num_token: 256, so I have no idea
> what's going on here.
> {code:java}
> cassandra.yaml value -> num_tokens: 256{code}
> These are the steps I'm performing
>
> {code:java}
> rm -rf /var/lib/cassandra/data/*
> rm -rf /var/lib/cassandra/commitlog/*
> rm -rf /var/lib/cassandra/saved_caches/*
> rm -rf /var/lib/cassandra/hints/*
> tar -xvf $BACKUP_LOC/$BACKUP_NAME.tar -C /
> find ${DATA_DIR} -mindepth 2 -path "*/snapshots/${BACKUP_NAME}/*" -type f
> \-exec bash -c 'dir={} && cd ${dir%/*} && mv {} ../..' \;
> nodetool -u $NODETOOL_USR -pw $NODETOOL_PASSWD -h $(hostname) refresh
> $keyspace $table --ssl
> {code}
>
> When I restart the node after perfoming the steps above it changes the tokens
> from 256 to 512.
> ERROR:
>
> {code:java}
> ERROR [main] 2021-10-07 15:16:24,060 CassandraDaemon.java:803 - Fatal
> configuration error org.apache.cassandra.exceptions.ConfigurationException:
> Cannot change the number of tokens from 512 to 256 at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1102)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:760)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:694)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.11.jar:3.11.11] INFO [StorageServiceShutdownHook]
> 2021-10-07 15:16:24,064 HintsService.java:209 - Paused hints dispatch INFO
> [StorageServiceShutdownHook] 2021-10-07 15:16:24,064 Gossiper.java:1683 -
> Announcing shutdown
> {code}
> It happens even in a empty node that I'm not trying to restore data, it
> happens after deleting the data from /var/lib/cassandra and restarting the
> node.
>
> {code:java}
> IINFO [main] 2021-10-12 15:21:23,034 StorageService.java:778 - Loading
> persisted ring state
> INFO [main] 2021-10-12 15:21:23,085 StorageService.java:907 - Starting up
> server gossip
> INFO [main] 2021-10-12 15:21:23,108 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> INFO [main] 2021-10-12 15:21:23,109 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> ERROR [main] 2021-10-12 15:21:23,166 CassandraDaemon.java:803 - Fatal
> configuration error
> org.apache.cassandra.exceptions.ConfigurationException: Cannot change the
> number of tokens from 512 to 256
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1078)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
>
[jira] [Commented] (CASSANDRA-14557) Add default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427895#comment-17427895
]
Aleksei Zotov commented on CASSANDRA-14557:
---
LGTM, +1.
> Add default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.1
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
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-17032) Allow configuring max allowable disk usage quota by keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-17032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427892#comment-17427892 ] Paulo Motta commented on CASSANDRA-17032: - This is a very useful feature. My only concern is suddenly start rejecting requests which may cause unexpected outages that may surprise unaware clients. I wonder if we should send quota exceeded warnings at the 65%, 75%, 85% marks (configurable), to give clients prior warning that their access is going to be denied if they don't take action, perhaps: * log warnings * diagnostics events * client warnings We should also probably add an easy way for clients to easily disable the quota for a specific keyspace as a break the glass mechanism to avoid outages, perhaps add an enabled flag per keyspace to the system table? > Allow configuring max allowable disk usage quota by keyspace > > > Key: CASSANDRA-17032 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17032 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > This is a similar idea (basically identical idea; didn't want to steamroll > that old ticket w/an update to description etc) to what was raised and closed > in CASSANDRA-5394. In multi-tenant situations it can be very helpful to > provide disk quotas per Keyspaces for users. > We can do this via a low priority background job that periodically checks > disk usage and flips a bit on the Keyspaces when it's over as well as reverts > it when things settle back down to prevent needing the read-before-write a > hard realtime requirement would introduce. While this would of course allow > users to "burst" their usage past that limit in the time window, it would > still be sufficient for many use-cases. -- 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-17009) Sstableverify unit test operate on SSTables
[ https://issues.apache.org/jira/browse/CASSANDRA-17009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Houser updated CASSANDRA-17009: - Mentor: Berenguer Blasi Status: Review In Progress (was: Changes Suggested) Added new commit and rebased against the current cassandra 4.0. added -c test (working and failed) addressed other comments > Sstableverify unit test operate on SSTables > --- > > Key: CASSANDRA-17009 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17009 > Project: Cassandra > Issue Type: Sub-task > Components: Tool/sstable >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Time Spent: 2h > Remaining Estimate: 0h > > as part of https://issues.apache.org/jira/browse/CASSANDRA-16009, unit > coverage is a bit lax and doesn't run through the verifier (based on my > coverage results). > There should be a unit test that exercises the internal verifier both for a > corrupt example and a working example. -- 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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427804#comment-17427804
]
Tatu Saloranta edited comment on CASSANDRA-15453 at 10/12/21, 7:11 PM:
---
Diff for patch to use Guava 19.0: [^cass-3.11-guava-19.0.patch]
Passes local test suite (ant clean test) without failures.
And matching PR:
https://github.com/apache/cassandra/pull/1265
was (Author: cowtowncoder):
Diff for patch to use Guava 19.0: [^cass-3.11-guava-19.0.patch]
Passes local test suite (ant clean test) without failures.
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427876#comment-17427876
]
Tatu Saloranta commented on CASSANDRA-15453:
Thank you [~slachiewicz]
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427804#comment-17427804
]
Tatu Saloranta edited comment on CASSANDRA-15453 at 10/12/21, 7:05 PM:
---
Diff for patch to use Guava 19.0: [^cass-3.11-guava-19.0.patch]
Passes local test suite (ant clean test) without failures.
was (Author: cowtowncoder):
Diff for patch to use Guava 19.0: [^cass-3.11-guava-19.0.patch]
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-16334) Replica failure causes timeout on multi-DC write
[
https://issues.apache.org/jira/browse/CASSANDRA-16334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427856#comment-17427856
]
Andres de la Peña commented on CASSANDRA-16334:
---
[~Ge] here are CircleCI runs for the patches:
||branch||CI||
|3.0|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/999/workflows/e3c6d75c-8c2c-4193-abea-7c1f582e27ee]|
|3.11|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/997/workflows/c6696afa-d529-4bb8-9fae-2880985417d1]|
|4.0|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/996/workflows/f37daddc-baec-48fa-8384-db5d15ae55b2]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/996/workflows/ec9dc32a-55d0-4032-a437-0a75d193ee99]|
|trunk|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/998/workflows/16728796-0e1b-4991-b579-e45a9dd39715]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/998/workflows/31dd24b9-2428-4142-8925-38f68007483f]|
They include 100 repeated runs for the new dtests. These runs are failing but I
think that's because of a problem with the Circle environment since they work
locally. I'll take a look at this.
> Replica failure causes timeout on multi-DC write
>
>
> Key: CASSANDRA-16334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16334
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Messaging/Internode
>Reporter: Paulo Motta
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Inserting a mutation larger than {{max_mutation_size_in_kb}} correctly throws
> a write error on a single DC keyspace with RF=3:
> {noformat}
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 0 responses and 3
> failures: UNKNOWN from /127.0.0.3:7000, UNKNOWN from /127.0.0.2:7000, UNKNOWN
> from /127.0.0.1:7000" info={'consistency': 'LOCAL_ONE', 'required_responses':
> 1, 'received_responses': 0, 'failures': 3}
> {noformat}
> The same insert wrongly causes a timeout on a keyspace with 2 dcs (RF=3 each):
> {noformat}
> cassandra.WriteTimeout: Error from server: code=1100 [Coordinator node timed
> out waiting for replica nodes' responses] message="Operation timed out -
> received only 0 responses." info={'consistency': 'LOCAL_ONE',
> 'required_responses': 1, 'received_responses': 0}
> {noformat}
> Reproduction steps:
> {noformat}
> # Setup cluster
> ccm create -n 3:3 test
> for i in {1..6}; do echo 'max_mutation_size_in_kb: 1000' >>
> ~/.ccm/test/node$i/conf/cassandra.yaml; done
> ccm start
> # Create schema
> ccm node1 cqlsh
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'dc1': 3, 'dc2': 3};
> CREATE TABLE test.test (key int PRIMARY KEY, val blob);
> exit;
> # Insert data
> python
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect('test')
> blob = f = open("2mbBlob", "rb").read().hex()
> session.execute("INSERT INTO test (key, val) VALUES (1, textAsBlob('" + blob
> + "'))")
> {noformat}
> Reproduced in 3.0, 3.11, 4.0, trunk.
--
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-13857) Allow MV with only partition key
[
https://issues.apache.org/jira/browse/CASSANDRA-13857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427848#comment-17427848
]
Stefan Miklosovic commented on CASSANDRA-13857:
---
Hi guys [~jasonstack] [~blerer] [~adelapena]
checking again after couple of years if this is still relevant, no concerns
here? Am I ok to deliver?
> Allow MV with only partition key
>
>
> Key: CASSANDRA-13857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13857
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Kurt Greaves
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> We currently disallow creation of a view that has the exact same primary key
> as the base where no clustering keys are present, however a potential use
> case would be a view where part of the PK is filtered so as to have a subset
> of data in the view which is faster for range queries. We actually currently
> allow this, but only if you have a clustering key defined. If you only have a
> partitioning key it's not possible.
> From the mailing list, the below example works:
> {code:java}
> CREATE TABLE users (
> site_id int,
> user_id text,
> n int,
> data set>,
> PRIMARY KEY ((site_id, user_id), n));
> user data is updated and read by PK and sometimes I have to fetch all user
> for some specific site_id. It appeared that full scan by
> token(site_id,user_id) filtered by WHERE site_id = works much
> slower than unfiltered full scan on
> CREATE MATERIALIZED VIEW users_1 AS
> SELECT site_id, user_id, n, data
> FROM users
> WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
> PRIMARY KEY ((site_id, user_id), n);
> {code}
> However the following does not:
> {code:java}
> CREATE TABLE users (
> site_id int,
> user_id text,
> data set,
> PRIMARY KEY ((site_id, user_id)));
> CREATE MATERIALIZED VIEW users_1 AS
> SELECT site_id, user_id, data
> FROM users
> WHERE site_id = 1 AND user_id IS NOT NULL
> PRIMARY KEY ((site_id, user_id));
> InvalidRequest: Error from server: code=2200 [Invalid query] message="No
> columns are defined for Materialized View other than primary key"
> {code}
> This is because if the clustering key is empty we assume they've only defined
> the primary key in the partition key and we haven't accounted for this use
> case.
> On that note, we also don't allow the following narrowing of the partition
> key:
> {code}
> CREATE TABLE kurt.base (
> id int,
> uid text,
> data text,
> PRIMARY KEY (id, uid)
> )
> CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT
> NULL and uid='1' PRIMARY KEY ((id, uid));
> InvalidRequest: Error from server: code=2200 [Invalid query] message="No
> columns are defined for Materialized View other than primary key"
> {code}
> But we do allow the following, which works because there is still a
> clustering key, despite not changing the PK.
> {code}
> CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT
> NULL and uid='1' PRIMARY KEY (id, uid);
> {code}
> And we also allow the following, which is a narrowing of the partition key as
> above, but with an extra clustering key.
> {code}
> create table kurt.base3 (id int, uid int, clus1 int, clus2 int, data text,
> PRIMARY KEY ((id, uid), clus1, clus2));
> CREATE MATERIALIZED VIEW kurt.mv4 AS SELECT * from kurt.base3 where id IS NOT
> NULL and uid IS NOT NULL and clus1 IS NOT NULL AND clus2 IS NOT NULL PRIMARY
> KEY ((id, uid, clus1), clus2);
> {code}
> I _think_ supporting these cases is trivial and mostly already handled in the
> underlying MV write path, so we might be able to get away with just a simple
> change of [this
> condition|https://github.com/apache/cassandra/blob/83822d12d87dcb3aaad2b1e670e57ebef4ab1c36/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java#L291].
--
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-13857) Allow MV with only partition key
[
https://issues.apache.org/jira/browse/CASSANDRA-13857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic reassigned CASSANDRA-13857:
-
Assignee: Stefan Miklosovic (was: Alexander Ivakov)
> Allow MV with only partition key
>
>
> Key: CASSANDRA-13857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13857
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: Kurt Greaves
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> We currently disallow creation of a view that has the exact same primary key
> as the base where no clustering keys are present, however a potential use
> case would be a view where part of the PK is filtered so as to have a subset
> of data in the view which is faster for range queries. We actually currently
> allow this, but only if you have a clustering key defined. If you only have a
> partitioning key it's not possible.
> From the mailing list, the below example works:
> {code:java}
> CREATE TABLE users (
> site_id int,
> user_id text,
> n int,
> data set>,
> PRIMARY KEY ((site_id, user_id), n));
> user data is updated and read by PK and sometimes I have to fetch all user
> for some specific site_id. It appeared that full scan by
> token(site_id,user_id) filtered by WHERE site_id = works much
> slower than unfiltered full scan on
> CREATE MATERIALIZED VIEW users_1 AS
> SELECT site_id, user_id, n, data
> FROM users
> WHERE site_id = 1 AND user_id IS NOT NULL AND n IS NOT NULL
> PRIMARY KEY ((site_id, user_id), n);
> {code}
> However the following does not:
> {code:java}
> CREATE TABLE users (
> site_id int,
> user_id text,
> data set,
> PRIMARY KEY ((site_id, user_id)));
> CREATE MATERIALIZED VIEW users_1 AS
> SELECT site_id, user_id, data
> FROM users
> WHERE site_id = 1 AND user_id IS NOT NULL
> PRIMARY KEY ((site_id, user_id));
> InvalidRequest: Error from server: code=2200 [Invalid query] message="No
> columns are defined for Materialized View other than primary key"
> {code}
> This is because if the clustering key is empty we assume they've only defined
> the primary key in the partition key and we haven't accounted for this use
> case.
> On that note, we also don't allow the following narrowing of the partition
> key:
> {code}
> CREATE TABLE kurt.base (
> id int,
> uid text,
> data text,
> PRIMARY KEY (id, uid)
> )
> CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT
> NULL and uid='1' PRIMARY KEY ((id, uid));
> InvalidRequest: Error from server: code=2200 [Invalid query] message="No
> columns are defined for Materialized View other than primary key"
> {code}
> But we do allow the following, which works because there is still a
> clustering key, despite not changing the PK.
> {code}
> CREATE MATERIALIZED VIEW kurt.mv2 AS SELECT * from kurt.base where id IS NOT
> NULL and uid='1' PRIMARY KEY (id, uid);
> {code}
> And we also allow the following, which is a narrowing of the partition key as
> above, but with an extra clustering key.
> {code}
> create table kurt.base3 (id int, uid int, clus1 int, clus2 int, data text,
> PRIMARY KEY ((id, uid), clus1, clus2));
> CREATE MATERIALIZED VIEW kurt.mv4 AS SELECT * from kurt.base3 where id IS NOT
> NULL and uid IS NOT NULL and clus1 IS NOT NULL AND clus2 IS NOT NULL PRIMARY
> KEY ((id, uid, clus1), clus2);
> {code}
> I _think_ supporting these cases is trivial and mostly already handled in the
> underlying MV write path, so we might be able to get away with just a simple
> change of [this
> condition|https://github.com/apache/cassandra/blob/83822d12d87dcb3aaad2b1e670e57ebef4ab1c36/src/java/org/apache/cassandra/cql3/statements/CreateViewStatement.java#L291].
--
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=17427845#comment-17427845 ] Brandon Williams commented on CASSANDRA-17019: -- [Here|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17019] is a circle run on trunk too. > 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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427833#comment-17427833
]
Sylwester Lachiewicz commented on CASSANDRA-15453:
--
This can be helpful https://github.com/jsevellec/cassandra-unit/issues/211
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-17035) Issue num_tokens on cassandra after perform snapshot restore - Cassandra 3.11.10 and 3.11.11
[
https://issues.apache.org/jira/browse/CASSANDRA-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Marinho updated CASSANDRA-17035:
-
Attachment: (was: system.log)
> Issue num_tokens on cassandra after perform snapshot restore - Cassandra
> 3.11.10 and 3.11.11
>
>
> Key: CASSANDRA-17035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17035
> Project: Cassandra
> Issue Type: Bug
>Reporter: Igor Marinho
>Priority: Urgent
>
> After upgrading from 3.0.13 to 3.11.10 I'm having issue when I retsore the
> data from the node. After the restore is done it changes the number of tokens
> from 256 to 512.In cassandra.yaml it still num_token: 256, so I have no idea
> what's going on here.
> {code:java}
> cassandra.yaml value -> num_tokens: 256{code}
> These are the steps I'm performing
>
> {code:java}
> rm -rf /var/lib/cassandra/data/*
> rm -rf /var/lib/cassandra/commitlog/*
> rm -rf /var/lib/cassandra/saved_caches/*
> rm -rf /var/lib/cassandra/hints/*
> tar -xvf $BACKUP_LOC/$BACKUP_NAME.tar -C /
> find ${DATA_DIR} -mindepth 2 -path "*/snapshots/${BACKUP_NAME}/*" -type f
> \-exec bash -c 'dir={} && cd ${dir%/*} && mv {} ../..' \;
> nodetool -u $NODETOOL_USR -pw $NODETOOL_PASSWD -h $(hostname) refresh
> $keyspace $table --ssl
> {code}
>
> When I restart the node after perfoming the steps above it changes the tokens
> from 256 to 512.
> ERROR:
>
> {code:java}
> ERROR [main] 2021-10-07 15:16:24,060 CassandraDaemon.java:803 - Fatal
> configuration error org.apache.cassandra.exceptions.ConfigurationException:
> Cannot change the number of tokens from 512 to 256 at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1102)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:760)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:694)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.11.jar:3.11.11] INFO [StorageServiceShutdownHook]
> 2021-10-07 15:16:24,064 HintsService.java:209 - Paused hints dispatch INFO
> [StorageServiceShutdownHook] 2021-10-07 15:16:24,064 Gossiper.java:1683 -
> Announcing shutdown
> {code}
> It happens even in a empty node that I'm not trying to restore data, it
> happens after deleting the data from /var/lib/cassandra and restarting the
> node.
>
> {code:java}
> IINFO [main] 2021-10-12 15:21:23,034 StorageService.java:778 - Loading
> persisted ring state
> INFO [main] 2021-10-12 15:21:23,085 StorageService.java:907 - Starting up
> server gossip
> INFO [main] 2021-10-12 15:21:23,108 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> INFO [main] 2021-10-12 15:21:23,109 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> ERROR [main] 2021-10-12 15:21:23,166 CassandraDaemon.java:803 - Fatal
> configuration error
> org.apache.cassandra.exceptions.ConfigurationException: Cannot change the
> number of tokens from 512 to 256
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1078)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,168
> HintsService.java:209 - Paused hints dispatch
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,169 Gossiper.java:1662
> - Announcing shutdown
> {code}
> Any ideas on it?
> Thanks,
--
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-17035) Issue num_tokens on cassandra after perform snapshot restore - Cassandra 3.11.10 and 3.11.11
[
https://issues.apache.org/jira/browse/CASSANDRA-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Marinho updated CASSANDRA-17035:
-
Attachment: system.log
> Issue num_tokens on cassandra after perform snapshot restore - Cassandra
> 3.11.10 and 3.11.11
>
>
> Key: CASSANDRA-17035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17035
> Project: Cassandra
> Issue Type: Bug
>Reporter: Igor Marinho
>Priority: Urgent
> Attachments: system.log
>
>
> After upgrading from 3.0.13 to 3.11.10 I'm having issue when I retsore the
> data from the node. After the restore is done it changes the number of tokens
> from 256 to 512.In cassandra.yaml it still num_token: 256, so I have no idea
> what's going on here.
> {code:java}
> cassandra.yaml value -> num_tokens: 256{code}
> These are the steps I'm performing
>
> {code:java}
> rm -rf /var/lib/cassandra/data/*
> rm -rf /var/lib/cassandra/commitlog/*
> rm -rf /var/lib/cassandra/saved_caches/*
> rm -rf /var/lib/cassandra/hints/*
> tar -xvf $BACKUP_LOC/$BACKUP_NAME.tar -C /
> find ${DATA_DIR} -mindepth 2 -path "*/snapshots/${BACKUP_NAME}/*" -type f
> \-exec bash -c 'dir={} && cd ${dir%/*} && mv {} ../..' \;
> nodetool -u $NODETOOL_USR -pw $NODETOOL_PASSWD -h $(hostname) refresh
> $keyspace $table --ssl
> {code}
>
> When I restart the node after perfoming the steps above it changes the tokens
> from 256 to 512.
> ERROR:
>
> {code:java}
> ERROR [main] 2021-10-07 15:16:24,060 CassandraDaemon.java:803 - Fatal
> configuration error org.apache.cassandra.exceptions.ConfigurationException:
> Cannot change the number of tokens from 512 to 256 at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1102)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:760)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:694)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.11.jar:3.11.11] INFO [StorageServiceShutdownHook]
> 2021-10-07 15:16:24,064 HintsService.java:209 - Paused hints dispatch INFO
> [StorageServiceShutdownHook] 2021-10-07 15:16:24,064 Gossiper.java:1683 -
> Announcing shutdown
> {code}
> It happens even in a empty node that I'm not trying to restore data, it
> happens after deleting the data from /var/lib/cassandra and restarting the
> node.
>
> {code:java}
> IINFO [main] 2021-10-12 15:21:23,034 StorageService.java:778 - Loading
> persisted ring state
> INFO [main] 2021-10-12 15:21:23,085 StorageService.java:907 - Starting up
> server gossip
> INFO [main] 2021-10-12 15:21:23,108 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> INFO [main] 2021-10-12 15:21:23,109 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> ERROR [main] 2021-10-12 15:21:23,166 CassandraDaemon.java:803 - Fatal
> configuration error
> org.apache.cassandra.exceptions.ConfigurationException: Cannot change the
> number of tokens from 512 to 256
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1078)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,168
> HintsService.java:209 - Paused hints dispatch
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,169 Gossiper.java:1662
> - Announcing shutdown
> {code}
> Any ideas on it?
> Thanks,
--
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-4478) Make index_interval be measured in kb (instead of number of keys)
[ https://issues.apache.org/jira/browse/CASSANDRA-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-4478: Resolution: Not A Problem Status: Resolved (was: Open) With this property now removed, closing. > Make index_interval be measured in kb (instead of number of keys) > - > > Key: CASSANDRA-4478 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4478 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Sylvain Lebresne >Priority: Low > Fix For: 4.x > > Attachments: 4478-incomplete.txt > > > Currently, index_interval is measured in number of keys: how may keys before > adding an entry to the index summary. After CASSANDRA-2319, each index entry > also contains the columns index for the row, so index entry can be a bit > bigger and of differing sizes. Measuring in number of keys is thus > sub-optimal and difficult to tune, since you might want a different setting > depending of whether your rows are big or small, but the setting is global. > So we should move to measuring the interval in bytes. -- 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-16334) Replica failure causes timeout on multi-DC write
[
https://issues.apache.org/jira/browse/CASSANDRA-16334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16334:
--
Reviewers: Andres de la Peña, Andres de la Peña (was: Andres de la Peña)
Andres de la Peña, Andres de la Peña (was: Andres de la Peña)
Status: Review In Progress (was: Patch Available)
> Replica failure causes timeout on multi-DC write
>
>
> Key: CASSANDRA-16334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16334
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Messaging/Internode
>Reporter: Paulo Motta
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Inserting a mutation larger than {{max_mutation_size_in_kb}} correctly throws
> a write error on a single DC keyspace with RF=3:
> {noformat}
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 0 responses and 3
> failures: UNKNOWN from /127.0.0.3:7000, UNKNOWN from /127.0.0.2:7000, UNKNOWN
> from /127.0.0.1:7000" info={'consistency': 'LOCAL_ONE', 'required_responses':
> 1, 'received_responses': 0, 'failures': 3}
> {noformat}
> The same insert wrongly causes a timeout on a keyspace with 2 dcs (RF=3 each):
> {noformat}
> cassandra.WriteTimeout: Error from server: code=1100 [Coordinator node timed
> out waiting for replica nodes' responses] message="Operation timed out -
> received only 0 responses." info={'consistency': 'LOCAL_ONE',
> 'required_responses': 1, 'received_responses': 0}
> {noformat}
> Reproduction steps:
> {noformat}
> # Setup cluster
> ccm create -n 3:3 test
> for i in {1..6}; do echo 'max_mutation_size_in_kb: 1000' >>
> ~/.ccm/test/node$i/conf/cassandra.yaml; done
> ccm start
> # Create schema
> ccm node1 cqlsh
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'dc1': 3, 'dc2': 3};
> CREATE TABLE test.test (key int PRIMARY KEY, val blob);
> exit;
> # Insert data
> python
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect('test')
> blob = f = open("2mbBlob", "rb").read().hex()
> session.execute("INSERT INTO test (key, val) VALUES (1, textAsBlob('" + blob
> + "'))")
> {noformat}
> Reproduced in 3.0, 3.11, 4.0, trunk.
--
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-15044) LIST ALL; crashes with ServerError: java.lang.IllegalArgumentException: Name EESBKEYSPACE is not valid for any resource type
[
https://issues.apache.org/jira/browse/CASSANDRA-15044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15044:
-
Resolution: Cannot Reproduce
Status: Resolved (was: Open)
> LIST ALL; crashes with ServerError: java.lang.IllegalArgumentException: Name
> EESBKEYSPACE is not valid for any resource type
>
>
> Key: CASSANDRA-15044
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15044
> Project: Cassandra
> Issue Type: Bug
> Environment: [cqlsh 5.0.1 | Cassandra 3.11.2 | CQL spec 3.4.4 |
> Native protocol v4]
> Linux eu50mqvt006.area1.eurofins.local 3.10.0-693.17.1.el7.x86_64 #1 SMP Sun
> Jan 14 10:36:03 EST 2018 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Petr Kuzel
>Priority: Urgent
>
> Following crashes:
>
> *{{$CASSANDRA_HOME/bin/cqlsh -u admin -e "LIST ALL;"
> $HOSTNAME}}{{:1:ServerError: java.lang.IllegalArgumentException: Name
> EESBKEYSPACE is not valid for any resource type}}*
>
> While following passes:
> {{admin@cqlsh> list all of cassandra;}}
> {{role | username | resource | permission}}
> {{---+---+-+}}
> {{ cassandra | cassandra | | CREATE}}
> {{ cassandra | cassandra | | ALTER}}
> {{ cassandra | cassandra | | DROP}}
> {{ cassandra | cassandra | | SELECT}}
> {{ cassandra | cassandra | | MODIFY}}
> {{ cassandra | cassandra | | AUTHORIZE}}
> {{ cassandra | cassandra | |
> ALTER}}
> {{}}
>
> Apparently it depends on user because:
> {{admin@cqlsh> list all of admin;}}
> {{ServerError: java.lang.IllegalArgumentException: Name EESBKEYSPACE is not
> valid for any resource type}}
>
> When trying from the keyspace listing angle getting:
>
> {{admin@cqlsh> list all on eesbkeyspace.eesbmessage_monitoring;}}
> {{InvalidRequest: Error from server: code=2200 [Invalid query]
> message=" doesn't exist"}}
> Warning: This is strange as it comes from above list. Something is
> inconsistent/stale and might be related to the ServerError.
>
> Anyway let use existing table for the same:
> {{admin@cqlsh> list all on eesbkeyspace.message_monitoring;}}
> {{role | username | resource | permission}}
> {{---+---+-+}}
> {{ admin | admin | | CREATE}}
> {{ admin | admin | | ALTER}}
> {{ admin | admin | | DROP}}
> {{ admin | admin | | SELECT}}
> {{ admin | admin | | MODIFY}}
> {{ admin | admin | | AUTHORIZE}}
> {{ admin | admin | | ALTER}}
> {{ admin | admin | | DROP}}
> {{ admin | admin | | SELECT}}
> {{ admin | admin | | MODIFY}}
> {{ admin | admin | | AUTHORIZE}}
> {{ cassandra | cassandra | | CREATE}}
> {{ cassandra | cassandra | | ALTER}}
> {{ cassandra | cassandra | | DROP}}
> {{ cassandra | cassandra | | SELECT}}
> {{ cassandra | cassandra | | MODIFY}}
> {{ cassandra | cassandra | | AUTHORIZE}}
> {{ cassandra | cassandra | | ALTER}}
> {{ cassandra | cassandra | | DROP}}
> {{ cassandra | cassandra | | SELECT}}
> {{ cassandra | cassandra | | MODIFY}}
> {{ cassandra | cassandra | |
> AUTHORIZE}}
>
> That works.
>
> The keyspace itself:
> {{admin@cqlsh> describe keyspace eesbkeyspace;}}
> {{CREATE KEYSPACE eesbkeyspace WITH replication = \{'class':
> 'NetworkTopologyStrategy', ...} AND durable_writes = true;}}
> {{CREATE TABLE eesbkeyspace.coupa_monitoring (}}
> {{ ...}}
> {{}}{{CREATE TABLE eesbkeyspace.test_monitoring (}}
> {{...}}
> {{CREATE TABLE eesbkeyspace.genomics_monitoring (}}
> {{...}}
> {{CREATE TABLE eesbkeyspace.statistics (}}
> {{...}}
> {{CREATE TABLE eesbkeyspace.message_monitoring (}}
> {{...}}
> {{CREATE TABLE eesbkeyspace.genomics_monitoring_statistics (}}
> {{...}}
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tatu Saloranta updated CASSANDRA-15453:
---
Attachment: cass-3.11-guava-19.0.patch
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427804#comment-17427804
]
Tatu Saloranta commented on CASSANDRA-15453:
Diff for patch to use Guava 19.0: [^cass-3.11-guava-19.0.patch]
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt, cass-3.11-guava-19.0.patch
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427795#comment-17427795
]
Tatu Saloranta edited comment on CASSANDRA-15453 at 10/12/21, 5:09 PM:
---
Diff for patch to use Guava 20.0: - removed -
EDIT: unfortunately as I noted on CASSANDRA-15248 there is a test dependency
that croaks with Guava 20.0 (wrt something called `FutureFallback`), which
needs to be tackled separately. Since it's a test failure, not runtime, likely
would not affect users but I can't just break tests obviously.
So I will attach a patch for just going to 19.0 first, with fixes for
`CharMatcher.DIGIT` and `Futures.transform()`.
was (Author: cowtowncoder):
Diff for patch to use Guava 20.0: [^cass-3.11-diff.txt]
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15248) Upgrade Guava to latest on master branch
[ https://issues.apache.org/jira/browse/CASSANDRA-15248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413438#comment-17413438 ] Tatu Saloranta edited comment on CASSANDRA-15248 at 10/12/21, 5:03 PM: --- Looking at incompatibilities, alas, it gets tricky. The immediate problem is `Futures.transform()` (used in 2 non-test and 1 test class): while it translates to un-deprecated `Futures.transformAsync()`, latter is only introduced in 19.0 but former immediately deleted from 20.0 (thanks Guava). Further, something somewhere in tests refers to `FutureFallback` which is also removed from 20.0. That would also need to be patched. So maybe my idea of small changes to allow `cassandra-all` to work with newer versions (even if not upgrading dependency to require) is unworkable. Added notes just in case it helps anyone figure out a way. It would definitely be nice if Guava version dependency was not as strict as it now is. EDIT: `FutureFallback` likely comes via "cassandra-driver-core", version 3.0.1: upgrading this would likely resolve it. There is a small compilation problem from a test class if upgrading that dependency, likely simple to resolve (i.e. this one would not be a blocker). Looks like "cassandra-driver-core" 3.2.0 does resolve these, see – [https://datastax-oss.atlassian.net/browse/JAVA-1328] – but whether using that version otherwise works seems unsure. Based on version it'd make sense it did but... EDIT2: To replace `CharMatcher.DIGIT` (removed from guava 26?) one could use `CharMatcher.digit()` added in 19.0. So even that relatively small improvement would require small bump to Guava version. was (Author: cowtowncoder): Looking at incompatibilities, alas, it gets tricky. The immediate problem is `Futures.transform()` (used in 2 non-test and 1 test class): while it translates to un-deprecated `Futures.transformAsync()`, latter is only introduced in 19.0 but former immediately deleted from 20.0 (thanks Guava). Further, something somewhere in tests refers to `FutureCallback` which is also removed from 20.0. That would also need to be patched. So maybe my idea of small changes to allow `cassandra-all` to work with newer versions (even if not upgrading dependency to require) is unworkable. Added notes just in case it helps anyone figure out a way. It would definitely be nice if Guava version dependency was not as strict as it now is. EDIT: `FutureCallback` likely comes via "cassandra-driver-core", version 3.0.1: upgrading this would likely resolve it. There is a small compilation problem from a test class if upgrading that dependency, likely simple to resolve (i.e. this one would not be a blocker). Looks like "cassandra-driver-core" 3.2.0 does resolve these, see – [https://datastax-oss.atlassian.net/browse/JAVA-1328] – but using that version otherwise works seems unsure. Based on version it'd make sense it did but... EDIT2: To replace `CharMatcher.DIGIT` (removed from guava 26?) one could use `CharMatcher.digit()` added in 19.0. So even that relatively small improvement would require small bump to Guava version. > Upgrade Guava to latest on master branch > > > Key: CASSANDRA-15248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15248 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies, Packaging >Reporter: Abhijit Sarkar >Priority: Normal > > Upgrade Guava to latest on master branch. See > https://issues.apache.org/jira/browse/CASSANDRA-15245. -- 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-17035) Issue num_tokens on cassandra after perform snapshot restore - Cassandra 3.11.10 and 3.11.11
[
https://issues.apache.org/jira/browse/CASSANDRA-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427797#comment-17427797
]
Brandon Williams commented on CASSANDRA-17035:
--
Can you upload the full log?
> Issue num_tokens on cassandra after perform snapshot restore - Cassandra
> 3.11.10 and 3.11.11
>
>
> Key: CASSANDRA-17035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17035
> Project: Cassandra
> Issue Type: Bug
>Reporter: Igor Marinho
>Priority: Urgent
>
> After upgrading from 3.0.13 to 3.11.10 I'm having issue when I retsore the
> data from the node. After the restore is done it changes the number of tokens
> from 256 to 512.In cassandra.yaml it still num_token: 256, so I have no idea
> what's going on here.
> {code:java}
> cassandra.yaml value -> num_tokens: 256{code}
> These are the steps I'm performing
>
> {code:java}
> rm -rf /var/lib/cassandra/data/*
> rm -rf /var/lib/cassandra/commitlog/*
> rm -rf /var/lib/cassandra/saved_caches/*
> rm -rf /var/lib/cassandra/hints/*
> tar -xvf $BACKUP_LOC/$BACKUP_NAME.tar -C /
> find ${DATA_DIR} -mindepth 2 -path "*/snapshots/${BACKUP_NAME}/*" -type f
> \-exec bash -c 'dir={} && cd ${dir%/*} && mv {} ../..' \;
> nodetool -u $NODETOOL_USR -pw $NODETOOL_PASSWD -h $(hostname) refresh
> $keyspace $table --ssl
> {code}
>
> When I restart the node after perfoming the steps above it changes the tokens
> from 256 to 512.
> ERROR:
>
> {code:java}
> ERROR [main] 2021-10-07 15:16:24,060 CassandraDaemon.java:803 - Fatal
> configuration error org.apache.cassandra.exceptions.ConfigurationException:
> Cannot change the number of tokens from 512 to 256 at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1102)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:760)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:694)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.11.jar:3.11.11] INFO [StorageServiceShutdownHook]
> 2021-10-07 15:16:24,064 HintsService.java:209 - Paused hints dispatch INFO
> [StorageServiceShutdownHook] 2021-10-07 15:16:24,064 Gossiper.java:1683 -
> Announcing shutdown
> {code}
> It happens even in a empty node that I'm not trying to restore data, it
> happens after deleting the data from /var/lib/cassandra and restarting the
> node.
>
> {code:java}
> IINFO [main] 2021-10-12 15:21:23,034 StorageService.java:778 - Loading
> persisted ring state
> INFO [main] 2021-10-12 15:21:23,085 StorageService.java:907 - Starting up
> server gossip
> INFO [main] 2021-10-12 15:21:23,108 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> INFO [main] 2021-10-12 15:21:23,109 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> ERROR [main] 2021-10-12 15:21:23,166 CassandraDaemon.java:803 - Fatal
> configuration error
> org.apache.cassandra.exceptions.ConfigurationException: Cannot change the
> number of tokens from 512 to 256
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1078)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,168
> HintsService.java:209 - Paused hints dispatch
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,169 Gossiper.java:1662
> - Announcing shutdown
> {code}
> Any ideas on it?
> Thanks,
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tatu Saloranta updated CASSANDRA-15453:
---
Attachment: cass-3.11-diff.txt
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427795#comment-17427795
]
Tatu Saloranta commented on CASSANDRA-15453:
Diff for patch to use Guava 20.0: [^cass-3.11-diff.txt]
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
> Attachments: cass-3.11-diff.txt
>
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-17035) Issue num_tokens on cassandra after perform snapshot restore - Cassandra 3.11.10 and 3.11.11
[
https://issues.apache.org/jira/browse/CASSANDRA-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427794#comment-17427794
]
Igor Marinho commented on CASSANDRA-17035:
--
Everything is set to default path /var/lib/cassandra so, I do not think it's
the case.
> Issue num_tokens on cassandra after perform snapshot restore - Cassandra
> 3.11.10 and 3.11.11
>
>
> Key: CASSANDRA-17035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17035
> Project: Cassandra
> Issue Type: Bug
>Reporter: Igor Marinho
>Priority: Urgent
>
> After upgrading from 3.0.13 to 3.11.10 I'm having issue when I retsore the
> data from the node. After the restore is done it changes the number of tokens
> from 256 to 512.In cassandra.yaml it still num_token: 256, so I have no idea
> what's going on here.
> {code:java}
> cassandra.yaml value -> num_tokens: 256{code}
> These are the steps I'm performing
>
> {code:java}
> rm -rf /var/lib/cassandra/data/*
> rm -rf /var/lib/cassandra/commitlog/*
> rm -rf /var/lib/cassandra/saved_caches/*
> rm -rf /var/lib/cassandra/hints/*
> tar -xvf $BACKUP_LOC/$BACKUP_NAME.tar -C /
> find ${DATA_DIR} -mindepth 2 -path "*/snapshots/${BACKUP_NAME}/*" -type f
> \-exec bash -c 'dir={} && cd ${dir%/*} && mv {} ../..' \;
> nodetool -u $NODETOOL_USR -pw $NODETOOL_PASSWD -h $(hostname) refresh
> $keyspace $table --ssl
> {code}
>
> When I restart the node after perfoming the steps above it changes the tokens
> from 256 to 512.
> ERROR:
>
> {code:java}
> ERROR [main] 2021-10-07 15:16:24,060 CassandraDaemon.java:803 - Fatal
> configuration error org.apache.cassandra.exceptions.ConfigurationException:
> Cannot change the number of tokens from 512 to 256 at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1102)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:760)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:694)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.11.jar:3.11.11] INFO [StorageServiceShutdownHook]
> 2021-10-07 15:16:24,064 HintsService.java:209 - Paused hints dispatch INFO
> [StorageServiceShutdownHook] 2021-10-07 15:16:24,064 Gossiper.java:1683 -
> Announcing shutdown
> {code}
> It happens even in a empty node that I'm not trying to restore data, it
> happens after deleting the data from /var/lib/cassandra and restarting the
> node.
>
> {code:java}
> IINFO [main] 2021-10-12 15:21:23,034 StorageService.java:778 - Loading
> persisted ring state
> INFO [main] 2021-10-12 15:21:23,085 StorageService.java:907 - Starting up
> server gossip
> INFO [main] 2021-10-12 15:21:23,108 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> INFO [main] 2021-10-12 15:21:23,109 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> ERROR [main] 2021-10-12 15:21:23,166 CassandraDaemon.java:803 - Fatal
> configuration error
> org.apache.cassandra.exceptions.ConfigurationException: Cannot change the
> number of tokens from 512 to 256
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1078)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,168
> HintsService.java:209 - Paused hints dispatch
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,169 Gossiper.java:1662
> - Announcing shutdown
> {code}
> Any ideas on it?
> Thanks,
--
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:
[jira] [Commented] (CASSANDRA-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427793#comment-17427793
]
Tatu Saloranta commented on CASSANDRA-15453:
Playing with this a bit more, it looks like upgrade to 20.0 is relatively easy
as well. In addition to `CharMatcher.DIGIT`, we have 2 other mechanical safe
changes:
# Futures.transform() -> Futures.transformAsync() (added in 19.0, old removed
from a later version)
# HostAndPort.getHostText() -> Futures.getHost() (added in 20.0, old removed
from 22.0)--
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-17035) Issue num_tokens on cassandra after perform snapshot restore - Cassandra 3.11.10 and 3.11.11
[
https://issues.apache.org/jira/browse/CASSANDRA-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427791#comment-17427791
]
Brandon Williams commented on CASSANDRA-17035:
--
Check the location in the cassandra.yaml and further up in the log it should
also indicate what directory it's loading from.
> Issue num_tokens on cassandra after perform snapshot restore - Cassandra
> 3.11.10 and 3.11.11
>
>
> Key: CASSANDRA-17035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17035
> Project: Cassandra
> Issue Type: Bug
>Reporter: Igor Marinho
>Priority: Urgent
>
> After upgrading from 3.0.13 to 3.11.10 I'm having issue when I retsore the
> data from the node. After the restore is done it changes the number of tokens
> from 256 to 512.In cassandra.yaml it still num_token: 256, so I have no idea
> what's going on here.
> {code:java}
> cassandra.yaml value -> num_tokens: 256{code}
> These are the steps I'm performing
>
> {code:java}
> rm -rf /var/lib/cassandra/data/*
> rm -rf /var/lib/cassandra/commitlog/*
> rm -rf /var/lib/cassandra/saved_caches/*
> rm -rf /var/lib/cassandra/hints/*
> tar -xvf $BACKUP_LOC/$BACKUP_NAME.tar -C /
> find ${DATA_DIR} -mindepth 2 -path "*/snapshots/${BACKUP_NAME}/*" -type f
> \-exec bash -c 'dir={} && cd ${dir%/*} && mv {} ../..' \;
> nodetool -u $NODETOOL_USR -pw $NODETOOL_PASSWD -h $(hostname) refresh
> $keyspace $table --ssl
> {code}
>
> When I restart the node after perfoming the steps above it changes the tokens
> from 256 to 512.
> ERROR:
>
> {code:java}
> ERROR [main] 2021-10-07 15:16:24,060 CassandraDaemon.java:803 - Fatal
> configuration error org.apache.cassandra.exceptions.ConfigurationException:
> Cannot change the number of tokens from 512 to 256 at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1102)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:760)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:694)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.11.jar:3.11.11] INFO [StorageServiceShutdownHook]
> 2021-10-07 15:16:24,064 HintsService.java:209 - Paused hints dispatch INFO
> [StorageServiceShutdownHook] 2021-10-07 15:16:24,064 Gossiper.java:1683 -
> Announcing shutdown
> {code}
> It happens even in a empty node that I'm not trying to restore data, it
> happens after deleting the data from /var/lib/cassandra and restarting the
> node.
>
> {code:java}
> IINFO [main] 2021-10-12 15:21:23,034 StorageService.java:778 - Loading
> persisted ring state
> INFO [main] 2021-10-12 15:21:23,085 StorageService.java:907 - Starting up
> server gossip
> INFO [main] 2021-10-12 15:21:23,108 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> INFO [main] 2021-10-12 15:21:23,109 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> ERROR [main] 2021-10-12 15:21:23,166 CassandraDaemon.java:803 - Fatal
> configuration error
> org.apache.cassandra.exceptions.ConfigurationException: Cannot change the
> number of tokens from 512 to 256
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1078)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,168
> HintsService.java:209 - Paused hints dispatch
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,169 Gossiper.java:1662
> - Announcing shutdown
> {code}
> Any ideas on it?
> Thanks,
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For
[jira] [Updated] (CASSANDRA-17036) Add logging and metrics to Index Summary Redistribution
[ https://issues.apache.org/jira/browse/CASSANDRA-17036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17036: -- Change Category: Operability Complexity: Low Hanging Fruit Status: Open (was: Triage Needed) > Add logging and metrics to Index Summary Redistribution > --- > > Key: CASSANDRA-17036 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17036 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Streaming >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > We don't have much visibility into the performance / impact / time taken on > index summary redistribution, either in memory impact or time to execute. We > should add some metrics and slightly tweak the logging around that to make it > more useful. -- 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-17036) Add logging and metrics to Index Summary Redistribution
[ https://issues.apache.org/jira/browse/CASSANDRA-17036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17036: -- Test and Documentation Plan: No extra testing or documentation needed; trivial change to expose a new metric and tweak log levels. Status: Patch Available (was: Open) > Add logging and metrics to Index Summary Redistribution > --- > > Key: CASSANDRA-17036 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17036 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Streaming >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > We don't have much visibility into the performance / impact / time taken on > index summary redistribution, either in memory impact or time to execute. We > should add some metrics and slightly tweak the logging around that to make it > more useful. -- 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-17036) Add logging and metrics to Index Summary Redistribution
[ https://issues.apache.org/jira/browse/CASSANDRA-17036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427788#comment-17427788 ] Josh McKenzie commented on CASSANDRA-17036: --- [Branch|https://github.com/apache/cassandra/compare/trunk...josh-mckenzie:cassandra-17036?expand=1] > Add logging and metrics to Index Summary Redistribution > --- > > Key: CASSANDRA-17036 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17036 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Streaming >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > We don't have much visibility into the performance / impact / time taken on > index summary redistribution, either in memory impact or time to execute. We > should add some metrics and slightly tweak the logging around that to make it > more useful. -- 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-17036) Add logging and metrics to Index Summary Redistribution
Josh McKenzie created CASSANDRA-17036: - Summary: Add logging and metrics to Index Summary Redistribution Key: CASSANDRA-17036 URL: https://issues.apache.org/jira/browse/CASSANDRA-17036 Project: Cassandra Issue Type: Improvement Components: Consistency/Streaming Reporter: Josh McKenzie Assignee: Josh McKenzie We don't have much visibility into the performance / impact / time taken on index summary redistribution, either in memory impact or time to execute. We should add some metrics and slightly tweak the logging around that to make it more useful. -- 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-17035) Issue num_tokens on cassandra after perform snapshot restore - Cassandra 3.11.10 and 3.11.11
[
https://issues.apache.org/jira/browse/CASSANDRA-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427787#comment-17427787
]
Igor Marinho commented on CASSANDRA-17035:
--
Could it be somewhere else?
cd /var/lib/cassandra/
[root@cass-01 cassandra]# ls -ltr
total 0
Before 3.11.x I never had this problem before. I'm try to restore one node out
3 in this case.
> Issue num_tokens on cassandra after perform snapshot restore - Cassandra
> 3.11.10 and 3.11.11
>
>
> Key: CASSANDRA-17035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17035
> Project: Cassandra
> Issue Type: Bug
>Reporter: Igor Marinho
>Priority: Urgent
>
> After upgrading from 3.0.13 to 3.11.10 I'm having issue when I retsore the
> data from the node. After the restore is done it changes the number of tokens
> from 256 to 512.In cassandra.yaml it still num_token: 256, so I have no idea
> what's going on here.
> {code:java}
> cassandra.yaml value -> num_tokens: 256{code}
> These are the steps I'm performing
>
> {code:java}
> rm -rf /var/lib/cassandra/data/*
> rm -rf /var/lib/cassandra/commitlog/*
> rm -rf /var/lib/cassandra/saved_caches/*
> rm -rf /var/lib/cassandra/hints/*
> tar -xvf $BACKUP_LOC/$BACKUP_NAME.tar -C /
> find ${DATA_DIR} -mindepth 2 -path "*/snapshots/${BACKUP_NAME}/*" -type f
> \-exec bash -c 'dir={} && cd ${dir%/*} && mv {} ../..' \;
> nodetool -u $NODETOOL_USR -pw $NODETOOL_PASSWD -h $(hostname) refresh
> $keyspace $table --ssl
> {code}
>
> When I restart the node after perfoming the steps above it changes the tokens
> from 256 to 512.
> ERROR:
>
> {code:java}
> ERROR [main] 2021-10-07 15:16:24,060 CassandraDaemon.java:803 - Fatal
> configuration error org.apache.cassandra.exceptions.ConfigurationException:
> Cannot change the number of tokens from 512 to 256 at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1102)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:760)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:694)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.11.jar:3.11.11] INFO [StorageServiceShutdownHook]
> 2021-10-07 15:16:24,064 HintsService.java:209 - Paused hints dispatch INFO
> [StorageServiceShutdownHook] 2021-10-07 15:16:24,064 Gossiper.java:1683 -
> Announcing shutdown
> {code}
> It happens even in a empty node that I'm not trying to restore data, it
> happens after deleting the data from /var/lib/cassandra and restarting the
> node.
>
> {code:java}
> IINFO [main] 2021-10-12 15:21:23,034 StorageService.java:778 - Loading
> persisted ring state
> INFO [main] 2021-10-12 15:21:23,085 StorageService.java:907 - Starting up
> server gossip
> INFO [main] 2021-10-12 15:21:23,108 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> INFO [main] 2021-10-12 15:21:23,109 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> ERROR [main] 2021-10-12 15:21:23,166 CassandraDaemon.java:803 - Fatal
> configuration error
> org.apache.cassandra.exceptions.ConfigurationException: Cannot change the
> number of tokens from 512 to 256
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1078)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,168
> HintsService.java:209 - Paused hints dispatch
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,169 Gossiper.java:1662
> - Announcing shutdown
> {code}
> Any ideas on it?
> Thanks,
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe,
[jira] [Commented] (CASSANDRA-17035) Issue num_tokens on cassandra after perform snapshot restore - Cassandra 3.11.10 and 3.11.11
[
https://issues.apache.org/jira/browse/CASSANDRA-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427784#comment-17427784
]
Brandon Williams commented on CASSANDRA-17035:
--
bq. it happens after deleting the data from /var/lib/cassandra and restarting
the node.
I don't think you're removing it entirely:
bq. INFO [main] 2021-10-12 15:21:23,034 StorageService.java:778 - Loading
persisted ring state
> Issue num_tokens on cassandra after perform snapshot restore - Cassandra
> 3.11.10 and 3.11.11
>
>
> Key: CASSANDRA-17035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17035
> Project: Cassandra
> Issue Type: Bug
>Reporter: Igor Marinho
>Priority: Urgent
>
> After upgrading from 3.0.13 to 3.11.10 I'm having issue when I retsore the
> data from the node. After the restore is done it changes the number of tokens
> from 256 to 512.In cassandra.yaml it still num_token: 256, so I have no idea
> what's going on here.
> {code:java}
> cassandra.yaml value -> num_tokens: 256{code}
> These are the steps I'm performing
>
> {code:java}
> rm -rf /var/lib/cassandra/data/*
> rm -rf /var/lib/cassandra/commitlog/*
> rm -rf /var/lib/cassandra/saved_caches/*
> rm -rf /var/lib/cassandra/hints/*
> tar -xvf $BACKUP_LOC/$BACKUP_NAME.tar -C /
> find ${DATA_DIR} -mindepth 2 -path "*/snapshots/${BACKUP_NAME}/*" -type f
> \-exec bash -c 'dir={} && cd ${dir%/*} && mv {} ../..' \;
> nodetool -u $NODETOOL_USR -pw $NODETOOL_PASSWD -h $(hostname) refresh
> $keyspace $table --ssl
> {code}
>
> When I restart the node after perfoming the steps above it changes the tokens
> from 256 to 512.
> ERROR:
>
> {code:java}
> ERROR [main] 2021-10-07 15:16:24,060 CassandraDaemon.java:803 - Fatal
> configuration error org.apache.cassandra.exceptions.ConfigurationException:
> Cannot change the number of tokens from 512 to 256 at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1102)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:760)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:694)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.11.jar:3.11.11] INFO [StorageServiceShutdownHook]
> 2021-10-07 15:16:24,064 HintsService.java:209 - Paused hints dispatch INFO
> [StorageServiceShutdownHook] 2021-10-07 15:16:24,064 Gossiper.java:1683 -
> Announcing shutdown
> {code}
> It happens even in a empty node that I'm not trying to restore data, it
> happens after deleting the data from /var/lib/cassandra and restarting the
> node.
>
> {code:java}
> IINFO [main] 2021-10-12 15:21:23,034 StorageService.java:778 - Loading
> persisted ring state
> INFO [main] 2021-10-12 15:21:23,085 StorageService.java:907 - Starting up
> server gossip
> INFO [main] 2021-10-12 15:21:23,108 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> INFO [main] 2021-10-12 15:21:23,109 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> ERROR [main] 2021-10-12 15:21:23,166 CassandraDaemon.java:803 - Fatal
> configuration error
> org.apache.cassandra.exceptions.ConfigurationException: Cannot change the
> number of tokens from 512 to 256
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1078)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,168
> HintsService.java:209 - Paused hints dispatch
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,169 Gossiper.java:1662
> - Announcing shutdown
> {code}
> Any ideas on it?
> Thanks,
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CASSANDRA-17035) Issue num_tokens on cassandra after perform snapshot restore - Cassandra 3.11.10 and 3.11.11
[
https://issues.apache.org/jira/browse/CASSANDRA-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Marinho updated CASSANDRA-17035:
-
Severity: Critical
> Issue num_tokens on cassandra after perform snapshot restore - Cassandra
> 3.11.10 and 3.11.11
>
>
> Key: CASSANDRA-17035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17035
> Project: Cassandra
> Issue Type: Bug
>Reporter: Igor Marinho
>Priority: Urgent
>
> After upgrading from 3.0.13 to 3.11.10 I'm having issue when I retsore the
> data from the node. After the restore is done it changes the number of tokens
> from 256 to 512.In cassandra.yaml it still num_token: 256, so I have no idea
> what's going on here.
> {code:java}
> cassandra.yaml value -> num_tokens: 256{code}
> These are the steps I'm performing
>
> {code:java}
> rm -rf /var/lib/cassandra/data/*
> rm -rf /var/lib/cassandra/commitlog/*
> rm -rf /var/lib/cassandra/saved_caches/*
> rm -rf /var/lib/cassandra/hints/*
> tar -xvf $BACKUP_LOC/$BACKUP_NAME.tar -C /
> find ${DATA_DIR} -mindepth 2 -path "*/snapshots/${BACKUP_NAME}/*" -type f
> \-exec bash -c 'dir={} && cd ${dir%/*} && mv {} ../..' \;
> nodetool -u $NODETOOL_USR -pw $NODETOOL_PASSWD -h $(hostname) refresh
> $keyspace $table --ssl
> {code}
>
> When I restart the node after perfoming the steps above it changes the tokens
> from 256 to 512.
> ERROR:
>
> {code:java}
> ERROR [main] 2021-10-07 15:16:24,060 CassandraDaemon.java:803 - Fatal
> configuration error org.apache.cassandra.exceptions.ConfigurationException:
> Cannot change the number of tokens from 512 to 256 at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1102)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:760)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:694)
> ~[apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.11.jar:3.11.11] at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.11.jar:3.11.11] INFO [StorageServiceShutdownHook]
> 2021-10-07 15:16:24,064 HintsService.java:209 - Paused hints dispatch INFO
> [StorageServiceShutdownHook] 2021-10-07 15:16:24,064 Gossiper.java:1683 -
> Announcing shutdown
> {code}
> It happens even in a empty node that I'm not trying to restore data, it
> happens after deleting the data from /var/lib/cassandra and restarting the
> node.
>
> {code:java}
> IINFO [main] 2021-10-12 15:21:23,034 StorageService.java:778 - Loading
> persisted ring state
> INFO [main] 2021-10-12 15:21:23,085 StorageService.java:907 - Starting up
> server gossip
> INFO [main] 2021-10-12 15:21:23,108 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> INFO [main] 2021-10-12 15:21:23,109 TokenMetadata.java:497 - Updating
> topology for /10.20.30.51
> ERROR [main] 2021-10-12 15:21:23,166 CassandraDaemon.java:803 - Fatal
> configuration error
> org.apache.cassandra.exceptions.ConfigurationException: Cannot change the
> number of tokens from 512 to 256
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1078)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
> [apache-cassandra-3.11.10.jar:3.11.10]
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,168
> HintsService.java:209 - Paused hints dispatch
> INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,169 Gossiper.java:1662
> - Announcing shutdown
> {code}
> Any ideas on it?
> Thanks,
--
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-17035) Issue num_tokens on cassandra after perform snapshot restore - Cassandra 3.11.10 and 3.11.11
Igor Marinho created CASSANDRA-17035:
Summary: Issue num_tokens on cassandra after perform snapshot
restore - Cassandra 3.11.10 and 3.11.11
Key: CASSANDRA-17035
URL: https://issues.apache.org/jira/browse/CASSANDRA-17035
Project: Cassandra
Issue Type: Bug
Reporter: Igor Marinho
After upgrading from 3.0.13 to 3.11.10 I'm having issue when I retsore the data
from the node. After the restore is done it changes the number of tokens from
256 to 512.In cassandra.yaml it still num_token: 256, so I have no idea what's
going on here.
{code:java}
cassandra.yaml value -> num_tokens: 256{code}
These are the steps I'm performing
{code:java}
rm -rf /var/lib/cassandra/data/*
rm -rf /var/lib/cassandra/commitlog/*
rm -rf /var/lib/cassandra/saved_caches/*
rm -rf /var/lib/cassandra/hints/*
tar -xvf $BACKUP_LOC/$BACKUP_NAME.tar -C /
find ${DATA_DIR} -mindepth 2 -path "*/snapshots/${BACKUP_NAME}/*" -type f
\-exec bash -c 'dir={} && cd ${dir%/*} && mv {} ../..' \;
nodetool -u $NODETOOL_USR -pw $NODETOOL_PASSWD -h $(hostname) refresh $keyspace
$table --ssl
{code}
When I restart the node after perfoming the steps above it changes the tokens
from 256 to 512.
ERROR:
{code:java}
ERROR [main] 2021-10-07 15:16:24,060 CassandraDaemon.java:803 - Fatal
configuration error org.apache.cassandra.exceptions.ConfigurationException:
Cannot change the number of tokens from 512 to 256 at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1102)
~[apache-cassandra-3.11.11.jar:3.11.11] at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:760)
~[apache-cassandra-3.11.11.jar:3.11.11] at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:694)
~[apache-cassandra-3.11.11.jar:3.11.11] at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
[apache-cassandra-3.11.11.jar:3.11.11] at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
[apache-cassandra-3.11.11.jar:3.11.11] at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
[apache-cassandra-3.11.11.jar:3.11.11] INFO [StorageServiceShutdownHook]
2021-10-07 15:16:24,064 HintsService.java:209 - Paused hints dispatch INFO
[StorageServiceShutdownHook] 2021-10-07 15:16:24,064 Gossiper.java:1683 -
Announcing shutdown
{code}
It happens even in a empty node that I'm not trying to restore data, it happens
after deleting the data from /var/lib/cassandra and restarting the node.
{code:java}
IINFO [main] 2021-10-12 15:21:23,034 StorageService.java:778 - Loading
persisted ring state
INFO [main] 2021-10-12 15:21:23,085 StorageService.java:907 - Starting up
server gossip
INFO [main] 2021-10-12 15:21:23,108 TokenMetadata.java:497 - Updating topology
for /10.20.30.51
INFO [main] 2021-10-12 15:21:23,109 TokenMetadata.java:497 - Updating topology
for /10.20.30.51
ERROR [main] 2021-10-12 15:21:23,166 CassandraDaemon.java:803 - Fatal
configuration error
org.apache.cassandra.exceptions.ConfigurationException: Cannot change the
number of tokens from 512 to 256
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1078)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:753)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:395)
[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:633)
[apache-cassandra-3.11.10.jar:3.11.10]
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:786)
[apache-cassandra-3.11.10.jar:3.11.10]
INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,168 HintsService.java:209
- Paused hints dispatch
INFO [StorageServiceShutdownHook] 2021-10-12 15:21:23,169 Gossiper.java:1662 -
Announcing shutdown
{code}
Any ideas on it?
Thanks,
--
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-16203) Rack Aware Topology Strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-16203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sumanth Pasupuleti reassigned CASSANDRA-16203: -- Assignee: Sumanth Pasupuleti (was: Stefan Miklosovic) > Rack Aware Topology Strategy > > > Key: CASSANDRA-16203 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16203 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership >Reporter: Cameron Zemek >Assignee: Sumanth Pasupuleti >Priority: Normal > Fix For: 4.x > > Attachments: rackaware.patch > > > If replication factor > racks then NetworkTopologyStrategy assigns the extras > in ring order. This means losing a rack can result in the loss of quorum. I > have implemented a similar topology strategy that evenly distributes replicas > across racks. -- 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-15453) Upgrade Guava to the same version as master on 3.11 branch
[
https://issues.apache.org/jira/browse/CASSANDRA-15453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427778#comment-17427778
]
Tatu Saloranta commented on CASSANDRA-15453:
It looks like the replacement for `CharMatcher.DIGIT` (removed from 26),
`CharMatcher.digit()` was added in Guava 19. So the very minimum possibly
useful thing would be a minimal upgrade for Cassandra 3.11 to:
# Upgrade Guava dep from 18.0 to 19.0
# Replace `CharMatcher.DIGIT` with `CharMatcher.digit()`
This alone will not solve other Guava upgrade issues (see CASSANDRA-15248 for
details) but might help untangle the problem.
If this sounds useful, I can provide a PR.
> Upgrade Guava to the same version as master on 3.11 branch
> --
>
> Key: CASSANDRA-15453
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15453
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tomo Suzuki
>Priority: Normal
>
> Can we backport the Guava version upgrade (CASSANDRA-15248) into 3.11 branch?
> h3. Background
> I'm trying to upgrade Apache Beam's dependencies to latest versions. Apache
> Beam depends on Cassandra 3 ({{org.apache.cassandra:cassandra-all:3.11.3}}).
> Cassandra 3 touches on Guava's old fields (and potentially methods), such as
> CharMatcher.DIGIT, are blocking Apache Beam's Guava dependency upgrade
> (BEAM-8911); the field is removed in Guava 26.0. Because of this, Apache
> Beam's Guava dependency must be lower than version 26.0.
> I see the latest cassandra-all release on 3.X is 3.11.5, which still relies
> on Guava 18. This version does not have {{CharMatcher.digit()}}, the
> replacement of old {{CharMatcher.DIGIT}}. To get rid of {{CharMatcher.DIGIT}}
> and thus let Apache Beam to use Guava 26 and higher, we need to upgrade
> Cassandra3's Guava version.
> h4. Test failure Beam's HadoopFormatIOCassandraTest
> Apache Beam's {{:sdks:java:io:hadoop-format}} has
> {{HadoopFormatIOCassandraTest}} that failed when I tried to upgrade Guava
> version to 26:
> https://github.com/GoogleCloudPlatform/cloud-opensource-java/issues/1028#issuecomment-557680928
> .
> h3. How about waiting for Cassandra version 4(-alpha)?
> I thought about Cassandra "4", which has a recent version of Guava. However,
> I believe quite a few Cassandra/Beam users will keep using Casandra 3 for
> several years. I want such users to be able to use the higher version of
> Guava.
> h3. Shading?
> Shading makes build process complex. When things go wrong due to this, it's
> hard to debug ([JLBP18|https://jlbp.dev/JLBP-18.html]).
> h3. CASSANDRA-15248 "Upgrade Guava to latest on master branch",
> I found CASSANDRA-15248 "Upgrade Guava to latest on master branch", but this
> did not go into 3.11 branch. Can we backport this Guava version upgrade
> (CASSANDRA-15248) into 3.11 branch?
--
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-15248) Upgrade Guava to latest on master branch
[ https://issues.apache.org/jira/browse/CASSANDRA-15248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413438#comment-17413438 ] Tatu Saloranta edited comment on CASSANDRA-15248 at 10/12/21, 3:53 PM: --- Looking at incompatibilities, alas, it gets tricky. The immediate problem is `Futures.transform()` (used in 2 non-test and 1 test class): while it translates to un-deprecated `Futures.transformAsync()`, latter is only introduced in 19.0 but former immediately deleted from 20.0 (thanks Guava). Further, something somewhere in tests refers to `FutureCallback` which is also removed from 20.0. That would also need to be patched. So maybe my idea of small changes to allow `cassandra-all` to work with newer versions (even if not upgrading dependency to require) is unworkable. Added notes just in case it helps anyone figure out a way. It would definitely be nice if Guava version dependency was not as strict as it now is. EDIT: `FutureCallback` likely comes via "cassandra-driver-core", version 3.0.1: upgrading this would likely resolve it. There is a small compilation problem from a test class if upgrading that dependency, likely simple to resolve (i.e. this one would not be a blocker). Looks like "cassandra-driver-core" 3.2.0 does resolve these, see – [https://datastax-oss.atlassian.net/browse/JAVA-1328] – but using that version otherwise works seems unsure. Based on version it'd make sense it did but... EDIT2: To replace `CharMatcher.DIGIT` (removed from guava 26?) one could use `CharMatcher.digit()` added in 19.0. So even that relatively small improvement would require small bump to Guava version. was (Author: cowtowncoder): Looking at incompatibilities, alas, it gets tricky. The immediate problem is `Futures.transform()` (used in 2 non-test and 1 test class): while it translates to un-deprecated `Futures.transformAsync()`, latter is only introduced in 19.0 but former immediately deleted from 20.0 (thanks Guava). Further, something somewhere in tests refers to `FutureFallback` which is also removed from 20.0. That would also need to be patched. So maybe my idea of small changes to allow `cassandra-all` to work with newer versions (even if not upgrading dependency to require) is unworkable. Added notes just in case it helps anyone figure out a way. It would definitely be nice if Guava version dependency was not as strict as it now is. EDIT: `FutureFallback` likely comes via "cassandra-driver-core", version 3.0.1: upgrading this would likely resolve it. There is a small compilation problem from a test class if upgrading that dependency, likely simple to resolve (i.e. this one would not be a blocker). Looks like "cassandra-driver-core" 3.2.0 does resolve these, see – [https://datastax-oss.atlassian.net/browse/JAVA-1328] – but using that version otherwise works seems unsure. Based on version it'd make sense it did but... > Upgrade Guava to latest on master branch > > > Key: CASSANDRA-15248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15248 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies, Packaging >Reporter: Abhijit Sarkar >Priority: Normal > > Upgrade Guava to latest on master branch. See > https://issues.apache.org/jira/browse/CASSANDRA-15245. -- 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-16203) Rack Aware Topology Strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-16203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427759#comment-17427759 ] Stefan Miklosovic commented on CASSANDRA-16203: --- I addressed all points but tests are still missing. https://github.com/instaclustr/cassandra/tree/CASSANDRA-16203 > Rack Aware Topology Strategy > > > Key: CASSANDRA-16203 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16203 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership >Reporter: Cameron Zemek >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Attachments: rackaware.patch > > > If replication factor > racks then NetworkTopologyStrategy assigns the extras > in ring order. This means losing a rack can result in the loss of quorum. I > have implemented a similar topology strategy that evenly distributes replicas > across racks. -- 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-16334) Replica failure causes timeout on multi-DC write
[
https://issues.apache.org/jira/browse/CASSANDRA-16334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16334:
--
Reviewers: Andres de la Peña
> Replica failure causes timeout on multi-DC write
>
>
> Key: CASSANDRA-16334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16334
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Messaging/Internode
>Reporter: Paulo Motta
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> Inserting a mutation larger than {{max_mutation_size_in_kb}} correctly throws
> a write error on a single DC keyspace with RF=3:
> {noformat}
> cassandra.WriteFailure: Error from server: code=1500 [Replica(s) failed to
> execute write] message="Operation failed - received 0 responses and 3
> failures: UNKNOWN from /127.0.0.3:7000, UNKNOWN from /127.0.0.2:7000, UNKNOWN
> from /127.0.0.1:7000" info={'consistency': 'LOCAL_ONE', 'required_responses':
> 1, 'received_responses': 0, 'failures': 3}
> {noformat}
> The same insert wrongly causes a timeout on a keyspace with 2 dcs (RF=3 each):
> {noformat}
> cassandra.WriteTimeout: Error from server: code=1100 [Coordinator node timed
> out waiting for replica nodes' responses] message="Operation timed out -
> received only 0 responses." info={'consistency': 'LOCAL_ONE',
> 'required_responses': 1, 'received_responses': 0}
> {noformat}
> Reproduction steps:
> {noformat}
> # Setup cluster
> ccm create -n 3:3 test
> for i in {1..6}; do echo 'max_mutation_size_in_kb: 1000' >>
> ~/.ccm/test/node$i/conf/cassandra.yaml; done
> ccm start
> # Create schema
> ccm node1 cqlsh
> CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
> 'dc1': 3, 'dc2': 3};
> CREATE TABLE test.test (key int PRIMARY KEY, val blob);
> exit;
> # Insert data
> python
> from cassandra.cluster import Cluster
> cluster = Cluster()
> session = cluster.connect('test')
> blob = f = open("2mbBlob", "rb").read().hex()
> session.execute("INSERT INTO test (key, val) VALUES (1, textAsBlob('" + blob
> + "'))")
> {noformat}
> Reproduced in 3.0, 3.11, 4.0, trunk.
--
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-17027) Allow to grant permission for all tables in a keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427738#comment-17427738
]
Andres de la Peña commented on CASSANDRA-17027:
---
Overall looks good to me, and it's nice to have authentication in
{{CQLTester}}. I have left a few minor suggestions on the PR.
> Allow to grant permission for all tables in a keyspace
> ---
>
> Key: CASSANDRA-17027
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17027
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax, Feature/Authorization
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In some scenario it is useful to prevent users to alter or drop a keyspace
> while allowing them to create new tables and user types.
--
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-17034) CEP-11: Memtable API implementation
[ https://issues.apache.org/jira/browse/CASSANDRA-17034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Branimir Lambov updated CASSANDRA-17034: Change Category: Performance Complexity: Normal Component/s: Local/Memtable Status: Open (was: Triage Needed) > CEP-11: Memtable API implementation > --- > > Key: CASSANDRA-17034 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17034 > Project: Cassandra > Issue Type: Improvement > Components: Local/Memtable >Reporter: Branimir Lambov >Assignee: Branimir Lambov >Priority: Normal > > Pluggable memtable API as described in > [CEP-11|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-11%3A+Pluggable+memtable+implementations]. > > Initial version is already available in [this > branch|https://github.com/datastax/cassandra/tree/memtable-api], and needs to > be updated to the changes in trunk. Two additional features suggested by CEP > reviewers are also to be implemented: > * Sharding support: extending the memtable owner interface to supply > suitable shard boundaries that split the owned token space and are in > agreement with disk boundaries. > * Shared read API with sstables: defining a common interface for reading > partitions from memtables and sstables; this is to include filters to avoid > unnecessary copying. -- 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-17034) CEP-11: Memtable API implementation
Branimir Lambov created CASSANDRA-17034: --- Summary: CEP-11: Memtable API implementation Key: CASSANDRA-17034 URL: https://issues.apache.org/jira/browse/CASSANDRA-17034 Project: Cassandra Issue Type: Improvement Reporter: Branimir Lambov Assignee: Branimir Lambov Pluggable memtable API as described in [CEP-11|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-11%3A+Pluggable+memtable+implementations]. Initial version is already available in [this branch|https://github.com/datastax/cassandra/tree/memtable-api], and needs to be updated to the changes in trunk. Two additional features suggested by CEP reviewers are also to be implemented: * Sharding support: extending the memtable owner interface to supply suitable shard boundaries that split the owned token space and are in agreement with disk boundaries. * Shared read API with sstables: defining a common interface for reading partitions from memtables and sstables; this is to include filters to avoid unnecessary copying. -- 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-16203) Rack Aware Topology Strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-16203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16203: -- Status: In Progress (was: Patch Available) > Rack Aware Topology Strategy > > > Key: CASSANDRA-16203 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16203 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership >Reporter: Cameron Zemek >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Attachments: rackaware.patch > > > If replication factor > racks then NetworkTopologyStrategy assigns the extras > in ring order. This means losing a rack can result in the loss of quorum. I > have implemented a similar topology strategy that evenly distributes replicas > across racks. -- 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-13780) ADD Node streaming throughput performance
[ https://issues.apache.org/jira/browse/CASSANDRA-13780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427680#comment-17427680 ] Stefan Miklosovic commented on CASSANDRA-13780: --- Hi [~jjirsa], is this still relevant after all these years? I think this targets 3.0 which we hardly support anymore anyway ... > ADD Node streaming throughput performance > - > > Key: CASSANDRA-13780 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13780 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core > Environment: Linux 2.6.32-696.3.2.el6.x86_64 #1 SMP Mon Jun 19 > 11:55:55 PDT 2017 x86_64 x86_64 x86_64 GNU/Linux > Architecture: x86_64 > CPU op-mode(s):32-bit, 64-bit > Byte Order:Little Endian > CPU(s):40 > On-line CPU(s) list: 0-39 > Thread(s) per core:2 > Core(s) per socket:10 > Socket(s): 2 > NUMA node(s): 2 > Vendor ID: GenuineIntel > CPU family:6 > Model: 79 > Model name:Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz > Stepping: 1 > CPU MHz: 2199.869 > BogoMIPS: 4399.36 > Virtualization:VT-x > L1d cache: 32K > L1i cache: 32K > L2 cache: 256K > L3 cache: 25600K > NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38 > NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39 > total used free sharedbuffers cached > Mem: 252G 217G34G 708K 308M 149G > -/+ buffers/cache:67G 185G > Swap: 16G 0B16G >Reporter: Kevin Rivait >Priority: Normal > Fix For: 3.0.x > > > Problem: Adding a new node to a large cluster runs at least 1000x slower than > what the network and node hardware capacity can support, taking several days > per new node. Adjusting stream throughput and other YAML parameters seems to > have no effect on performance. Essentially, it appears that Cassandra has an > architecture scalability growth problem when adding new nodes to a moderate > to high data ingestion cluster because Cassandra cannot add new node capacity > fast enough to keep up with increasing data ingestion volumes and growth. > Initial Configuration: > Running 3.0.9 and have implemented TWCS on one of our largest table. > Largest table partitioned on (ID, MM) using 1 day buckets with a TTL of > 60 days. > Next release will change partitioning to (ID, MMDD) so that partitions > are aligned with daily TWCS buckets. > Each node is currently creating roughly a 30GB SSTable per day. > TWCS working as expected, daily SSTables are dropping off daily after 70 > days ( 60 + 10 day grace) > Current deployment is a 28 node 2 datacenter cluster, 14 nodes in each DC , > replication factor 3 > Data directories are backed with 4 - 2TB SSDs on each node and a 1 800GB SSD > for commit logs. > Requirement is to double cluster size, capacity, and ingestion volume within > a few weeks. > Observed Behavior: > 1. streaming throughput during add node – we observed maximum 6 Mb/s > streaming from each of the 14 nodes on a 20Gb/s switched network, taking at > least 106 hours for each node to join cluster and each node is only about 2.2 > TB is size. > 2. compaction on the newly added node - compaction has fallen behind, with > anywhere from 4,000 to 10,000 SSTables at any given time. It took 3 weeks > for compaction to finish on each newly added node. Increasing number of > compaction threads to match number of CPU (40) and increasing compaction > throughput to 32MB/s seemed to be the sweet spot. > 3. TWCS buckets on new node, data streamed to this node over 4 1/2 days. > Compaction correctly placed the data in daily files, but the problem is the > file dates reflect when compaction created the file and not the date of the > last record written in the TWCS bucket, which will cause the files to remain > around much longer than necessary. > Two Questions: > 1. What can be done to substantially improve the performance of adding a new > node? > 2. Can compaction on TWCS partitions for newly added nodes change the file > create date to match the highest date record in the file -or- add another > piece of meta-data to the TWCS files that reflect the file drop date so that > TWCS partitions can be dropped consistently? -- 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-11181) Add broadcast_rpc_address to system.local
[ https://issues.apache.org/jira/browse/CASSANDRA-11181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-11181: -- Fix Version/s: (was: 4.x) 4.1 Source Control Link: https://github.com/apache/cassandra/commit/243d220854895b968e2f169d3650c27d83567bb3 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Add broadcast_rpc_address to system.local > - > > Key: CASSANDRA-11181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11181 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Distributed Metadata >Reporter: Nick Bailey >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Right now it's impossible to get the broadcast_rpc_address of the node you > are connected to via the drivers. -- 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
[cassandra] branch trunk updated (0d4cc2e -> 243d220)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 0d4cc2e Add support for type casting in WHERE clause components and in the values of INSERT/UPDATE statements add 243d220 store FBUtilities.getJustBroadcastNativeAddress() in system.local for rpc_address column No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../org/apache/cassandra/db/SystemKeyspace.java| 2 +- .../apache/cassandra/db/SystemKeyspaceTest.java| 30 ++ 3 files changed, 32 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11181) Add broadcast_rpc_address to system.local
[ https://issues.apache.org/jira/browse/CASSANDRA-11181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427669#comment-17427669 ] Stefan Miklosovic commented on CASSANDRA-11181: --- https://app.circleci.com/pipelines/github/instaclustr/cassandra/564/workflows/d7ba5a32-1916-4514-9962-ae6d4143337c > Add broadcast_rpc_address to system.local > - > > Key: CASSANDRA-11181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11181 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Distributed Metadata >Reporter: Nick Bailey >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Right now it's impossible to get the broadcast_rpc_address of the node you > are connected to via the drivers. -- 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-11181) Add broadcast_rpc_address to system.local
[ https://issues.apache.org/jira/browse/CASSANDRA-11181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-11181: -- Status: Ready to Commit (was: Review In Progress) > Add broadcast_rpc_address to system.local > - > > Key: CASSANDRA-11181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11181 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Distributed Metadata >Reporter: Nick Bailey >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Right now it's impossible to get the broadcast_rpc_address of the node you > are connected to via the drivers. -- 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-16673) Avoid race in AbstractReplicationStrategy endpoint caching
[
https://issues.apache.org/jira/browse/CASSANDRA-16673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427633#comment-17427633
]
Alex Petrov commented on CASSANDRA-16673:
-
+1, thank you for the updates. I like the new state. I think we can avoid
{{maybeClear}} in {{get}} because we'll remove {{null}} anyways, and in {{put}}
- because we'll CAS on a newer version anyways. I don't mind to commit without
this change though.
> Avoid race in AbstractReplicationStrategy endpoint caching
> --
>
> Key: CASSANDRA-16673
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16673
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
>
> We should make sure we track which ringVersion we are caching in
> AbstractReplicationStrategy to avoid a race where we might return the wrong
> EndpointsForRange.
> {code}
> Caused by: java.lang.IllegalArgumentException: 9010454139840013625 is not
> contained within (9223372036854775801,-4611686018427387905]
> at
> org.apache.cassandra.locator.EndpointsForRange.forToken(EndpointsForRange.java:59)
> at
> org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicasForToken(AbstractReplicationStrategy.java:104)
> at
> org.apache.cassandra.locator.ReplicaLayout.forTokenReadLiveSorted(ReplicaLayout.java:330)
> at
> org.apache.cassandra.locator.ReplicaPlans.forRead(ReplicaPlans.java:594)
> {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-17027) Allow to grant permission for all tables in a keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17027: -- Reviewers: Andres de la Peña, Ekaterina Dimitrova (was: Ekaterina Dimitrova) > Allow to grant permission for all tables in a keyspace > --- > > Key: CASSANDRA-17027 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17027 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Syntax, Feature/Authorization >Reporter: Benjamin Lerer >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > In some scenario it is useful to prevent users to alter or drop a keyspace > while allowing them to create new tables and user types. -- 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-14337) cast function is not working in INSERT statement
[
https://issues.apache.org/jira/browse/CASSANDRA-14337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-14337:
--
Fix Version/s: (was: 4.x)
4.1
Source Control Link:
https://github.com/apache/cassandra/commit/0d4cc2ef0d246df34d534ef2f0df8ad9bb043206
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> cast function is not working in INSERT statement
>
>
> Key: CASSANDRA-14337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14337
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
> Environment: cqlsh
>Reporter: Rakesh Roshan
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1
>
>
> INSERT INTO test.table(last_modified) values(cast(
> ('2018-03-20 13:05:56.063000+' as timestamp));
>
> fails with error
> *no viable alternative at input '('*
--
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-14337) cast function is not working in INSERT statement
[
https://issues.apache.org/jira/browse/CASSANDRA-14337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427617#comment-17427617
]
Andres de la Peña commented on CASSANDRA-14337:
---
Thanks for the review, committed to {{trunk}} as
[0d4cc2ef0d246df34d534ef2f0df8ad9bb043206|https://github.com/apache/cassandra/commit/0d4cc2ef0d246df34d534ef2f0df8ad9bb043206].
> cast function is not working in INSERT statement
>
>
> Key: CASSANDRA-14337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14337
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
> Environment: cqlsh
>Reporter: Rakesh Roshan
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> INSERT INTO test.table(last_modified) values(cast(
> ('2018-03-20 13:05:56.063000+' as timestamp));
>
> fails with error
> *no viable alternative at input '('*
--
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
[cassandra] branch trunk updated: Add support for type casting in WHERE clause components and in the values of INSERT/UPDATE statements
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 0d4cc2e Add support for type casting in WHERE clause components and
in the values of INSERT/UPDATE statements
0d4cc2e is described below
commit 0d4cc2ef0d246df34d534ef2f0df8ad9bb043206
Author: Andrés de la Peña
AuthorDate: Tue Oct 12 11:55:31 2021 +0100
Add support for type casting in WHERE clause components and in the values
of INSERT/UPDATE statements
patch by Andrés de la Peña; reviewed by Benjamin Lerer for CASSANDRA-14337
---
CHANGES.txt| 1 +
NEWS.txt | 1 +
doc/cql3/CQL.textile | 3 +-
src/antlr/Parser.g | 9 +-
.../cassandra/cql3/functions/FunctionCall.java | 6 +
test/unit/org/apache/cassandra/cql3/CQLTester.java | 10 +
.../cassandra/cql3/functions/CastFctsTest.java | 271 +++--
7 files changed, 278 insertions(+), 23 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index a98d6e0..127e555 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * Add support for type casting in WHERE clause components and in the values
of INSERT/UPDATE statements (CASSANDRA-14337)
* add credentials file support to CQLSH (CASSANDRA-16983)
* Skip remaining bytes in the Envelope buffer when a ProtocolException is
thrown to avoid double decoding (CASSANDRA-17026)
* Allow reverse iteration of resources during permissions checking
(CASSANDRA-17016)
diff --git a/NEWS.txt b/NEWS.txt
index e8ae8e1..6121525 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -38,6 +38,7 @@ using the provided 'sstableupgrade' tool.
New features
+- Added support for type casting in the WHERE clause components and in the
values of INSERT and UPDATE statements.
- Warn/abort thresholds added to read queries notifying clients when these
thresholds trigger (by
emitting a client warning or aborting the query). This feature is
disabled by default, scheduled
to be enabled in 4.2; it is controlled with the configuration
track_warnings.enabled,
diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile
index 46bf8a2..c60800e 100644
--- a/doc/cql3/CQL.textile
+++ b/doc/cql3/CQL.textile
@@ -122,6 +122,7 @@ bc(syntax)..
|
|
| '(' ( (',' )*)? ')'
+ | CAST '(' AS ')'
::=
|
@@ -1951,7 +1952,7 @@ CQL3 distinguishes between built-in functions (so called
'native functions') and
h3(#castFun). Cast
-The @cast@ function can be used to converts one native datatype to another.
+The @cast@ function can be used to convert one native datatype to another.
The following table describes the conversions supported by the @cast@
function. Cassandra will silently ignore any cast converting a datatype into
its own datatype.
diff --git a/src/antlr/Parser.g b/src/antlr/Parser.g
index b3ba7b3..39b3d9f 100644
--- a/src/antlr/Parser.g
+++ b/src/antlr/Parser.g
@@ -1554,9 +1554,10 @@ termGroup returns [Term.Raw term]
;
simpleTerm returns [Term.Raw term]
-: v=value { $term = v; }
-| f=function { $term = f; }
-| '(' c=comparatorType ')' t=simpleTerm { $term = new TypeCast(c, t); }
+: v=value{ $term = v; }
+| f=function { $term = f; }
+| '(' c=comparatorType ')' t=simpleTerm { $term = new TypeCast(c,
t); }
+| K_CAST '(' t=simpleTerm K_AS n=native_type ')' { $term =
FunctionCall.Raw.newCast(t, n); }
;
columnOperation[List> operations]
@@ -1776,7 +1777,7 @@ native_type returns [CQL3Type t]
| K_COUNTER { $t = CQL3Type.Native.COUNTER; }
| K_DECIMAL { $t = CQL3Type.Native.DECIMAL; }
| K_DOUBLE{ $t = CQL3Type.Native.DOUBLE; }
-| K_DURATION{ $t = CQL3Type.Native.DURATION; }
+| K_DURATION { $t = CQL3Type.Native.DURATION; }
| K_FLOAT { $t = CQL3Type.Native.FLOAT; }
| K_INET { $t = CQL3Type.Native.INET;}
| K_INT { $t = CQL3Type.Native.INT; }
diff --git a/src/java/org/apache/cassandra/cql3/functions/FunctionCall.java
b/src/java/org/apache/cassandra/cql3/functions/FunctionCall.java
index 0083a31..4761d66 100644
--- a/src/java/org/apache/cassandra/cql3/functions/FunctionCall.java
+++ b/src/java/org/apache/cassandra/cql3/functions/FunctionCall.java
@@ -148,6 +148,12 @@ public class FunctionCall extends Term.NonTerminal
return new Raw(name, Collections.singletonList(raw));
}
+public static Raw newCast(Term.Raw raw, CQL3Type type)
+{
+FunctionName name =
[jira] [Commented] (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:comment-tabpanel=17427604#comment-17427604
]
Benjamin Lerer commented on CASSANDRA-17030:
It is fine.
> 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
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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] [Commented] (CASSANDRA-16964) WEBSITE - September 2021 blog post on Reaper
[ https://issues.apache.org/jira/browse/CASSANDRA-16964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427585#comment-17427585 ] Erick Ramirez commented on CASSANDRA-16964: --- APPROVED – Verified the following: * blog post renders correctly * all images render correctly * post appears in blog index h2. Blog index !CASSANDRA-16964-blog-index.png|width=300! h2. Blog post !CASSANDRA-16964-blogpost-page1.png|width=300! !CASSANDRA-16964-blogpost-page2.png|width=300! !CASSANDRA-16964-blogpost-page3.png|width=300! !CASSANDRA-16964-blogpost-page4.png|width=300! > WEBSITE - September 2021 blog post on Reaper > > > Key: CASSANDRA-16964 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16964 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Anthony Grasso >Assignee: Erick Ramirez >Priority: Normal > Fix For: NA > > Attachments: CASSANDRA-16964-blog-index.png, > CASSANDRA-16964-blogpost-page1.png, CASSANDRA-16964-blogpost-page2.png, > CASSANDRA-16964-blogpost-page3.png, CASSANDRA-16964-blogpost-page4.png > > > This ticket is to capture the work associated with publishing the August 2021 > blog post. In the blog post we will cover the topic of Reaper and repairs. > We can close this once the blog post has gone live on the website. -- 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-16964) WEBSITE - September 2021 blog post on Reaper
[ https://issues.apache.org/jira/browse/CASSANDRA-16964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16964: -- Attachment: CASSANDRA-16964-blogpost-page1.png CASSANDRA-16964-blogpost-page2.png CASSANDRA-16964-blogpost-page3.png CASSANDRA-16964-blogpost-page4.png CASSANDRA-16964-blog-index.png > WEBSITE - September 2021 blog post on Reaper > > > Key: CASSANDRA-16964 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16964 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Anthony Grasso >Assignee: Erick Ramirez >Priority: Normal > Fix For: NA > > Attachments: CASSANDRA-16964-blog-index.png, > CASSANDRA-16964-blogpost-page1.png, CASSANDRA-16964-blogpost-page2.png, > CASSANDRA-16964-blogpost-page3.png, CASSANDRA-16964-blogpost-page4.png > > > This ticket is to capture the work associated with publishing the August 2021 > blog post. In the blog post we will cover the topic of Reaper and repairs. > We can close this once the blog post has gone live on the website. -- 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-16964) WEBSITE - September 2021 blog post on Reaper
[ https://issues.apache.org/jira/browse/CASSANDRA-16964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-16964: -- Status: Needs Committer (was: Review In Progress) > WEBSITE - September 2021 blog post on Reaper > > > Key: CASSANDRA-16964 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16964 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Anthony Grasso >Assignee: Erick Ramirez >Priority: Normal > Fix For: NA > > Attachments: CASSANDRA-16964-blog-index.png, > CASSANDRA-16964-blogpost-page1.png, CASSANDRA-16964-blogpost-page2.png, > CASSANDRA-16964-blogpost-page3.png, CASSANDRA-16964-blogpost-page4.png > > > This ticket is to capture the work associated with publishing the August 2021 > blog post. In the blog post we will cover the topic of Reaper and repairs. > We can close this once the blog post has gone live on the website. -- 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=17427575#comment-17427575 ] Stefan Miklosovic commented on CASSANDRA-17019: --- It would be awesome if you had a capacity to run dtests too. > 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-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=17427568#comment-17427568 ] Yuqi Gu commented on CASSANDRA-17019: - Sure, I'll post the result of Unit tests late. > 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] [Updated] (CASSANDRA-14557) Add default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-14557:
--
Fix Version/s: (was: 4.x)
4.1
> Add default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.1
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
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-14557) Add default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-14557:
--
Status: Needs Committer (was: Review In Progress)
> Add default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
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-14557) Add default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427546#comment-17427546
]
Stefan Miklosovic commented on CASSANDRA-14557:
---
Thanks, I am +1 on this. I think we need one more +1 to merge.
> Add default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
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=17427540#comment-17427540 ] Stefan Miklosovic commented on CASSANDRA-17019: --- Hi [~yqGu], could you please run all tests? I was reported that build is not a problem but tests are. > 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] [Updated] (CASSANDRA-14337) cast function is not working in INSERT statement
[
https://issues.apache.org/jira/browse/CASSANDRA-14337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14337:
---
Status: Ready to Commit (was: Review In Progress)
> cast function is not working in INSERT statement
>
>
> Key: CASSANDRA-14337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14337
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
> Environment: cqlsh
>Reporter: Rakesh Roshan
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> INSERT INTO test.table(last_modified) values(cast(
> ('2018-03-20 13:05:56.063000+' as timestamp));
>
> fails with error
> *no viable alternative at input '('*
--
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-14337) cast function is not working in INSERT statement
[
https://issues.apache.org/jira/browse/CASSANDRA-14337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427531#comment-17427531
]
Benjamin Lerer commented on CASSANDRA-14337:
Thanks for the patch [~adelapena]. It looks good to me.
> cast function is not working in INSERT statement
>
>
> Key: CASSANDRA-14337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14337
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
> Environment: cqlsh
>Reporter: Rakesh Roshan
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> INSERT INTO test.table(last_modified) values(cast(
> ('2018-03-20 13:05:56.063000+' as timestamp));
>
> fails with error
> *no viable alternative at input '('*
--
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-14337) cast function is not working in INSERT statement
[
https://issues.apache.org/jira/browse/CASSANDRA-14337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14337:
---
Reviewers: Benjamin Lerer
Status: Review In Progress (was: Patch Available)
> cast function is not working in INSERT statement
>
>
> Key: CASSANDRA-14337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14337
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
> Environment: cqlsh
>Reporter: Rakesh Roshan
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> INSERT INTO test.table(last_modified) values(cast(
> ('2018-03-20 13:05:56.063000+' as timestamp));
>
> fails with error
> *no viable alternative at input '('*
--
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-14557) Add default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427487#comment-17427487
]
Sumanth Pasupuleti commented on CASSANDRA-14557:
[~stefan.miklosovic] fyi, updated javadoc
> Add default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
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=17427478#comment-17427478
]
Yuqi Gu edited comment on CASSANDRA-17019 at 10/12/21, 6:42 AM:
Successfully built on Apple M1 by replacing 5.6.0 with
5.9.0([https://github.com/apache/cassandra/pull/1256]):
Environment:
{code:java}
Hardware Overview:
Model Name: Mac mini
Model Identifier: Macmini9,1
Chip: Apple M1
Total Number of Cores: 8 (4 performance and 4 efficiency)
Memory: 16 GB
JDK11:
openjdk 11.0.12 2021-07-20
OpenJDK Runtime Environment Homebrew (build 11.0.12+0)
OpenJDK 64-Bit Server VM Homebrew (build 11.0.12+0, mixed mode)
{code}
{code:java}
$ ant -Duse.jdk11=true
Buildfile: /Users/linux/yuqi/cassandra/build.xml
[script] Warning: Nashorn engine is planned to be removed from a future JDK
releasevalidate-build-conf:init:
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/classes/main
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/lib
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/classes
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/stress-classes
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/fqltool-classes
[mkdir] Created dir: /Users/linux/yuqi/cassandra/src/gen-java
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/lib
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/jacoco
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/jacoco/partials
.
.
...
..
.
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/tools/lib
[jar] Building jar: /Users/linux/yuqi/cassandra/build/tools/lib/stress.jar
[mkdir] Created dir:
/Users/linux/yuqi/cassandra/build/classes/fqltool/META-INF
[jar] Building jar:
/Users/linux/yuqi/cassandra/build/tools/lib/fqltool.jar
BUILD SUCCESSFUL
Total time: 4 minutes 22 seconds
{code}
was (Author: yqgu):
Successfully built on Apple M1 by replacing 5.6.0 with
5.9.0([https://github.com/apache/cassandra/pull/1256]):
Environment:
{code:java}
Hardware Overview:
Model Name: Mac mini
Model Identifier: Macmini9,1
Chip: Apple M1
Total Number of Cores: 8 (4 performance and 4 efficiency)
Memory: 16 GB
JDK11:
openjdk 11.0.12 2021-07-20
OpenJDK Runtime Environment Homebrew (build 11.0.12+0)
OpenJDK 64-Bit Server VM Homebrew (build 11.0.12+0, mixed mode)
{code}
{code:java}
$ ant -Duse.jdk11=true
Buildfile: /Users/linux/yuqi/cassandra/build.xml
[script] Warning: Nashorn engine is planned to be removed from a future JDK
releasevalidate-build-conf:init:
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/classes/main
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/lib
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/classes
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/stress-classes
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/fqltool-classes
[mkdir] Created dir: /Users/linux/yuqi/cassandra/src/gen-java
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/lib
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/jacoco
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/jacoco/partials
.
.
...
..
.
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/tools/lib
[jar] Building jar: /Users/linux/yuqi/cassandra/build/tools/lib/stress.jar
[mkdir] Created dir:
/Users/linux/yuqi/cassandra/build/classes/fqltool/META-INF
[jar] Building jar:
/Users/linux/yuqi/cassandra/build/tools/lib/fqltool.jar
BUILD SUCCESSFUL
Total time: 4 minutes 22 seconds
{code}
> 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] [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=17427478#comment-17427478
]
Yuqi Gu edited comment on CASSANDRA-17019 at 10/12/21, 6:42 AM:
Successfully built on Apple M1 by replacing 5.6.0 with
5.9.0([https://github.com/apache/cassandra/pull/1256]):
Environment:
{code:java}
Hardware Overview:
Model Name: Mac mini
Model Identifier: Macmini9,1
Chip: Apple M1
Total Number of Cores: 8 (4 performance and 4 efficiency)
Memory: 16 GB
JDK11:
openjdk 11.0.12 2021-07-20
OpenJDK Runtime Environment Homebrew (build 11.0.12+0)
OpenJDK 64-Bit Server VM Homebrew (build 11.0.12+0, mixed mode)
{code}
{code:java}
$ ant -Duse.jdk11=true
Buildfile: /Users/linux/yuqi/cassandra/build.xml
[script] Warning: Nashorn engine is planned to be removed from a future JDK
releasevalidate-build-conf:init:
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/classes/main
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/lib
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/classes
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/stress-classes
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/fqltool-classes
[mkdir] Created dir: /Users/linux/yuqi/cassandra/src/gen-java
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/lib
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/jacoco
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/jacoco/partials
.
.
...
..
.
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/tools/lib
[jar] Building jar: /Users/linux/yuqi/cassandra/build/tools/lib/stress.jar
[mkdir] Created dir:
/Users/linux/yuqi/cassandra/build/classes/fqltool/META-INF
[jar] Building jar:
/Users/linux/yuqi/cassandra/build/tools/lib/fqltool.jar
BUILD SUCCESSFUL
Total time: 4 minutes 22 seconds
{code}
was (Author: yqgu):
Successfully built on Apple M1 by replacing 5.6.0 with
5.9.0([https://github.com/apache/cassandra/pull/1256]):
Environment:
{code:java}
Hardware Overview:
Model Name: Mac mini
Model Identifier: Macmini9,1
Chip: Apple M1
Total Number of Cores: 8 (4 performance and 4 efficiency)
Memory: 16 GB
JDK11:
openjdk 11.0.12 2021-07-20
OpenJDK Runtime Environment Homebrew (build 11.0.12+0)
OpenJDK 64-Bit Server VM Homebrew (build 11.0.12+0, mixed mode)
{code}
{code:java}
$ ant -Duse.jdk11=true
Buildfile: /Users/linux/yuqi/cassandra/build.xml
[script] Warning: Nashorn engine is planned to be removed from a future JDK
releasevalidate-build-conf:init:
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/classes/main
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/lib
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/classes
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/stress-classes
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/fqltool-classes
[mkdir] Created dir: /Users/linux/yuqi/cassandra/src/gen-java
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/lib
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/jacoco
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/jacoco/partials
.
.
...
..
.
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/tools/lib
[jar] Building jar: /Users/linux/yuqi/cassandra/build/tools/lib/stress.jar
[mkdir] Created dir:
/Users/linux/yuqi/cassandra/build/classes/fqltool/META-INF
[jar] Building jar:
/Users/linux/yuqi/cassandra/build/tools/lib/fqltool.jar
BUILD SUCCESSFUL
Total time: 4 minutes 22 seconds
{code}
> 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-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=17427478#comment-17427478
]
Yuqi Gu commented on CASSANDRA-17019:
-
Successfully built on Apple M1 by replacing 5.6.0 with
5.9.0([https://github.com/apache/cassandra/pull/1256]):
Environment:
{code:java}
Hardware Overview:
Model Name: Mac mini
Model Identifier: Macmini9,1
Chip: Apple M1
Total Number of Cores: 8 (4 performance and 4 efficiency)
Memory: 16 GB
JDK11:
openjdk 11.0.12 2021-07-20
OpenJDK Runtime Environment Homebrew (build 11.0.12+0)
OpenJDK 64-Bit Server VM Homebrew (build 11.0.12+0, mixed mode)
{code}
{code:java}
$ ant -Duse.jdk11=true
Buildfile: /Users/linux/yuqi/cassandra/build.xml
[script] Warning: Nashorn engine is planned to be removed from a future JDK
releasevalidate-build-conf:init:
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/classes/main
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/lib
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/classes
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/stress-classes
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/test/fqltool-classes
[mkdir] Created dir: /Users/linux/yuqi/cassandra/src/gen-java
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/lib
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/jacoco
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/jacoco/partials
.
.
...
..
.
[mkdir] Created dir: /Users/linux/yuqi/cassandra/build/tools/lib
[jar] Building jar: /Users/linux/yuqi/cassandra/build/tools/lib/stress.jar
[mkdir] Created dir:
/Users/linux/yuqi/cassandra/build/classes/fqltool/META-INF
[jar] Building jar:
/Users/linux/yuqi/cassandra/build/tools/lib/fqltool.jar
BUILD SUCCESSFUL
Total time: 4 minutes 22 seconds
{code}
> 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
