[jira] [Updated] (CASSANDRA-18941) Support max SSTable size in sorted CQLSSTableWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-18941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-18941: -- Reviewers: Alex Petrov, Francisco Guerrero, Maxwell Guo (was: Francisco Guerrero, Maxwell Guo) Status: Review In Progress (was: Needs Committer) > Support max SSTable size in sorted CQLSSTableWriter > --- > > Key: CASSANDRA-18941 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18941 > Project: Cassandra > Issue Type: Improvement > Components: Tool/sstable >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 5.x > > Time Spent: 2h 40m > Remaining Estimate: 0h > > The CQLSSTableWriter can produce a series of SSTables with a bounded size in > the unsorted mode. The functionality is missing in the sorted > CQLSSTableWriter. > It will be great to bringing the parity to the sorted mode, so that it is > able to produce a series of size-bounded SSTable, instead of a single but > giant one. > Unlike the unsorted CQLSSTableWriter, the max SSTable size in the sorted > writer does not require buffering. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18941) Support max SSTable size in sorted CQLSSTableWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-18941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1996#comment-1996 ] Yifan Cai commented on CASSANDRA-18941: --- It makes sense to use the same method for both cases. I just pushed a new commit to address it. > Support max SSTable size in sorted CQLSSTableWriter > --- > > Key: CASSANDRA-18941 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18941 > Project: Cassandra > Issue Type: Improvement > Components: Tool/sstable >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 5.x > > Time Spent: 2h 40m > Remaining Estimate: 0h > > The CQLSSTableWriter can produce a series of SSTables with a bounded size in > the unsorted mode. The functionality is missing in the sorted > CQLSSTableWriter. > It will be great to bringing the parity to the sorted mode, so that it is > able to produce a series of size-bounded SSTable, instead of a single but > giant one. > Unlike the unsorted CQLSSTableWriter, the max SSTable size in the sorted > writer does not require buffering. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18952) Add metrics and logging to repair retries
[ https://issues.apache.org/jira/browse/CASSANDRA-18952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1993#comment-1993 ] Maxim Muzafarov commented on CASSANDRA-18952: - [~dcapwell] Thank you for the patch! I left a few comments in PR. Looks like you raised these two PRs against the 5.0 branch, I guess one of them should be against the trunk branch, right? Do we need to write tests for these metrics? > Add metrics and logging to repair retries > - > > Key: CASSANDRA-18952 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18952 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair, Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.0.x, 5.x > > Time Spent: 40m > Remaining Estimate: 0h > > In CASSANDRA-18816 we added repair message retries but forgot to add logging > and metrics to actually let operators know repairs happened and how often… we > should add such visibility to help operators know how best to tune it for > their environment. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18952) Add metrics and logging to repair retries
[
https://issues.apache.org/jira/browse/CASSANDRA-18952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1981#comment-1981
]
David Capwell commented on CASSANDRA-18952:
---
sample logs generated during simulation
{code}
INFO [main] 2023-10-20 14:38:44,766 NoSpamLogger.java:99 - [repair
#ff3a7920-6f90-11ee-84c8-e333f98a75a2] Retry of repair verb SNAPSHOT_MSG was
success after 1 attempts
WARN [main] 2023-10-20 14:39:21,274 NoSpamLogger.java:102 - [repair
#210bb320-6f91-11ee-a2be-c1f203a1893a] Timeout for repair verb VALIDATION_REQ;
could not complete within 2 attempts
{code}
> Add metrics and logging to repair retries
> -
>
> Key: CASSANDRA-18952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18952
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair, Observability/Metrics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In CASSANDRA-18816 we added repair message retries but forgot to add logging
> and metrics to actually let operators know repairs happened and how often… we
> should add such visibility to help operators know how best to tune it for
> their environment.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18952) Add metrics and logging to repair retries
[ https://issues.apache.org/jira/browse/CASSANDRA-18952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18952: -- Test and Documentation Plan: existing tests Status: Patch Available (was: Open) > Add metrics and logging to repair retries > - > > Key: CASSANDRA-18952 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18952 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair, Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.0.x, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > In CASSANDRA-18816 we added repair message retries but forgot to add logging > and metrics to actually let operators know repairs happened and how often… we > should add such visibility to help operators know how best to tune it for > their environment. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18952) Add metrics and logging to repair retries
David Capwell created CASSANDRA-18952: - Summary: Add metrics and logging to repair retries Key: CASSANDRA-18952 URL: https://issues.apache.org/jira/browse/CASSANDRA-18952 Project: Cassandra Issue Type: Improvement Components: Consistency/Repair, Observability/Metrics Reporter: David Capwell Assignee: David Capwell In CASSANDRA-18816 we added repair message retries but forgot to add logging and metrics to actually let operators know repairs happened and how often… we should add such visibility to help operators know how best to tune it for their environment. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18952) Add metrics and logging to repair retries
[ https://issues.apache.org/jira/browse/CASSANDRA-18952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18952: -- Change Category: Operability Complexity: Low Hanging Fruit Fix Version/s: 5.0.x 5.x Status: Open (was: Triage Needed) > Add metrics and logging to repair retries > - > > Key: CASSANDRA-18952 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18952 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair, Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.0.x, 5.x > > > In CASSANDRA-18816 we added repair message retries but forgot to add logging > and metrics to actually let operators know repairs happened and how often… we > should add such visibility to help operators know how best to tune it for > their environment. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18929) CEP-15: (C*) Implement TopologySorter to prioritise hosts based on DynamicSnitch and/or topology layout
[ https://issues.apache.org/jira/browse/CASSANDRA-18929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1976#comment-1976 ] David Capwell commented on CASSANDRA-18929: --- too many failing tests, but compared against the current HEAD and CI mostly matches https://app.circleci.com/pipelines/github/dcapwell/cassandra/2307/workflows/6e2bc0da-4a6b-4f07-ad92-0e68ddef9ca2. so looks like its good... > CEP-15: (C*) Implement TopologySorter to prioritise hosts based on > DynamicSnitch and/or topology layout > --- > > Key: CASSANDRA-18929 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18929 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Implement TopologySorter to prioritise hosts based on DynamicSnitch and/or > topology layout -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-79) Sidecar should be able to load metadata even if the local instance is unavailable
[ https://issues.apache.org/jira/browse/CASSANDRASC-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRASC-79: -- Labels: pull-request-available (was: ) > Sidecar should be able to load metadata even if the local instance is > unavailable > - > > Key: CASSANDRASC-79 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-79 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Doug Rohrer >Assignee: Doug Rohrer >Priority: Normal > Labels: pull-request-available > > Today, the sidecar’s CassandraAdapter/CqlSessionProvider uses a load > balancing policy that only allows connections to a single instance configured > for one of the managed instances of Cassandra. However, this is both > unnecessary and potentially harmful, as requests to that instance’s hostname > will fail to retrieve information like keyspace/cluster metadata when that > instance is unavailable, and will not receive any updates to metadata either, > which can cause stale metadata to be used. > Instead, the CqlSessionProvider should take a list of contact points and use > them to connect to the whole cluster (or a subset of nodes) without the > single-instance load balancing policy. Where it is necessary to query an > individual instance (system tables, attempts to check the health of a > particular instance) we can, instead, use the driver’s ability to direct > queries to a specific host on a per-statement basis. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18896) ClientRequestSize metrics should not treat CONTAINS restrictions as being equality-based
[
https://issues.apache.org/jira/browse/CASSANDRA-18896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1480#comment-1480
]
Caleb Rackliffe edited comment on CASSANDRA-18896 at 10/20/23 8:09 PM:
---
5.0: [https://github.com/apache/cassandra/pull/2829]
trunk: [https://github.com/apache/cassandra/pull/2831]
was (Author: maedhroz):
5.0 patch: [https://github.com/apache/cassandra/pull/2829]
> ClientRequestSize metrics should not treat CONTAINS restrictions as being
> equality-based
>
>
> Key: CASSANDRA-18896
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18896
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-alpha2, 5.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The following behavior needs to be changed to consider the column restricted
> by {{CONTAINS}} or {{CONTAINS KEY}} as "read", rather than "provided by the
> client". We already do this for things like range restrictions, and the
> current behavior is inconsistent.
> {noformat}
> @Test
> public void shouldRecordReadMetricsForContainsQuery() throws Throwable
> {
> createTable("CREATE TABLE %s (pk int, ck int, v set, PRIMARY KEY
> (pk, ck))");
> executeNet(CURRENT, "INSERT INTO %s (pk, ck, v) VALUES (1, 1, {1, 2, 3}
> )");
> executeNet(CURRENT, "INSERT INTO %s (pk, ck, v) VALUES (2, 2, {4, 5,
> 6})");
> executeNet(CURRENT, "SELECT * FROM %s WHERE v CONTAINS 1 ALLOW
> FILTERING");
> assertEquals(1, ClientRequestSizeMetrics.totalRowsRead.getCount());
> // The filtering term is provided by the client in the request, so we
> don't consider that column read.
> assertEquals(2, ClientRequestSizeMetrics.totalColumnsRead.getCount());
> }
> {noformat}
> The fix should be literally two lines, one in {{SingleRestriction}} and one
> in the test above.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (e732d7888 -> e422614e4)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard e732d7888 generate docs for 1d0135e5 add dddbfce3d Ensure 4.1 and 5.0 sections for git branch based contributions state the correct versions new e422614e4 generate docs for dddbfce3 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (e732d7888) \ N -- N -- N refs/heads/asf-staging (e422614e4) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/_/development/how_to_commit.html | 4 ++-- content/_/development/index.html | 4 ++-- .../managing/tools/nodetool/upgradesstables.html | 3 ++- .../managing/tools/nodetool/upgradesstables.html | 3 ++- .../ROOT/pages/development/how_to_commit.adoc | 4 ++-- site-ui/build/ui-bundle.zip| Bin 4881412 -> 4881412 bytes 6 files changed, 10 insertions(+), 8 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18896) ClientRequestSize metrics should not treat CONTAINS restrictions as being equality-based
[
https://issues.apache.org/jira/browse/CASSANDRA-18896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18896:
Fix Version/s: 5.0-alpha2
(was: 5.0.x)
> ClientRequestSize metrics should not treat CONTAINS restrictions as being
> equality-based
>
>
> Key: CASSANDRA-18896
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18896
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-alpha2, 5.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following behavior needs to be changed to consider the column restricted
> by {{CONTAINS}} or {{CONTAINS KEY}} as "read", rather than "provided by the
> client". We already do this for things like range restrictions, and the
> current behavior is inconsistent.
> {noformat}
> @Test
> public void shouldRecordReadMetricsForContainsQuery() throws Throwable
> {
> createTable("CREATE TABLE %s (pk int, ck int, v set, PRIMARY KEY
> (pk, ck))");
> executeNet(CURRENT, "INSERT INTO %s (pk, ck, v) VALUES (1, 1, {1, 2, 3}
> )");
> executeNet(CURRENT, "INSERT INTO %s (pk, ck, v) VALUES (2, 2, {4, 5,
> 6})");
> executeNet(CURRENT, "SELECT * FROM %s WHERE v CONTAINS 1 ALLOW
> FILTERING");
> assertEquals(1, ClientRequestSizeMetrics.totalRowsRead.getCount());
> // The filtering term is provided by the client in the request, so we
> don't consider that column read.
> assertEquals(2, ClientRequestSizeMetrics.totalColumnsRead.getCount());
> }
> {noformat}
> The fix should be literally two lines, one in {{SingleRestriction}} and one
> in the test above.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18896) ClientRequestSize metrics should not treat CONTAINS restrictions as being equality-based
[
https://issues.apache.org/jira/browse/CASSANDRA-18896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18896:
Reviewers: Benjamin Lerer
Status: Review In Progress (was: Patch Available)
> ClientRequestSize metrics should not treat CONTAINS restrictions as being
> equality-based
>
>
> Key: CASSANDRA-18896
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18896
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following behavior needs to be changed to consider the column restricted
> by {{CONTAINS}} or {{CONTAINS KEY}} as "read", rather than "provided by the
> client". We already do this for things like range restrictions, and the
> current behavior is inconsistent.
> {noformat}
> @Test
> public void shouldRecordReadMetricsForContainsQuery() throws Throwable
> {
> createTable("CREATE TABLE %s (pk int, ck int, v set, PRIMARY KEY
> (pk, ck))");
> executeNet(CURRENT, "INSERT INTO %s (pk, ck, v) VALUES (1, 1, {1, 2, 3}
> )");
> executeNet(CURRENT, "INSERT INTO %s (pk, ck, v) VALUES (2, 2, {4, 5,
> 6})");
> executeNet(CURRENT, "SELECT * FROM %s WHERE v CONTAINS 1 ALLOW
> FILTERING");
> assertEquals(1, ClientRequestSizeMetrics.totalRowsRead.getCount());
> // The filtering term is provided by the client in the request, so we
> don't consider that column read.
> assertEquals(2, ClientRequestSizeMetrics.totalColumnsRead.getCount());
> }
> {noformat}
> The fix should be literally two lines, one in {{SingleRestriction}} and one
> in the test above.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18836) Replace CRC32 w/ CRC32C in IndexFileUtils.ChecksummingWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-18836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1946#comment-1946 ] Caleb Rackliffe commented on CASSANDRA-18836: - Committed. Thanks for the patch! > Replace CRC32 w/ CRC32C in IndexFileUtils.ChecksummingWriter > > > Key: CASSANDRA-18836 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18836 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index, Feature/SAI >Reporter: Caleb Rackliffe >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0-alpha2, 5.0, 5.1 > > Time Spent: 5h 40m > Remaining Estimate: 0h > > It seems that now we're on Java 11 for 5.0, there isn't much reason not to > use CRC32C as a drop-in replacement for CRC32. SAI isn't even released, so > has no binary compatibility entanglements, and this should be pretty > straightforward. > See https://github.com/apache/bookkeeper/pull/3309 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18836) Replace CRC32 w/ CRC32C in IndexFileUtils.ChecksummingWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-18836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18836: Fix Version/s: 5.0 5.1 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/07df26778b01a00c1f5770c8cf133ce4c2829533 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Replace CRC32 w/ CRC32C in IndexFileUtils.ChecksummingWriter > > > Key: CASSANDRA-18836 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18836 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index, Feature/SAI >Reporter: Caleb Rackliffe >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0-alpha2, 5.0, 5.1 > > Time Spent: 5h 40m > Remaining Estimate: 0h > > It seems that now we're on Java 11 for 5.0, there isn't much reason not to > use CRC32C as a drop-in replacement for CRC32. SAI isn't even released, so > has no binary compatibility entanglements, and this should be pretty > straightforward. > See https://github.com/apache/bookkeeper/pull/3309 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (06202c9ff3 -> bf321d7951)
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 06202c9ff3 Merge branch 'cassandra-5.0' into trunk new 07df26778b Change the checksum algorithm SAI-related files use from CRC32 to CRC32C new bf321d7951 Merge branch 'cassandra-5.0' into trunk 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: CHANGES.txt| 1 + .../sai/disk/io/BufferedChecksumIndexInput.java| 86 ++ .../index/sai/disk/io/IndexFileUtils.java | 19 - .../index/sai/disk/v1/MetadataSource.java | 5 +- .../cassandra/index/sai/disk/v1/SAICodecUtils.java | 42 --- .../index/sai/disk/v1/SAICodecUtilsTest.java | 22 +++--- 6 files changed, 148 insertions(+), 27 deletions(-) create mode 100644 src/java/org/apache/cassandra/index/sai/disk/io/BufferedChecksumIndexInput.java - 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-5.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 bf321d79511de0b7fc99ae652a6523042ec5e659 Merge: 06202c9ff3 07df26778b Author: Caleb Rackliffe AuthorDate: Fri Oct 20 14:47:26 2023 -0500 Merge branch 'cassandra-5.0' into trunk * cassandra-5.0: Change the checksum algorithm SAI-related files use from CRC32 to CRC32C CHANGES.txt| 1 + .../sai/disk/io/BufferedChecksumIndexInput.java| 86 ++ .../index/sai/disk/io/IndexFileUtils.java | 19 - .../index/sai/disk/v1/MetadataSource.java | 5 +- .../cassandra/index/sai/disk/v1/SAICodecUtils.java | 42 --- .../index/sai/disk/v1/SAICodecUtilsTest.java | 22 +++--- 6 files changed, 148 insertions(+), 27 deletions(-) diff --cc CHANGES.txt index ed18ef6962,547a1bb11f..7b4ea53fc4 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,8 -1,5 +1,9 @@@ -5.0-alpha2 +5.1 + * Add ELAPSED command to cqlsh (CASSANDRA-18861) + * Add the ability to disable bulk loading of SSTables (CASSANDRA-18781) + * Clean up obsolete functions and simplify cql_version handling in cqlsh (CASSANDRA-18787) +Merged from 5.0: + * Change the checksum algorithm SAI-related files use from CRC32 to CRC32C (CASSANDRA-18836) * Correctly remove Index.Group from IndexRegistry (CASSANDRA-18905) * Fix vector type to support DDM's mask_default function (CASSANDRA-18889) * Remove unnecessary reporter-config3 dependency (CASSANDRA-18907) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-5.0 updated: Change the checksum algorithm SAI-related files use from CRC32 to CRC32C
This is an automated email from the ASF dual-hosted git repository.
maedhroz pushed a commit to branch cassandra-5.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-5.0 by this push:
new 07df26778b Change the checksum algorithm SAI-related files use from
CRC32 to CRC32C
07df26778b is described below
commit 07df26778b01a00c1f5770c8cf133ce4c2829533
Author: Maxim Muzafarov
AuthorDate: Fri Oct 20 11:01:54 2023 +0200
Change the checksum algorithm SAI-related files use from CRC32 to CRC32C
patch by Maxim Muzafarov; reviewed by Caleb Rackliffe and Zhao Yang for
CASSANDRA-18836
---
CHANGES.txt| 1 +
.../sai/disk/io/BufferedChecksumIndexInput.java| 86 ++
.../index/sai/disk/io/IndexFileUtils.java | 19 -
.../index/sai/disk/v1/MetadataSource.java | 5 +-
.../cassandra/index/sai/disk/v1/SAICodecUtils.java | 42 ---
.../index/sai/disk/v1/SAICodecUtilsTest.java | 22 +++---
6 files changed, 148 insertions(+), 27 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 89d1163f83..547a1bb11f 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
5.0-alpha2
+ * Change the checksum algorithm SAI-related files use from CRC32 to CRC32C
(CASSANDRA-18836)
* Correctly remove Index.Group from IndexRegistry (CASSANDRA-18905)
* Fix vector type to support DDM's mask_default function (CASSANDRA-18889)
* Remove unnecessary reporter-config3 dependency (CASSANDRA-18907)
diff --git
a/src/java/org/apache/cassandra/index/sai/disk/io/BufferedChecksumIndexInput.java
b/src/java/org/apache/cassandra/index/sai/disk/io/BufferedChecksumIndexInput.java
new file mode 100644
index 00..333868466a
--- /dev/null
+++
b/src/java/org/apache/cassandra/index/sai/disk/io/BufferedChecksumIndexInput.java
@@ -0,0 +1,86 @@
+/*
+ * 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.index.sai.disk.io;
+
+import org.apache.lucene.store.ChecksumIndexInput;
+import org.apache.lucene.store.IndexInput;
+
+import java.io.IOException;
+import java.util.zip.Checksum;
+
+/**
+ * This implementation of {@link ChecksumIndexInput} is based on {@link
org.apache.lucene.store.BufferedChecksumIndexInput}
+ * but uses custom checksum algorithm instead of the hardcoded {@code CRC32}
in {@code BufferedChecksumIndexInput}.
+ *
+ * @see
org.apache.cassandra.index.sai.disk.io.IndexFileUtils.ChecksummingWriter
+ */
+class BufferedChecksumIndexInput extends ChecksumIndexInput
+{
+final IndexInput delegate;
+final Checksum digest;
+
+public BufferedChecksumIndexInput(IndexInput delegate, Checksum digest)
+{
+super("BufferedChecksumIndexInput(" + delegate + ')');
+this.delegate = delegate;
+this.digest = digest;
+}
+
+public byte readByte() throws IOException
+{
+byte b = this.delegate.readByte();
+this.digest.update(b);
+return b;
+}
+
+public void readBytes(byte[] b, int offset, int len) throws IOException
+{
+this.delegate.readBytes(b, offset, len);
+this.digest.update(b, offset, len);
+}
+
+public long getChecksum()
+{
+return this.digest.getValue();
+}
+
+public void close() throws IOException
+{
+this.delegate.close();
+}
+public long getFilePointer()
+{
+return this.delegate.getFilePointer();
+}
+
+public long length()
+{
+return this.delegate.length();
+}
+
+public IndexInput clone()
+{
+throw new UnsupportedOperationException();
+}
+
+public IndexInput slice(String sliceDescription, long offset, long length)
throws IOException
+{
+throw new UnsupportedOperationException();
+}
+}
diff --git
a/src/java/org/apache/cassandra/index/sai/disk/io/IndexFileUtils.java
b/src/java/org/apache/cassandra/index/sai/disk/io/IndexFileUtils.java
index b0145d24fd..4d280ea7a1 100644
--- a/src/java/org/apache/cassandra/index/sai/disk/io/IndexFileUtils.java
+++ b/src/java/org/apache/cassandra/index/sai/disk/io/IndexFileUtils.java
@@ -20,7 +20,9 @@ package
[cassandra-website] branch trunk updated: Ensure 4.1 and 5.0 sections for git branch based contributions state the correct versions
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new dddbfce3d Ensure 4.1 and 5.0 sections for git branch based contributions state the correct versions dddbfce3d is described below commit dddbfce3dfc9c2b25216473627be9c0a2e1d93e2 Author: Caleb Rackliffe AuthorDate: Fri Oct 20 14:37:13 2023 -0500 Ensure 4.1 and 5.0 sections for git branch based contributions state the correct versions --- site-content/source/modules/ROOT/pages/development/how_to_commit.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc b/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc index 383fcf605..e3c2ad1f4 100644 --- a/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc +++ b/site-content/source/modules/ROOT/pages/development/how_to_commit.adoc @@ -63,7 +63,7 @@ On cassandra-4.0::: compiles) On cassandra-4.1::: . `+git merge cassandra-4.0 -s ours --log+` - . `+git format-patch -1 +` (alternative to + . `+git format-patch -1 +` (alternative to format-patch and apply is [.title-ref]#cherry-pick -n#) . `+git apply -3 .patch+` (any issue with CHANGES.txt : fix and [.title-ref]#git add CHANGES.txt#) @@ -73,7 +73,7 @@ On cassandra-4.1::: patch into the forward merge commit) On cassandra-5.0::: . `+git merge cassandra-4.1 -s ours --log+` -. `+git format-patch -1 +` (alternative to +. `+git format-patch -1 +` (alternative to format-patch and apply is [.title-ref]#cherry-pick -n#) . `+git apply -3 .patch+` (any issue with CHANGES.txt : fix and [.title-ref]#git add CHANGES.txt#) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18836) Replace CRC32 w/ CRC32C in IndexFileUtils.ChecksummingWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-18836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18836: Status: Ready to Commit (was: Review In Progress) > Replace CRC32 w/ CRC32C in IndexFileUtils.ChecksummingWriter > > > Key: CASSANDRA-18836 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18836 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index, Feature/SAI >Reporter: Caleb Rackliffe >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0-alpha2, 5.x > > Time Spent: 5h > Remaining Estimate: 0h > > It seems that now we're on Java 11 for 5.0, there isn't much reason not to > use CRC32C as a drop-in replacement for CRC32. SAI isn't even released, so > has no binary compatibility entanglements, and this should be pretty > straightforward. > See https://github.com/apache/bookkeeper/pull/3309 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18836) Replace CRC32 w/ CRC32C in IndexFileUtils.ChecksummingWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-18836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18836: Reviewers: Caleb Rackliffe, Zhao Yang (was: Caleb Rackliffe) > Replace CRC32 w/ CRC32C in IndexFileUtils.ChecksummingWriter > > > Key: CASSANDRA-18836 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18836 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index, Feature/SAI >Reporter: Caleb Rackliffe >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0-alpha2, 5.x > > Time Spent: 5h > Remaining Estimate: 0h > > It seems that now we're on Java 11 for 5.0, there isn't much reason not to > use CRC32C as a drop-in replacement for CRC32. SAI isn't even released, so > has no binary compatibility entanglements, and this should be pretty > straightforward. > See https://github.com/apache/bookkeeper/pull/3309 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18951) Add option for MutualTlsAuthenticator to restrict the certificate age
[
https://issues.apache.org/jira/browse/CASSANDRA-18951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Guerrero updated CASSANDRA-18951:
---
Change Category: Semantic
Complexity: Normal
Component/s: Feature/Authorization
Status: Open (was: Triage Needed)
> Add option for MutualTlsAuthenticator to restrict the certificate age
> -
>
> Key: CASSANDRA-18951
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18951
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Authorization
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
>
> In {{org.apache.cassandra.auth.MutualTlsAuthenticator}}, we validate that a
> certificate is valid by looking at the identities inside the
> certificate and making sure the identity exists in the identity to role table.
> In some situations we may want to restrict the certificates
> we accept by rejecting certificates older than x amount of days. Some
> certificates can be generated with long expiration dates,
> and this might be undesired when you want to protect against potential
> certificates being compromised. For that reason, it is
> important to add an option, that when configured, we can limit the age of the
> certificate we accept for mTLS authentication.
> When enabled, this will force clients to have to renew certificates more
> frequently, reducing the exposure of a Cassandra cluster
> to leaked certificates.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18951) Add option for MutualTlsAuthenticator to restrict the certificate age
Francisco Guerrero created CASSANDRA-18951:
--
Summary: Add option for MutualTlsAuthenticator to restrict the
certificate age
Key: CASSANDRA-18951
URL: https://issues.apache.org/jira/browse/CASSANDRA-18951
Project: Cassandra
Issue Type: New Feature
Reporter: Francisco Guerrero
Assignee: Francisco Guerrero
In {{org.apache.cassandra.auth.MutualTlsAuthenticator}}, we validate that a
certificate is valid by looking at the identities inside the
certificate and making sure the identity exists in the identity to role table.
In some situations we may want to restrict the certificates
we accept by rejecting certificates older than x amount of days. Some
certificates can be generated with long expiration dates,
and this might be undesired when you want to protect against potential
certificates being compromised. For that reason, it is
important to add an option, that when configured, we can limit the age of the
certificate we accept for mTLS authentication.
When enabled, this will force clients to have to renew certificates more
frequently, reducing the exposure of a Cassandra cluster
to leaked certificates.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18950) Test failure: dtest.sslnodetonode_test.TestNodeToNodeSSLEncryption.test_ca_mismatch
[
https://issues.apache.org/jira/browse/CASSANDRA-18950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18950:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test failure:
> dtest.sslnodetonode_test.TestNodeToNodeSSLEncryption.test_ca_mismatch
> ---
>
> Key: CASSANDRA-18950
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18950
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1746/testReport/dtest.sslnodetonode_test/TestNodeToNodeSSLEncryption/test_ca_mismatch/]
>
> {code:java}
> self = 0x7f45da997710> def test_ca_mismatch(self): """CA mismatch should cause nodes
> to fail to connect""" credNode1 = sslkeygen.generate_credentials("127.0.0.1")
> credNode2 = sslkeygen.generate_credentials("127.0.0.2") # mismatching CA!
> self.setup_nodes(credNode1, credNode2)
> self.fixture_dtest_setup.allow_log_errors = True
> self.cluster.start(no_wait=True) found = self._grep_msg(self.node1,
> _LOG_ERR_HANDSHAKE) self.cluster.stop() > assert found E assert False
> sslnodetonode_test.py:115: AssertionError{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18950) Test failure: dtest.sslnodetonode_test.TestNodeToNodeSSLEncryption.test_ca_mismatch
Ekaterina Dimitrova created CASSANDRA-18950:
---
Summary: Test failure:
dtest.sslnodetonode_test.TestNodeToNodeSSLEncryption.test_ca_mismatch
Key: CASSANDRA-18950
URL: https://issues.apache.org/jira/browse/CASSANDRA-18950
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Seen here:
[https://ci-cassandra.apache.org/job/Cassandra-trunk/1746/testReport/dtest.sslnodetonode_test/TestNodeToNodeSSLEncryption/test_ca_mismatch/]
{code:java}
self = def test_ca_mismatch(self): """CA mismatch should cause nodes
to fail to connect""" credNode1 = sslkeygen.generate_credentials("127.0.0.1")
credNode2 = sslkeygen.generate_credentials("127.0.0.2") # mismatching CA!
self.setup_nodes(credNode1, credNode2)
self.fixture_dtest_setup.allow_log_errors = True
self.cluster.start(no_wait=True) found = self._grep_msg(self.node1,
_LOG_ERR_HANDSHAKE) self.cluster.stop() > assert found E assert False
sslnodetonode_test.py:115: AssertionError{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18950) Test failure: dtest.sslnodetonode_test.TestNodeToNodeSSLEncryption.test_ca_mismatch
[
https://issues.apache.org/jira/browse/CASSANDRA-18950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18950:
Fix Version/s: 5.x
> Test failure:
> dtest.sslnodetonode_test.TestNodeToNodeSSLEncryption.test_ca_mismatch
> ---
>
> Key: CASSANDRA-18950
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18950
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1746/testReport/dtest.sslnodetonode_test/TestNodeToNodeSSLEncryption/test_ca_mismatch/]
>
> {code:java}
> self = 0x7f45da997710> def test_ca_mismatch(self): """CA mismatch should cause nodes
> to fail to connect""" credNode1 = sslkeygen.generate_credentials("127.0.0.1")
> credNode2 = sslkeygen.generate_credentials("127.0.0.2") # mismatching CA!
> self.setup_nodes(credNode1, credNode2)
> self.fixture_dtest_setup.allow_log_errors = True
> self.cluster.start(no_wait=True) found = self._grep_msg(self.node1,
> _LOG_ERR_HANDSHAKE) self.cluster.stop() > assert found E assert False
> sslnodetonode_test.py:115: AssertionError{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18798) Appending to list in Accord transactions uses insertion timestamp
[
https://issues.apache.org/jira/browse/CASSANDRA-18798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1896#comment-1896
]
Henrik Ingo commented on CASSANDRA-18798:
-
New branch btw: https://github.com/apache/cassandra/pull/2830
This seems to work now. Key was to understand what each method in TimeUUID
class really does.
I'll add some source code commentary in that regard on Monday, then submit for
review.
[~kijanowski] to confirm whether the Elle test now passes
> Appending to list in Accord transactions uses insertion timestamp
> -
>
> Key: CASSANDRA-18798
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18798
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: Jaroslaw Kijanowski
>Assignee: Henrik Ingo
>Priority: Normal
> Fix For: 5.0-alpha2
>
> Attachments: image-2023-09-26-20-05-25-846.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Given the following schema:
> {code:java}
> CREATE KEYSPACE IF NOT EXISTS accord WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 3};
> CREATE TABLE IF NOT EXISTS accord.list_append(id int PRIMARY KEY,contents
> LIST);
> TRUNCATE accord.list_append;{code}
> And the following two possible queries executed by 10 threads in parallel:
> {code:java}
> BEGIN TRANSACTION
> LET row = (SELECT * FROM list_append WHERE id = ?);
> SELECT row.contents;
> COMMIT TRANSACTION;"
> BEGIN TRANSACTION
> UPDATE list_append SET contents += ? WHERE id = ?;
> COMMIT TRANSACTION;"
> {code}
> there seems to be an issue with transaction guarantees. Here's an excerpt in
> the edn format from a test.
> {code:java}
> {:type :invoke :process 8 :value [[:append 5 352]] :tid 3 :n 52
> :time 1692607285967116627}
> {:type :invoke :process 9 :value [[:r 5 nil]] :tid 1 :n 54
> :time 1692607286078732473}
> {:type :invoke :process 6 :value [[:append 5 553]] :tid 5 :n 53
> :time 1692607286133833428}
> {:type :invoke :process 7 :value [[:append 5 455]] :tid 4 :n 55
> :time 1692607286149702511}
> {:type :ok :process 8 :value [[:append 5 352]] :tid 3 :n 52
> :time 1692607286156314099}
> {:type :invoke :process 5 :value [[:r 5 nil]] :tid 9 :n 52
> :time 1692607286167090389}
> {:type :ok :process 9 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352]]] :tid 1 :n 54 :time 1692607286168657534}
> {:type :invoke :process 1 :value [[:r 5 nil]] :tid 0 :n 51
> :time 1692607286201762938}
> {:type :ok :process 7 :value [[:append 5 455]] :tid 4 :n 55
> :time 1692607286245571513}
> {:type :invoke :process 7 :value [[:r 5 nil]] :tid 4 :n 56
> :time 1692607286245655775}
> {:type :ok :process 5 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352 455]]] :tid 9 :n 52 :time 1692607286253928906}
> {:type :invoke :process 5 :value [[:r 5 nil]] :tid 9 :n 53
> :time 1692607286254095215}
> {:type :ok :process 6 :value [[:append 5 553]] :tid 5 :n 53
> :time 1692607286266263422}
> {:type :ok :process 1 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352 553 455]]] :tid 0 :n 51 :time 1692607286271617955}
> {:type :ok :process 7 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352 553 455]]] :tid 4 :n 56 :time 1692607286271816933}
> {:type :ok :process 5 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352 553 455]]] :tid 9 :n 53 :time 1692607286281483026}
> {:type :invoke :process 9 :value [[:r 5 nil]] :tid 1 :n 56
> :time 1692607286284097561}
> {:type :ok :process 9 :value [[:r 5 [303 304 604 6 306 509 909 409 912
> 411 514 415 719 419 19 623 22 425 24 926 25 832 130 733 430 533 29 933 333
> 537 934 538 740 139 744 938 544 42 646 749 242 546 547 548 753 450 150 349 48
> 852 352 553 455]]] :tid 1 :n 56 :time
[jira] [Created] (CASSANDRA-18949) Test failure: org.apache.cassandra.tools.nodetool.ClearSnapshotTest.testClearSnapshot_RemoveByName-.jdk11.arch=x86_64.python2.7
Ekaterina Dimitrova created CASSANDRA-18949:
---
Summary: Test failure:
org.apache.cassandra.tools.nodetool.ClearSnapshotTest.testClearSnapshot_RemoveByName-.jdk11.arch=x86_64.python2.7
Key: CASSANDRA-18949
URL: https://issues.apache.org/jira/browse/CASSANDRA-18949
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Seen here:
[https://ci-cassandra.apache.org/job/Cassandra-trunk/1747/testReport/org.apache.cassandra.tools.nodetool/ClearSnapshotTest/testClearSnapshot_RemoveByName__jdk11_arch_x86_64_python2_7/]
h3.
{code:java}
Error Message
[bin/nodetool, -p, 36753, -h, 127.0.0.1, snapshot, -t, some-name] exited with
code 2 stderr: error: Unknown keyspace keyspace_04 -- StackTrace --
java.lang.AssertionError: Unknown keyspace keyspace_04 at
org.apache.cassandra.db.Keyspace.(Keyspace.java:324) at
org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162) at
org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)
at
org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251) at
org.apache.cassandra.db.Keyspace.open(Keyspace.java:162) at
org.apache.cassandra.db.Keyspace.open(Keyspace.java:151) at
com.google.common.collect.Iterators$6.transform(Iterators.java:828) at
com.google.common.collect.TransformedIterator.next(TransformedIterator.java:52)
at
org.apache.cassandra.service.StorageService.takeSnapshot(StorageService.java:4356)
at
org.apache.cassandra.service.StorageService.takeSnapshot(StorageService.java:4221)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) at
jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260) at
java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
at
java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
at
java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at
java.management/com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at
java.management/com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at
java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:809)
at
java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at
java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1466)
at
java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
at
java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1399)
at
java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:827)
at java.base/jdk.internal.reflect.GeneratedMethodAccessor16.invoke(Unknown
Source) at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359) at
java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200) at
java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197) at
java.base/java.security.AccessController.doPrivileged(Native Method) at
java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196) at
java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
at java.base/java.security.AccessController.doPrivileged(Native Method) at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:676)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829) stdout: Requested creating
snapshot(s) for [all keyspaces] with snapshot name [some-name] and options
{skipFlush=false}
[jira] [Updated] (CASSANDRA-18949) Test failure: org.apache.cassandra.tools.nodetool.ClearSnapshotTest.testClearSnapshot_RemoveByName-.jdk11.arch=x86_64.python2.7
[
https://issues.apache.org/jira/browse/CASSANDRA-18949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18949:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: CI
Discovered By: Unit Test
Severity: Normal
Status: Open (was: Triage Needed)
> Test failure:
> org.apache.cassandra.tools.nodetool.ClearSnapshotTest.testClearSnapshot_RemoveByName-.jdk11.arch=x86_64.python2.7
> ---
>
> Key: CASSANDRA-18949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18949
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1747/testReport/org.apache.cassandra.tools.nodetool/ClearSnapshotTest/testClearSnapshot_RemoveByName__jdk11_arch_x86_64_python2_7/]
> h3.
> {code:java}
> Error Message
> [bin/nodetool, -p, 36753, -h, 127.0.0.1, snapshot, -t, some-name] exited with
> code 2 stderr: error: Unknown keyspace keyspace_04 -- StackTrace --
> java.lang.AssertionError: Unknown keyspace keyspace_04 at
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324) at
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162) at
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)
> at
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:162) at
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151) at
> com.google.common.collect.Iterators$6.transform(Iterators.java:828) at
> com.google.common.collect.TransformedIterator.next(TransformedIterator.java:52)
> at
> org.apache.cassandra.service.StorageService.takeSnapshot(StorageService.java:4356)
> at
> org.apache.cassandra.service.StorageService.takeSnapshot(StorageService.java:4221)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) at
> jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260) at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at
> java.management/com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:809)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1466)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1399)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:827)
> at java.base/jdk.internal.reflect.GeneratedMethodAccessor16.invoke(Unknown
> Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
> at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200) at
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197) at
> java.base/java.security.AccessController.doPrivileged(Native Method) at
> java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196) at
> java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
> at
>
[jira] [Updated] (CASSANDRA-18949) Test failure: org.apache.cassandra.tools.nodetool.ClearSnapshotTest.testClearSnapshot_RemoveByName-.jdk11.arch=x86_64.python2.7
[
https://issues.apache.org/jira/browse/CASSANDRA-18949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18949:
Fix Version/s: 5.x
> Test failure:
> org.apache.cassandra.tools.nodetool.ClearSnapshotTest.testClearSnapshot_RemoveByName-.jdk11.arch=x86_64.python2.7
> ---
>
> Key: CASSANDRA-18949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18949
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1747/testReport/org.apache.cassandra.tools.nodetool/ClearSnapshotTest/testClearSnapshot_RemoveByName__jdk11_arch_x86_64_python2_7/]
> h3.
> {code:java}
> Error Message
> [bin/nodetool, -p, 36753, -h, 127.0.0.1, snapshot, -t, some-name] exited with
> code 2 stderr: error: Unknown keyspace keyspace_04 -- StackTrace --
> java.lang.AssertionError: Unknown keyspace keyspace_04 at
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324) at
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162) at
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)
> at
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)
> at org.apache.cassandra.db.Keyspace.open(Keyspace.java:162) at
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151) at
> com.google.common.collect.Iterators$6.transform(Iterators.java:828) at
> com.google.common.collect.TransformedIterator.next(TransformedIterator.java:52)
> at
> org.apache.cassandra.service.StorageService.takeSnapshot(StorageService.java:4356)
> at
> org.apache.cassandra.service.StorageService.takeSnapshot(StorageService.java:4221)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) at
> jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> java.base/sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:260) at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> java.management/com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at
> java.management/com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at
> java.management/com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:809)
> at
> java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1466)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1399)
> at
> java.management.rmi/javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:827)
> at java.base/jdk.internal.reflect.GeneratedMethodAccessor16.invoke(Unknown
> Source) at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566) at
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
> at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200) at
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197) at
> java.base/java.security.AccessController.doPrivileged(Native Method) at
> java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196) at
> java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
> at
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
> at
[jira] [Assigned] (CASSANDRA-18945) Unified Compaction Strategy is creating too many sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ethan Brown reassigned CASSANDRA-18945:
---
Assignee: Ethan Brown
> Unified Compaction Strategy is creating too many sstables
> -
>
> Key: CASSANDRA-18945
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18945
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Branimir Lambov
>Assignee: Ethan Brown
>Priority: Normal
>
> The unified compaction strategy currently aims to create sstables with close
> to the same size, defaulting to 1 GiB. Unfortunately tests show that
> Cassandra starts to have performance problems when the number of sstables
> grows to the order of a thousand, and in particular that even 1 TiB of data
> with the default configuration is creating too many sstables for efficient
> processing. This matters even more for SAI, where the number of sstables in
> the system can have a proportional effect on the complexity of operations.
> It is quite easy to create a configuration option that allows sstables to
> take some part of the data growth by adding a multiplier to [the shard count
> calculation|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.md#sharding]
> formula, replacing
> {{2 ^ round(log2(d / (t * b))) * b}}
> with
> {{2 ^ round((1 - 휆) * log2(d / (t * b))) * b}},
> where 휆 is a parameter whose value is between 0 and 1.
> With this, a 휆 of 0.5 would mean that shard count and sstable size grow in
> parallel at the square root of the data size growth. 0 would result in no
> growth, and 1 in always using the same number of shards.
> It may also be valuable to introduce a threshold for engaging the base shard
> count to avoid splitting lowest-level sstables into fragments that are too
> small.
> Once both of these are in place, we can set defaults that better suit all
> node densities, including 10 TiB and beyond, for example:
> - target size of 1 GiB
> - 휆 of 1/3
> - base shard count of 4
> - minimum size 100 MiB
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18948) Test failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
[
https://issues.apache.org/jira/browse/CASSANDRA-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18948:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Test/unit
Discovered By: User Report
Platform: (was: All)
Severity: Normal
Status: Open (was: Triage Needed)
> Test failure:
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
>
> ---
>
> Key: CASSANDRA-18948
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18948
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> Seen here:
> https://ci-cassandra.apache.org/job/Cassandra-5.0/71/testReport/org.apache.cassandra.db.commitlog/CommitLogSegmentManagerCDCTest/testReplayLogic_compression_jdk17_arch_x86_64_python2_7/
> h3.
> {code:java}
> Error Message
> Missing old CDCIndexData in new set after replay:
> CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData in new set of
> indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
> CommitLog-7-1697673230998_cdc.idx,3509214
> Stacktrace
> junit.framework.AssertionFailedError: Missing old CDCIndexData in new set
> after replay: CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData
> in new set of indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
> CommitLog-7-1697673230998_cdc.idx,3509214 at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic(CommitLogSegmentManagerCDCTest.java:319)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18948) Test failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
[
https://issues.apache.org/jira/browse/CASSANDRA-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18948:
Fix Version/s: 5.0.x
> Test failure:
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
>
> ---
>
> Key: CASSANDRA-18948
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18948
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0.x
>
>
> Seen here:
> https://ci-cassandra.apache.org/job/Cassandra-5.0/71/testReport/org.apache.cassandra.db.commitlog/CommitLogSegmentManagerCDCTest/testReplayLogic_compression_jdk17_arch_x86_64_python2_7/
> h3.
> {code:java}
> Error Message
> Missing old CDCIndexData in new set after replay:
> CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData in new set of
> indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
> CommitLog-7-1697673230998_cdc.idx,3509214
> Stacktrace
> junit.framework.AssertionFailedError: Missing old CDCIndexData in new set
> after replay: CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData
> in new set of indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
> CommitLog-7-1697673230998_cdc.idx,3509214 at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic(CommitLogSegmentManagerCDCTest.java:319)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18948) Test failure: org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
Ekaterina Dimitrova created CASSANDRA-18948:
---
Summary: Test failure:
org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic-compression.jdk17.arch=x86_64.python2.7
Key: CASSANDRA-18948
URL: https://issues.apache.org/jira/browse/CASSANDRA-18948
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Seen here:
https://ci-cassandra.apache.org/job/Cassandra-5.0/71/testReport/org.apache.cassandra.db.commitlog/CommitLogSegmentManagerCDCTest/testReplayLogic_compression_jdk17_arch_x86_64_python2_7/
h3.
{code:java}
Error Message
Missing old CDCIndexData in new set after replay:
CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData in new set of
indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
CommitLog-7-1697673230998_cdc.idx,3509214
Stacktrace
junit.framework.AssertionFailedError: Missing old CDCIndexData in new set after
replay: CommitLog-7-1697673230997_cdc.idx,1747785 List of CDCIndexData in new
set of indexes after replay: CommitLog-7-1697673230996_cdc.idx,3510561
CommitLog-7-1697673230998_cdc.idx,3509214 at
org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testReplayLogic(CommitLogSegmentManagerCDCTest.java:319)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18947) Test failure: dtest-novnode.disk_balance_test.TestDiskBalance.test_disk_balance_stress
[
https://issues.apache.org/jira/browse/CASSANDRA-18947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18947:
Fix Version/s: 5.0.x
> Test failure:
> dtest-novnode.disk_balance_test.TestDiskBalance.test_disk_balance_stress
> --
>
> Key: CASSANDRA-18947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18947
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.0.x
>
>
> Seen here:
> https://ci-cassandra.apache.org/job/Cassandra-5.0/72/testReport/dtest-novnode.disk_balance_test/TestDiskBalance/test_disk_balance_stress/
> h3.
> {code:java}
> Error Message
> AssertionError: values not within 10.00% of the max: (2534183, 2762123,
> 2423706) (node1)
> Stacktrace
> self = def
> test_disk_balance_stress(self): cluster = self.cluster if
> self.dtest_config.use_vnodes:
> cluster.set_configuration_options(values={'num_tokens': 256})
> cluster.populate(4).start() node1 = cluster.nodes['node1']
> node1.stress(['write', 'n=50k', 'no-warmup', '-rate', 'threads=100',
> '-schema', 'replication(factor=3)',
> 'compaction(strategy=SizeTieredCompactionStrategy,enabled=false)'])
> cluster.flush() # make sure the data directories are balanced: for node in
> cluster.nodelist(): > self.assert_balanced(node) disk_balance_test.py:48: _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> disk_balance_test.py:186: in assert_balanced assert_almost_equal(*new_sums,
> error=0.1, error_message=node.name) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ args = (2534183, 2762123, 2423706)
> kwargs = {'error': 0.1, 'error_message': 'node1'}, error = 0.1, vmax =
> 2762123 vmin = 2423706, error_message = 'node1' def
> assert_almost_equal(*args, **kwargs): """ Assert variable number of arguments
> all fall within a margin of error. @params *args variable number of numerical
> arguments to check @params error Optional margin of error. Default 0.16
> @params error_message Optional error message to print. Default '' Examples:
> assert_almost_equal(sizes[2], init_size) assert_almost_equal(ttl_session1,
> ttl_session2[0][0], error=0.005) """ error = kwargs['error'] if 'error' in
> kwargs else 0.16 vmax = max(args) vmin = min(args) error_message = '' if
> 'error_message' not in kwargs else kwargs['error_message'] assert vmin > vmax
> * (1.0 - error) or vmin == vmax, \ > "values not within {:.2f}% of the max:
> {} ({})".format(error * 100, args, error_message) E AssertionError: values
> not within 10.00% of the max: (2534183, 2762123, 2423706) (node1)
> tools/assertions.py:206: AssertionError
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18947) Test failure: dtest-novnode.disk_balance_test.TestDiskBalance.test_disk_balance_stress
[
https://issues.apache.org/jira/browse/CASSANDRA-18947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18947:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Test/dtest/python
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test failure:
> dtest-novnode.disk_balance_test.TestDiskBalance.test_disk_balance_stress
> --
>
> Key: CASSANDRA-18947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18947
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> Seen here:
> https://ci-cassandra.apache.org/job/Cassandra-5.0/72/testReport/dtest-novnode.disk_balance_test/TestDiskBalance/test_disk_balance_stress/
> h3.
> {code:java}
> Error Message
> AssertionError: values not within 10.00% of the max: (2534183, 2762123,
> 2423706) (node1)
> Stacktrace
> self = def
> test_disk_balance_stress(self): cluster = self.cluster if
> self.dtest_config.use_vnodes:
> cluster.set_configuration_options(values={'num_tokens': 256})
> cluster.populate(4).start() node1 = cluster.nodes['node1']
> node1.stress(['write', 'n=50k', 'no-warmup', '-rate', 'threads=100',
> '-schema', 'replication(factor=3)',
> 'compaction(strategy=SizeTieredCompactionStrategy,enabled=false)'])
> cluster.flush() # make sure the data directories are balanced: for node in
> cluster.nodelist(): > self.assert_balanced(node) disk_balance_test.py:48: _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> disk_balance_test.py:186: in assert_balanced assert_almost_equal(*new_sums,
> error=0.1, error_message=node.name) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ args = (2534183, 2762123, 2423706)
> kwargs = {'error': 0.1, 'error_message': 'node1'}, error = 0.1, vmax =
> 2762123 vmin = 2423706, error_message = 'node1' def
> assert_almost_equal(*args, **kwargs): """ Assert variable number of arguments
> all fall within a margin of error. @params *args variable number of numerical
> arguments to check @params error Optional margin of error. Default 0.16
> @params error_message Optional error message to print. Default '' Examples:
> assert_almost_equal(sizes[2], init_size) assert_almost_equal(ttl_session1,
> ttl_session2[0][0], error=0.005) """ error = kwargs['error'] if 'error' in
> kwargs else 0.16 vmax = max(args) vmin = min(args) error_message = '' if
> 'error_message' not in kwargs else kwargs['error_message'] assert vmin > vmax
> * (1.0 - error) or vmin == vmax, \ > "values not within {:.2f}% of the max:
> {} ({})".format(error * 100, args, error_message) E AssertionError: values
> not within 10.00% of the max: (2534183, 2762123, 2423706) (node1)
> tools/assertions.py:206: AssertionError
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18947) Test failure: dtest-novnode.disk_balance_test.TestDiskBalance.test_disk_balance_stress
Ekaterina Dimitrova created CASSANDRA-18947:
---
Summary: Test failure:
dtest-novnode.disk_balance_test.TestDiskBalance.test_disk_balance_stress
Key: CASSANDRA-18947
URL: https://issues.apache.org/jira/browse/CASSANDRA-18947
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Seen here:
https://ci-cassandra.apache.org/job/Cassandra-5.0/72/testReport/dtest-novnode.disk_balance_test/TestDiskBalance/test_disk_balance_stress/
h3.
{code:java}
Error Message
AssertionError: values not within 10.00% of the max: (2534183, 2762123,
2423706) (node1)
Stacktrace
self = def
test_disk_balance_stress(self): cluster = self.cluster if
self.dtest_config.use_vnodes:
cluster.set_configuration_options(values={'num_tokens': 256})
cluster.populate(4).start() node1 = cluster.nodes['node1']
node1.stress(['write', 'n=50k', 'no-warmup', '-rate', 'threads=100', '-schema',
'replication(factor=3)',
'compaction(strategy=SizeTieredCompactionStrategy,enabled=false)'])
cluster.flush() # make sure the data directories are balanced: for node in
cluster.nodelist(): > self.assert_balanced(node) disk_balance_test.py:48: _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
disk_balance_test.py:186: in assert_balanced assert_almost_equal(*new_sums,
error=0.1, error_message=node.name) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ args = (2534183, 2762123, 2423706) kwargs =
{'error': 0.1, 'error_message': 'node1'}, error = 0.1, vmax = 2762123 vmin =
2423706, error_message = 'node1' def assert_almost_equal(*args, **kwargs): """
Assert variable number of arguments all fall within a margin of error. @params
*args variable number of numerical arguments to check @params error Optional
margin of error. Default 0.16 @params error_message Optional error message to
print. Default '' Examples: assert_almost_equal(sizes[2], init_size)
assert_almost_equal(ttl_session1, ttl_session2[0][0], error=0.005) """ error =
kwargs['error'] if 'error' in kwargs else 0.16 vmax = max(args) vmin =
min(args) error_message = '' if 'error_message' not in kwargs else
kwargs['error_message'] assert vmin > vmax * (1.0 - error) or vmin == vmax, \ >
"values not within {:.2f}% of the max: {} ({})".format(error * 100, args,
error_message) E AssertionError: values not within 10.00% of the max: (2534183,
2762123, 2423706) (node1) tools/assertions.py:206: AssertionError
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18747) Test failure: Fix assertion error AssertionError: Unknown keyspace system_auth\n\tat org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat org.apache.ca
[
https://issues.apache.org/jira/browse/CASSANDRA-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1863#comment-1863
]
Ekaterina Dimitrova commented on CASSANDRA-18747:
-
{quote}[https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/977/workflows/f6f81939-5b1e-4e17-b756-bfb8791dc23d/jobs/38838/tests]
{quote}
CASSANDRA-18447 - the jamm issue is the same technically... So not related;
{quote}ShortPaxosSimulationTest
{quote}
CASSANDRA-18944
{quote}Additionally, {{LeaveAndBootstrapTest}} turned out to be flaky
{quote}
CASSANDRA-18045, we can post your investigations there so someone can solve the
problem?
> Test failure: Fix assertion error AssertionError: Unknown keyspace
> system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)
> ---
>
> Key: CASSANDRA-18747
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18747
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema, Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.1.4, 5.0-alpha2, 5.0, 5.1
>
> Time Spent: 8h 20m
> Remaining Estimate: 0h
>
> I've been seeing this assertion error in different tests lately.
> Full error message:
> {code:java}
> failed on teardown with "Unexpected error found in node logs (see stdout for
> full details). Errors: [[node2] 'ERROR [PendingRangeCalculator:1] 2023-08-11
> 16:35:14,445 JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']" Unexpected error found in
> node logs (see stdout for full details). Errors: [[node2] 'ERROR
> [PendingRangeCalculator:1] 2023-08-11 16:35:14,445
> JVMStabilityInspector.java:70 - Exception in thread
> Thread[PendingRangeCalculator:1,5,PendingRangeCalculator]\njava.lang.AssertionError:
> Unknown keyspace system_auth\n\tat
> org.apache.cassandra.db.Keyspace.(Keyspace.java:324)\n\tat
> org.apache.cassandra.db.Keyspace.lambda$open$0(Keyspace.java:162)\n\tat
> org.apache.cassandra.utils.concurrent.LoadingMap.blockingLoadIfAbsent(LoadingMap.java:105)\n\tat
>
> org.apache.cassandra.schema.Schema.maybeAddKeyspaceInstance(Schema.java:251)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:162)\n\tat
> org.apache.cassandra.db.Keyspace.open(Keyspace.java:151)\n\tat
> org.apache.cassandra.service.PendingRangeCalculatorService.lambda$new$1(PendingRangeCalculatorService.java:58)\n\tat
>
> org.apache.cassandra.concurrent.SingleThreadExecutorPlus$AtLeastOnce.run(SingleThreadExecutorPlus.java:60)\n\tat
>
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)\n\tat
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)\n\tat
>
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat
> java.base/java.lang.Thread.run(Thread.java:829)']{code}
> Example failures:
> test_failed_snitch_update_property_file_snitch -
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2475/workflows/2086619e-0f21-464b-a866-84aca516b5e5/jobs/36716/tests]
> test_gcgs_validation -
>
[jira] [Updated] (CASSANDRA-17421) Test Failure: org.apache.cassandra.service.LeaveAndBootstrapTest.testSimultaneousMove
[
https://issues.apache.org/jira/browse/CASSANDRA-17421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17421:
Resolution: Duplicate
Status: Resolved (was: Open)
> Test Failure:
> org.apache.cassandra.service.LeaveAndBootstrapTest.testSimultaneousMove
> -
>
> Key: CASSANDRA-17421
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17421
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.0.x, 5.x
>
>
> Branch: 4.0
> https://ci-cassandra.apache.org/job/Cassandra-4.0/350/testReport/org.apache.cassandra.service/LeaveAndBootstrapTest/testSimultaneousMove/
> {code}
> java.lang.NullPointerException
> at
> org.apache.cassandra.service.StorageService.updatePeerInfo(StorageService.java:2440)
> at
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2810)
> at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:2316)
> at
> org.apache.cassandra.service.LeaveAndBootstrapTest.testSimultaneousMove(LeaveAndBootstrapTest.java:354)
> {code}
> Failure: 1 of 15
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18944) Test failure: org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
[
https://issues.apache.org/jira/browse/CASSANDRA-18944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18944:
Complexity: Normal
Severity: Normal
Status: Open (was: Triage Needed)
> Test failure:
> org.apache.cassandra.simulator.test.ShortPaxosSimulationTest.simulationTest
> -
>
> Key: CASSANDRA-18944
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18944
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> The simulator test
> {{org.apache.cassandra.simulator.test.ShortPaxosSimulationTest#simulationTest}}
> is flaky on 5.0 and trunk:
> *
> https://app.circleci.com/pipelines/github/mike-tr-adamson/cassandra/332/workflows/946e28f4-2dec-4384-ac38-de011093f6c6/jobs/25735/tests
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3253/workflows/e48b49e9-cf36-412a-a811-d813031e6f01/jobs/83735/tests
> *
> https://app.circleci.com/pipelines/github/adelapena/cassandra/3254/workflows/69f451ef-fb39-48e4-b1d1-40ee4141b0c1/jobs/83739/tests
> {code}
> org.apache.cassandra.simulator.SimulationException: Failed on seed
> 0xb01206bb3b021127
> Caused by: java.lang.ClassCastException: class
> org.apache.cassandra.net.NoPayload cannot be cast to class
> org.apache.cassandra.gms.GossipShutdown (org.apache.cassandra.net.NoPayload
> and org.apache.cassandra.gms.GossipShutdown are in unnamed module of loader
> org.apache.cassandra.distributed.shared.InstanceClassLoader @68801feb)
> at
> org.apache.cassandra.gms.GossipShutdown$Serializer.serialize(GossipShutdown.java:41)
> at
> org.apache.cassandra.net.Message$Serializer.serialize(Message.java:722)
> at
> org.apache.cassandra.distributed.impl.Instance.serializeMessage(Instance.java:427)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$registerOutboundFilter$5(Instance.java:370)
> at
> org.apache.cassandra.net.OutboundSink$Filtered.accept(OutboundSink.java:54)
> at org.apache.cassandra.net.OutboundSink.accept(OutboundSink.java:70)
> at
> org.apache.cassandra.net.MessagingService.send(MessagingService.java:449)
> at
> org.apache.cassandra.net.MessagingService.send(MessagingService.java:419)
> at
> org.apache.cassandra.gms.Gossiper.unsafeSendShutdown(Gossiper.java:2634)
> at
> org.apache.cassandra.simulator.cluster.OnInstanceSendShutdown.lambda$invokableSendShutdown$1(OnInstanceSendShutdown.java:48)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
> at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> at
> org.apache.cassandra.concurrent.SyncFutureTask$1.call(SyncFutureTask.java:46)
> at
> org.apache.cassandra.concurrent.SyncFutureTask.run(SyncFutureTask.java:68)
> at
> org.apache.cassandra.simulator.systems.InterceptingExecutor$AbstractSingleThreadedExecutorPlus.lambda$new$0(InterceptingExecutor.java:584)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> The test failure can easily be reproduced on CircleCI with:
> {code}
> .circleci/generate.sh -sp \
> -e
> REPEATED_SIMULATOR_DTESTS=org.apache.cassandra.simulator.test.ShortPaxosSimulationTest
> \
> -e REPEATED_SIMULATOR_DTESTS_COUNT=100
> {code}
> Flakiness seems ~18%.
> The test failure is not reported on Butler because simulator tests are not
> run by Jenkins.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18946) Add cqlsh autocompletion for the vector data type
[
https://issues.apache.org/jira/browse/CASSANDRA-18946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxwell Guo updated CASSANDRA-18946:
Change Category: Operability
Complexity: Normal
Fix Version/s: 5.0
5.x
Priority: Low (was: Normal)
Status: Open (was: Triage Needed)
> Add cqlsh autocompletion for the vector data type
> -
>
> Key: CASSANDRA-18946
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18946
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Vector Search
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Low
> Fix For: 5.0, 5.x
>
>
> Add cqlsh autocompletion for the vector data type, so we have completions
> such as:
> {code:java}
> cqlsh> CREATE TABLE t (v
> ascii boolean decimal float int set time tinyint
> varint
> bigintcounter doublefrozenlist smallint timestamp uuid
> vector
> blob date duration inet map text timeuuid varchar
> cqlsh> CREATE TABLE t (v vector<
> ascii blob counter decimal duration inet smallint time
> timeuuid uuid varint
> bigintboolean date doublefloat int text
> timestamp tinyint varchar
> cqlsh> CREATE TABLE t (v vector -
> cqlsh> INSERT INTO t(k, v) VALUES ( 0,
> )>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18710) Test failure: org.apache.cassandra.io.DiskSpaceMetricsTest.testFlushSize-.jdk17 (from org.apache.cassandra.io.DiskSpaceMetricsTest-.jdk17)
[
https://issues.apache.org/jira/browse/CASSANDRA-18710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1851#comment-1851
]
Brandon Williams commented on CASSANDRA-18710:
--
bq. We need to understand what causes these COMMITLOG_DIRTY flushes, because
there are quite a few tests that will fail if a flush happens at the wrong
time. Or maybe somehow disable commitlog-driven flushing for tests (e.g. by
setting a really large commit log space limit).
I remember running into this same situation in CASSANDRA-18706 now, and I think
something in 5.0 must have changed to cause this. I'll see if I can track that
down, but we could also shut the optional tasks executor down since whatever is
triggering the flushes is going through it.
> Test failure:
> org.apache.cassandra.io.DiskSpaceMetricsTest.testFlushSize-.jdk17 (from
> org.apache.cassandra.io.DiskSpaceMetricsTest-.jdk17)
> --
>
> Key: CASSANDRA-18710
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18710
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: org.apache.cassandra.io.DiskSpaceMetricsTest.txt
>
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1644/testReport/org.apache.cassandra.io/DiskSpaceMetricsTest/testFlushSize__jdk17/]
> h3.
> {code:java}
> Error Message
> expected:<7200.0> but was:<1367.83970468544>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<7200.0> but
> was:<1367.83970468544> at
> org.apache.cassandra.io.DiskSpaceMetricsTest.testFlushSize(DiskSpaceMetricsTest.java:119)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18710) Test failure: org.apache.cassandra.io.DiskSpaceMetricsTest.testFlushSize-.jdk17 (from org.apache.cassandra.io.DiskSpaceMetricsTest-.jdk17)
[
https://issues.apache.org/jira/browse/CASSANDRA-18710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1830#comment-1830
]
Branimir Lambov commented on CASSANDRA-18710:
-
It looks like the reason for the unexpected flush is the commit log:
{code:java}
[junit-timeout] INFO [OptionalTasks:1] 2023-10-12 21:55:11,095
ColumnFamilyStore.java:1017 - Enqueuing flush of
cql_test_keyspace_alt.table_01, Reason: COMMITLOG_DIRTY, Usage: 74.752KiB (0%)
on-heap, 3.777KiB (0%) off-heap
[junit-timeout] INFO [PerDiskMemtableFlushWriter_0:2] 2023-10-12 21:55:11,103
Flushing.java:154 - Writing Memtable-table_01@1180822937(6.854KiB serialized
bytes, 242 ops, 74.916KiB (0%) on-heap, 3.781KiB (0%) off-heap), flushed range
= [null, null)
[junit-timeout] INFO [PerDiskMemtableFlushWriter_0:2] 2023-10-12 21:55:11,128
Flushing.java:180 - Completed flushing
/tmp/cassandra/build/test/cassandra/data/cql_test_keyspace_alt/table_01-03e61210694a11eeb4091bdb4ac3170b/nc-1-big-Data.db
(6.839KiB) ... {code}
which is flushing just 242 out of the 1000 ops that the test needs per table.
We need to understand what causes these {{COMMITLOG_DIRTY}} flushes, because
there are quite a few tests that will fail if a flush happens at the wrong
time. Or maybe somehow disable commitlog-driven flushing for tests (e.g. by
setting a really large commit log space limit).
> Test failure:
> org.apache.cassandra.io.DiskSpaceMetricsTest.testFlushSize-.jdk17 (from
> org.apache.cassandra.io.DiskSpaceMetricsTest-.jdk17)
> --
>
> Key: CASSANDRA-18710
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18710
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: org.apache.cassandra.io.DiskSpaceMetricsTest.txt
>
>
> Seen here:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1644/testReport/org.apache.cassandra.io/DiskSpaceMetricsTest/testFlushSize__jdk17/]
> h3.
> {code:java}
> Error Message
> expected:<7200.0> but was:<1367.83970468544>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<7200.0> but
> was:<1367.83970468544> at
> org.apache.cassandra.io.DiskSpaceMetricsTest.testFlushSize(DiskSpaceMetricsTest.java:119)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18891) Cassandra 4.0 - JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-18891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1821#comment-1821 ] Maxim Muzafarov commented on CASSANDRA-18891: - [~brandon.williams] Thanks for the confirmation. So, I think the patch (dependency update) is valuable only for development purposes for the members who are running on Apple M1 to facilitate the running of Cassandra without workarounds. Here is the corresponding thread on Slack: https://the-asf.slack.com/archives/CK23JSY2K/p1696888467711249 > Cassandra 4.0 - JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-18891 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18891 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Thomas Steinmaurer >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.0.x > > Attachments: signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > As discussed on Slack: > [https://the-asf.slack.com/archives/CJZLTM05A/p1684745250901489] > Created this ticket as clone of CASSANDRA-17019, to ask for considering a JNA > library upgrade in Cassandra 4.0, so that we could utilize ARM-based AWS > Gravition instances e.g. m7g already with Cassandra 4.0. > From linked ticket: > "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." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18891) Cassandra 4.0 - JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-18891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1819#comment-1819 ] Brandon Williams commented on CASSANDRA-18891: -- To clarify I actually meant "does 5.6.0 actually work on Graviton m7g machines on linux?" because nobody is going to run macOS there, as you've noted. I don't think it's a case we need to consider. > Cassandra 4.0 - JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-18891 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18891 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Thomas Steinmaurer >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.0.x > > Attachments: signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > As discussed on Slack: > [https://the-asf.slack.com/archives/CJZLTM05A/p1684745250901489] > Created this ticket as clone of CASSANDRA-17019, to ask for considering a JNA > library upgrade in Cassandra 4.0, so that we could utilize ARM-based AWS > Gravition instances e.g. m7g already with Cassandra 4.0. > From linked ticket: > "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." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18946) Add cqlsh autocompletion for the vector data type
Andres de la Peña created CASSANDRA-18946:
-
Summary: Add cqlsh autocompletion for the vector data type
Key: CASSANDRA-18946
URL: https://issues.apache.org/jira/browse/CASSANDRA-18946
Project: Cassandra
Issue Type: New Feature
Components: Feature/Vector Search
Reporter: Andres de la Peña
Assignee: Andres de la Peña
Add cqlsh autocompletion for the vector data type, so we have completions such
as:
{code:java}
cqlsh> CREATE TABLE t (v
ascii boolean decimal float int set time tinyint
varint
bigintcounter doublefrozenlist smallint timestamp uuid
vector
blob date duration inet map text timeuuid varchar
cqlsh> CREATE TABLE t (v vector<
ascii blob counter decimal duration inet smallint time
timeuuid uuid varint
bigintboolean date doublefloat int text timestamp
tinyint varchar
cqlsh> CREATE TABLE t (v vector
cqlsh> INSERT INTO t(k, v) VALUES ( 0,
)>
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18891) Cassandra 4.0 - JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-18891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1811#comment-1811 ] Maxim Muzafarov commented on CASSANDRA-18891: - Unless I'm missing something, here are the OS you can install on the Gravitron machines, and it depends on what OS we are running. https://docs.aws.amazon.com/systems-manager/latest/userguide/operating-systems-and-machine-types.html Basically, Cassandra 4.0.11 with JNA 5.6.0 works on all Linux-like OS on the arm64 platform (I tested it). Cassandra 4.0.11 with JNA 5.6.0 _DOESN'T_ work on macOS (Amazon EC2 instances only) on the arm64 platform. This means that the dependency update up to JNA 5.13.0 will fix the latter case (Gravitron + macOS), but the question here is, is it a production use case for Cassandra? This case is not even mentioned in the "Cassandra Requirements" documentation page as "supported". https://cassandra.apache.org/doc/4.0/cassandra/getting_started/installing.html > Cassandra 4.0 - JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-18891 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18891 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Thomas Steinmaurer >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.0.x > > Attachments: signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > As discussed on Slack: > [https://the-asf.slack.com/archives/CJZLTM05A/p1684745250901489] > Created this ticket as clone of CASSANDRA-17019, to ask for considering a JNA > library upgrade in Cassandra 4.0, so that we could utilize ARM-based AWS > Gravition instances e.g. m7g already with Cassandra 4.0. > From linked ticket: > "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." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18775) Remove libraries in lib/sigar-bin for unsupported architectures
[
https://issues.apache.org/jira/browse/CASSANDRA-18775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1806#comment-1806
]
Michael Semb Wever commented on CASSANDRA-18775:
To nit: the Cassandra project doesn't support any architectures at all – it
maintains a codebase.
That said, folk are working on improving "support" for architectures that we
don't formally maintain. So we cannot remove stuff just because it's not
formally supported. Some examples are PPC64 Big Endian (CASSANDRA-7476), s390x
(CASSANDRA-17723), PPC64 Little Endian (CASSANDRA-7381), sparcv9
(CASSANDRA-6628).
So yes, I see reason not to do this. Removing windows stuff is legit as we
agreed to remove it altogether. And I'm very much in favour of taking the
non-arch-specific approach where/when ever possible (e.g. Brandon's response on
dev@)
> Remove libraries in lib/sigar-bin for unsupported architectures
> ---
>
> Key: CASSANDRA-18775
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18775
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Stefan Miklosovic
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
>
> {code}
> ✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [trunk L|⚑ 49]
> 15:41 $ ls -la lib/sigar-bin/
> total 6376
> drwxrwxr-x 2 fermat fermat 4096 aug 17 11:26 .
> drwxrwxr-x 5 fermat fermat 12288 aug 17 11:28 ..
> -rw-rw-r-- 1 fermat fermat 210641 aug 17 11:26 libsigar-amd64-freebsd-6.so
> -rw-rw-r-- 1 fermat fermat 246605 aug 17 11:26 libsigar-amd64-linux.so
> -rw-rw-r-- 1 fermat fermat 251360 aug 17 11:26 libsigar-amd64-solaris.so
> -rw-rw-r-- 1 fermat fermat 577452 aug 17 11:26 libsigar-ia64-hpux-11.sl
> -rw-rw-r-- 1 fermat fermat 494929 aug 17 11:26 libsigar-ia64-linux.so
> -rw-rw-r-- 1 fermat fermat 516096 aug 17 11:26 libsigar-pa-hpux-11.sl
> -rw-rw-r-- 1 fermat fermat 425077 aug 17 11:26 libsigar-ppc64-aix-5.so
> -rw-rw-r-- 1 fermat fermat 310792 aug 17 11:26 libsigar-ppc64le-linux.so
> -rw-rw-r-- 1 fermat fermat 330767 aug 17 11:26 libsigar-ppc64-linux.so
> -rw-rw-r-- 1 fermat fermat 400925 aug 17 11:26 libsigar-ppc-aix-5.so
> -rw-rw-r-- 1 fermat fermat 258547 aug 17 11:26 libsigar-ppc-linux.so
> -rw-rw-r-- 1 fermat fermat 269932 aug 17 11:26 libsigar-s390x-linux.so
> -rw-rw-r-- 1 fermat fermat 261896 aug 17 11:26 libsigar-sparc64-solaris.so
> -rw-rw-r-- 1 fermat fermat 285004 aug 17 11:26 libsigar-sparc-solaris.so
> -rw-rw-r-- 1 fermat fermat 397440 aug 17 11:26
> libsigar-universal64-macosx.dylib
> -rw-rw-r-- 1 fermat fermat 377668 aug 17 11:26 libsigar-universal-macosx.dylib
> -rw-rw-r-- 1 fermat fermat 179751 aug 17 11:26 libsigar-x86-freebsd-5.so
> -rw-rw-r-- 1 fermat fermat 179379 aug 17 11:26 libsigar-x86-freebsd-6.so
> -rw-rw-r-- 1 fermat fermat 233385 aug 17 11:26 libsigar-x86-linux.so
> -rw-rw-r-- 1 fermat fermat 242880 aug 17 11:26 libsigar-x86-solaris.so
> ✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [trunk L|⚑ 49]
> 15:43 $ du -shc lib/sigar-bin/
> 6,3Mlib/sigar-bin/
> 6,3Mtotal
> {code}
> I think we could definitely improve this. We basically need just x86-linux,
> amd64-linux and two libs for macosx.
> We could save like 5M from the final tarball size. From 75M down to 70M is
> not bad!
> Or maybe I am not getting something and we need this?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18775) Remove libraries in lib/sigar-bin for unsupported architectures
[
https://issues.apache.org/jira/browse/CASSANDRA-18775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1794#comment-1794
]
Claude Warren edited comment on CASSANDRA-18775 at 10/20/23 2:08 PM:
-
I think that preserving any sigar library where the file name contains the word
"linux" or "macosx" should be acceptable. This will preserve:
libsigar-amd64-linux.so
libsigar-ia64-linux.so
libsigar-ppc-linux.so
libsigar-ppc64-linux.so
libsigar-ppc64le-linux.so
libsigar-s390x-linux.so
libsigar-universal-macosx.dylib
libsigar-universal64-macosx.dylib
libsigar-x86-linux.so
and remove:
libsigar-amd64-freebsd-6.so
libsigar-amd64-solaris.so
libsigar-ia64-hpux-11.sl
libsigar-pa-hpux-11.sl
libsigar-ppc-aix-5.so
libsigar-ppc64-aix-5.so
libsigar-sparc-solaris.so
libsigar-sparc64-solaris.so
libsigar-x86-freebsd-5.so
libsigar-x86-freebsd-6.so
libsigar-x86-solaris.so
resulting in a savings of 3530461 bytes out of 6,450,526 from the
/lib/sigar-bin directory, an approximately 50% reduction.
Does anyone see any reason _not_ to do this?
was (Author: claudenw):
I think that preserving any sigar library where the file name contains the word
"linux" or "macosx" should be acceptable. This will preserve:
libsigar-amd64-linux.so
libsigar-ia64-linux.so
libsigar-ppc-linux.so
libsigar-ppc64-linux.so
libsigar-ppc64le-linux.so
libsigar-s390x-linux.so
libsigar-universal-macosx.dylib
libsigar-universal64-macosx.dylib
libsigar-x86-linux.so
and remove:
libsigar-amd64-freebsd-6.solibsigar-amd64-solaris.so
libsigar-ia64-hpux-11.sl
libsigar-pa-hpux-11.sl
libsigar-ppc-aix-5.solibsigar-ppc64-aix-5.so
libsigar-sparc-solaris.so
libsigar-sparc64-solaris.so
libsigar-x86-freebsd-5.so
libsigar-x86-freebsd-6.so
libsigar-x86-solaris.so
resulting in a savings of 3530461 bytes out of 6,450,526 from the
/lib/sigar-bin directory, a 48% reduction.
Does anyone see any reason _not_ to do this?
> Remove libraries in lib/sigar-bin for unsupported architectures
> ---
>
> Key: CASSANDRA-18775
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18775
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Stefan Miklosovic
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
>
> {code}
> ✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [trunk L|⚑ 49]
> 15:41 $ ls -la lib/sigar-bin/
> total 6376
> drwxrwxr-x 2 fermat fermat 4096 aug 17 11:26 .
> drwxrwxr-x 5 fermat fermat 12288 aug 17 11:28 ..
> -rw-rw-r-- 1 fermat fermat 210641 aug 17 11:26 libsigar-amd64-freebsd-6.so
> -rw-rw-r-- 1 fermat fermat 246605 aug 17 11:26 libsigar-amd64-linux.so
> -rw-rw-r-- 1 fermat fermat 251360 aug 17 11:26 libsigar-amd64-solaris.so
> -rw-rw-r-- 1 fermat fermat 577452 aug 17 11:26 libsigar-ia64-hpux-11.sl
> -rw-rw-r-- 1 fermat fermat 494929 aug 17 11:26 libsigar-ia64-linux.so
> -rw-rw-r-- 1 fermat fermat 516096 aug 17 11:26 libsigar-pa-hpux-11.sl
> -rw-rw-r-- 1 fermat fermat 425077 aug 17 11:26 libsigar-ppc64-aix-5.so
> -rw-rw-r-- 1 fermat fermat 310792 aug 17 11:26 libsigar-ppc64le-linux.so
> -rw-rw-r-- 1 fermat fermat 330767 aug 17 11:26 libsigar-ppc64-linux.so
> -rw-rw-r-- 1 fermat fermat 400925 aug 17 11:26 libsigar-ppc-aix-5.so
> -rw-rw-r-- 1 fermat fermat 258547 aug 17 11:26 libsigar-ppc-linux.so
> -rw-rw-r-- 1 fermat fermat 269932 aug 17 11:26 libsigar-s390x-linux.so
> -rw-rw-r-- 1 fermat fermat 261896 aug 17 11:26 libsigar-sparc64-solaris.so
> -rw-rw-r-- 1 fermat fermat 285004 aug 17 11:26 libsigar-sparc-solaris.so
> -rw-rw-r-- 1 fermat fermat 397440 aug 17 11:26
> libsigar-universal64-macosx.dylib
> -rw-rw-r-- 1 fermat fermat 377668 aug 17 11:26 libsigar-universal-macosx.dylib
> -rw-rw-r-- 1 fermat fermat 179751 aug 17 11:26 libsigar-x86-freebsd-5.so
> -rw-rw-r-- 1 fermat fermat 179379 aug 17 11:26 libsigar-x86-freebsd-6.so
> -rw-rw-r-- 1 fermat fermat 233385 aug 17 11:26 libsigar-x86-linux.so
> -rw-rw-r-- 1 fermat fermat 242880 aug 17 11:26 libsigar-x86-solaris.so
> ✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [trunk L|⚑ 49]
> 15:43 $ du -shc lib/sigar-bin/
> 6,3Mlib/sigar-bin/
> 6,3Mtotal
> {code}
> I think we could definitely improve this. We basically need just x86-linux,
> amd64-linux and two libs for macosx.
> We could save like 5M from the final tarball size. From 75M down to 70M is
> not bad!
> Or maybe I am not getting something and we need this?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18775) Remove libraries in lib/sigar-bin for unsupported architectures
[
https://issues.apache.org/jira/browse/CASSANDRA-18775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1794#comment-1794
]
Claude Warren edited comment on CASSANDRA-18775 at 10/20/23 2:06 PM:
-
I think that preserving any sigar library where the file name contains the word
"linux" or "macosx" should be acceptable. This will preserve:
libsigar-amd64-linux.so
libsigar-ia64-linux.so
libsigar-ppc-linux.so
libsigar-ppc64-linux.so
libsigar-ppc64le-linux.so
libsigar-s390x-linux.so
libsigar-universal-macosx.dylib
libsigar-universal64-macosx.dylib
libsigar-x86-linux.so
and remove:
libsigar-amd64-freebsd-6.solibsigar-amd64-solaris.so
libsigar-ia64-hpux-11.sl
libsigar-pa-hpux-11.sl
libsigar-ppc-aix-5.solibsigar-ppc64-aix-5.so
libsigar-sparc-solaris.so
libsigar-sparc64-solaris.so
libsigar-x86-freebsd-5.so
libsigar-x86-freebsd-6.so
libsigar-x86-solaris.so
resulting in a savings of 3530461 bytes out of 6,450,526 from the
/lib/sigar-bin directory, a 48% reduction.
Does anyone see any reason _not_ to do this?
was (Author: claudenw):
I think that preserving any sigar library where the file name contains the word
"linux" or "macosx" should be acceptable. This will preserve:
libsigar-amd64-linux.so
libsigar-ia64-linux.so
libsigar-ppc-linux.so
libsigar-ppc64-aix-5.so
libsigar-ppc64-linux.so
libsigar-ppc64le-linux.so
libsigar-s390x-linux.so
libsigar-universal-macosx.dylib
libsigar-universal64-macosx.dylib
libsigar-x86-linux.so
and remove:
libsigar-amd64-freebsd-6.solibsigar-amd64-solaris.so
libsigar-ia64-hpux-11.sl
libsigar-pa-hpux-11.sl
libsigar-ppc-aix-5.so
libsigar-sparc-solaris.so
libsigar-sparc64-solaris.so
libsigar-x86-freebsd-5.so
libsigar-x86-freebsd-6.so
libsigar-x86-solaris.so
resulting in a savings of 3,105,384 bytes out of 6,450,526 from the
/lib/sigar-bin directory, a 48% reduction.
Does anyone see any reason _not_ to do this?
> Remove libraries in lib/sigar-bin for unsupported architectures
> ---
>
> Key: CASSANDRA-18775
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18775
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Stefan Miklosovic
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
>
> {code}
> ✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [trunk L|⚑ 49]
> 15:41 $ ls -la lib/sigar-bin/
> total 6376
> drwxrwxr-x 2 fermat fermat 4096 aug 17 11:26 .
> drwxrwxr-x 5 fermat fermat 12288 aug 17 11:28 ..
> -rw-rw-r-- 1 fermat fermat 210641 aug 17 11:26 libsigar-amd64-freebsd-6.so
> -rw-rw-r-- 1 fermat fermat 246605 aug 17 11:26 libsigar-amd64-linux.so
> -rw-rw-r-- 1 fermat fermat 251360 aug 17 11:26 libsigar-amd64-solaris.so
> -rw-rw-r-- 1 fermat fermat 577452 aug 17 11:26 libsigar-ia64-hpux-11.sl
> -rw-rw-r-- 1 fermat fermat 494929 aug 17 11:26 libsigar-ia64-linux.so
> -rw-rw-r-- 1 fermat fermat 516096 aug 17 11:26 libsigar-pa-hpux-11.sl
> -rw-rw-r-- 1 fermat fermat 425077 aug 17 11:26 libsigar-ppc64-aix-5.so
> -rw-rw-r-- 1 fermat fermat 310792 aug 17 11:26 libsigar-ppc64le-linux.so
> -rw-rw-r-- 1 fermat fermat 330767 aug 17 11:26 libsigar-ppc64-linux.so
> -rw-rw-r-- 1 fermat fermat 400925 aug 17 11:26 libsigar-ppc-aix-5.so
> -rw-rw-r-- 1 fermat fermat 258547 aug 17 11:26 libsigar-ppc-linux.so
> -rw-rw-r-- 1 fermat fermat 269932 aug 17 11:26 libsigar-s390x-linux.so
> -rw-rw-r-- 1 fermat fermat 261896 aug 17 11:26 libsigar-sparc64-solaris.so
> -rw-rw-r-- 1 fermat fermat 285004 aug 17 11:26 libsigar-sparc-solaris.so
> -rw-rw-r-- 1 fermat fermat 397440 aug 17 11:26
> libsigar-universal64-macosx.dylib
> -rw-rw-r-- 1 fermat fermat 377668 aug 17 11:26 libsigar-universal-macosx.dylib
> -rw-rw-r-- 1 fermat fermat 179751 aug 17 11:26 libsigar-x86-freebsd-5.so
> -rw-rw-r-- 1 fermat fermat 179379 aug 17 11:26 libsigar-x86-freebsd-6.so
> -rw-rw-r-- 1 fermat fermat 233385 aug 17 11:26 libsigar-x86-linux.so
> -rw-rw-r-- 1 fermat fermat 242880 aug 17 11:26 libsigar-x86-solaris.so
> ✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [trunk L|⚑ 49]
> 15:43 $ du -shc lib/sigar-bin/
> 6,3Mlib/sigar-bin/
> 6,3Mtotal
> {code}
> I think we could definitely improve this. We basically need just x86-linux,
> amd64-linux and two libs for macosx.
> We could save like 5M from the final tarball size. From 75M down to 70M is
> not bad!
> Or maybe I am not getting something and we need this?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18775) Remove libraries in lib/sigar-bin for unsupported architectures
[
https://issues.apache.org/jira/browse/CASSANDRA-18775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1794#comment-1794
]
Claude Warren commented on CASSANDRA-18775:
---
I think that preserving any sigar library where the file name contains the word
"linux" or "macosx" should be acceptable. This will preserve:
libsigar-amd64-linux.so
libsigar-ia64-linux.so
libsigar-ppc-linux.so
libsigar-ppc64-aix-5.so
libsigar-ppc64-linux.so
libsigar-ppc64le-linux.so
libsigar-s390x-linux.so
libsigar-universal-macosx.dylib
libsigar-universal64-macosx.dylib
libsigar-x86-linux.so
and remove:
libsigar-amd64-freebsd-6.solibsigar-amd64-solaris.so
libsigar-ia64-hpux-11.sl
libsigar-pa-hpux-11.sl
libsigar-ppc-aix-5.so
libsigar-sparc-solaris.so
libsigar-sparc64-solaris.so
libsigar-x86-freebsd-5.so
libsigar-x86-freebsd-6.so
libsigar-x86-solaris.so
resulting in a savings of 3,105,384 bytes out of 6,450,526 from the
/lib/sigar-bin directory, a 48% reduction.
Does anyone see any reason _not_ to do this?
> Remove libraries in lib/sigar-bin for unsupported architectures
> ---
>
> Key: CASSANDRA-18775
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18775
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Stefan Miklosovic
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
>
> {code}
> ✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [trunk L|⚑ 49]
> 15:41 $ ls -la lib/sigar-bin/
> total 6376
> drwxrwxr-x 2 fermat fermat 4096 aug 17 11:26 .
> drwxrwxr-x 5 fermat fermat 12288 aug 17 11:28 ..
> -rw-rw-r-- 1 fermat fermat 210641 aug 17 11:26 libsigar-amd64-freebsd-6.so
> -rw-rw-r-- 1 fermat fermat 246605 aug 17 11:26 libsigar-amd64-linux.so
> -rw-rw-r-- 1 fermat fermat 251360 aug 17 11:26 libsigar-amd64-solaris.so
> -rw-rw-r-- 1 fermat fermat 577452 aug 17 11:26 libsigar-ia64-hpux-11.sl
> -rw-rw-r-- 1 fermat fermat 494929 aug 17 11:26 libsigar-ia64-linux.so
> -rw-rw-r-- 1 fermat fermat 516096 aug 17 11:26 libsigar-pa-hpux-11.sl
> -rw-rw-r-- 1 fermat fermat 425077 aug 17 11:26 libsigar-ppc64-aix-5.so
> -rw-rw-r-- 1 fermat fermat 310792 aug 17 11:26 libsigar-ppc64le-linux.so
> -rw-rw-r-- 1 fermat fermat 330767 aug 17 11:26 libsigar-ppc64-linux.so
> -rw-rw-r-- 1 fermat fermat 400925 aug 17 11:26 libsigar-ppc-aix-5.so
> -rw-rw-r-- 1 fermat fermat 258547 aug 17 11:26 libsigar-ppc-linux.so
> -rw-rw-r-- 1 fermat fermat 269932 aug 17 11:26 libsigar-s390x-linux.so
> -rw-rw-r-- 1 fermat fermat 261896 aug 17 11:26 libsigar-sparc64-solaris.so
> -rw-rw-r-- 1 fermat fermat 285004 aug 17 11:26 libsigar-sparc-solaris.so
> -rw-rw-r-- 1 fermat fermat 397440 aug 17 11:26
> libsigar-universal64-macosx.dylib
> -rw-rw-r-- 1 fermat fermat 377668 aug 17 11:26 libsigar-universal-macosx.dylib
> -rw-rw-r-- 1 fermat fermat 179751 aug 17 11:26 libsigar-x86-freebsd-5.so
> -rw-rw-r-- 1 fermat fermat 179379 aug 17 11:26 libsigar-x86-freebsd-6.so
> -rw-rw-r-- 1 fermat fermat 233385 aug 17 11:26 libsigar-x86-linux.so
> -rw-rw-r-- 1 fermat fermat 242880 aug 17 11:26 libsigar-x86-solaris.so
> ✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [trunk L|⚑ 49]
> 15:43 $ du -shc lib/sigar-bin/
> 6,3Mlib/sigar-bin/
> 6,3Mtotal
> {code}
> I think we could definitely improve this. We basically need just x86-linux,
> amd64-linux and two libs for macosx.
> We could save like 5M from the final tarball size. From 75M down to 70M is
> not bad!
> Or maybe I am not getting something and we need this?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18891) Cassandra 4.0 - JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-18891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1784#comment-1784 ] Brandon Williams commented on CASSANDRA-18891: -- I see, thanks for the clarification! So it seems the only question is does 5.6.0 actually work on Graviton m7g machines? If the answer is yes, then we'd only gain Darwin support by upgrading here. > Cassandra 4.0 - JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-18891 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18891 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Thomas Steinmaurer >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.0.x > > Attachments: signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > As discussed on Slack: > [https://the-asf.slack.com/archives/CJZLTM05A/p1684745250901489] > Created this ticket as clone of CASSANDRA-17019, to ask for considering a JNA > library upgrade in Cassandra 4.0, so that we could utilize ARM-based AWS > Gravition instances e.g. m7g already with Cassandra 4.0. > From linked ticket: > "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." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18891) Cassandra 4.0 - JNA 5.6.0 does not support arm64
[
https://issues.apache.org/jira/browse/CASSANDRA-18891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1734#comment-1734
]
Maxim Muzafarov edited comment on CASSANDRA-18891 at 10/20/23 1:40 PM:
---
Hey, [~tsteinmaurer]
I've done some testing/CI and can now confirm that the 4.0.11 release only
fails for Apple M1 (Darwin) when running natively, but for the supported OS on
the arm64 the release works fine. I doubt anyone is running Cassandra on a
Darwin kernel in production environments, aren't they? JNA actually supports a
wide variety of platforms, which is mentioned below, so Cassandra does too:
[java-native-access -
Makefile|https://raw.githubusercontent.com/java-native-access/jna/master/native/Makefile]
There's no mention of the Darwin kernel in the Cassandra documentation for the
4.0.11 release, so it looks like the behaviour mentioned by you is correct,
right?
[Getting started with
Cassandra|https://cassandra.apache.org/doc/4.0/cassandra/getting_started/installing.html]
Cassandra is actually available for the arm64 platform, here are Docker images
for it. I've tested this image locally with the 4.0.11 and it runs and works
fine:
[https://hub.docker.com/r/arm64v8/cassandra/]
One other point, which is worth mentioning here is that I have run CI for the
4.0.11 release (some of the off-heap dtests) and it also passed successfully on
cassandra-arm Jenkins agents, which seems to be the case we've been discussing
for a while:
[Cassandra-4.0-dtest-offheap-arm64|https://ci-cassandra.apache.org/view/Cassandra%204.0/job/Cassandra-4.0-dtest-offheap-arm64/],
the patch CI
[Cassandra-devbranch-dtest-offheap-arm64|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest-offheap-arm64/]
I did some local testing of the 4.0.11 release on my local virtual environments:
- (passed) Linux fedora-linux-38 6.5.7-200.fc38.aarch64 #1 aarch64 GNU/Linux
- (failed) Darwin Maxims-MacBook.local Darwin Kernel Version 22.6.0: arm64
{code:java}
java.lang.UnsatisfiedLinkError: Can't load library:
/Users/m/Library/Caches/JNA/temp/jna3019109962359550762.tmp
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2638)
at java.base/java.lang.Runtime.load0(Runtime.java:768)
at java.base/java.lang.System.load(System.java:1850)
at
com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1018)
at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:988)
at com.sun.jna.Native.(Native.java:195)
at com.sun.jna.NativeLibrary.(NativeLibrary.java:87)
at
org.apache.cassandra.utils.NativeLibraryDarwin.(NativeLibraryDarwin.java:56)
at
org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:100)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:258)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
{code}
Instead of a conclusion, I think we can fix the dependency, but it's clearly
not a production case. Wdyt?
The patch is here:
https://github.com/apache/cassandra/pull/2767
was (Author: mmuzaf):
Hey, [~tsteinmaurer]
I've done some testing/CI and can now confirm that the 4.0.11 release only
fails for Apple M1 (Darwin) when running natively, but for the supported OS on
the arm64 the release works fine. I doubt anyone is running Cassandra on a
Darwin kernel in production environments, aren't they? JNA actually supports a
wide variety of platforms, which is mentioned below, so Cassandra does too:
[java-native-access -
Makefile|https://raw.githubusercontent.com/java-native-access/jna/master/native/Makefile]
There's no mention of the Darwin kernel in the Cassandra documentation for the
4.0 release, so it looks like the behaviour mentioned by you is correct, right?
[Getting started with
Cassandra|https://cassandra.apache.org/doc/4.0/cassandra/getting_started/installing.html]
Cassandra is actually available for the arm64 platform, here are Docker images
for it. I've tested this image locally with the 4.0.11 and it runs and works
fine:
[https://hub.docker.com/r/arm64v8/cassandra/]
One other point, which is worth mentioning here is that I have run CI for the
4.0 release (some of the off-heap dtests) and it also passed successfully on
cassandra-arm Jenkins agents, which seems to be the case we've been discussing
for a while:
[Cassandra-4.0-dtest-offheap-arm64|https://ci-cassandra.apache.org/view/Cassandra%204.0/job/Cassandra-4.0-dtest-offheap-arm64/],
the patch CI
[Cassandra-devbranch-dtest-offheap-arm64|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest-offheap-arm64/]
I did some local testing of the 4.0.11 release on my local virtual environments:
- (passed) Linux fedora-linux-38
[jira] [Comment Edited] (CASSANDRA-18891) Cassandra 4.0 - JNA 5.6.0 does not support arm64
[
https://issues.apache.org/jira/browse/CASSANDRA-18891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1734#comment-1734
]
Maxim Muzafarov edited comment on CASSANDRA-18891 at 10/20/23 1:39 PM:
---
Hey, [~tsteinmaurer]
I've done some testing/CI and can now confirm that the 4.0.11 release only
fails for Apple M1 (Darwin) when running natively, but for the supported OS on
the arm64 the release works fine. I doubt anyone is running Cassandra on a
Darwin kernel in production environments, aren't they? JNA actually supports a
wide variety of platforms, which is mentioned below, so Cassandra does too:
[java-native-access -
Makefile|https://raw.githubusercontent.com/java-native-access/jna/master/native/Makefile]
There's no mention of the Darwin kernel in the Cassandra documentation for the
4.0 release, so it looks like the behaviour mentioned by you is correct, right?
[Getting started with
Cassandra|https://cassandra.apache.org/doc/4.0/cassandra/getting_started/installing.html]
Cassandra is actually available for the arm64 platform, here are Docker images
for it. I've tested this image locally with the 4.0.11 and it runs and works
fine:
[https://hub.docker.com/r/arm64v8/cassandra/]
One other point, which is worth mentioning here is that I have run CI for the
4.0 release (some of the off-heap dtests) and it also passed successfully on
cassandra-arm Jenkins agents, which seems to be the case we've been discussing
for a while:
[Cassandra-4.0-dtest-offheap-arm64|https://ci-cassandra.apache.org/view/Cassandra%204.0/job/Cassandra-4.0-dtest-offheap-arm64/],
the patch CI
[Cassandra-devbranch-dtest-offheap-arm64|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest-offheap-arm64/]
I did some local testing of the 4.0.11 release on my local virtual environments:
- (passed) Linux fedora-linux-38 6.5.7-200.fc38.aarch64 #1 aarch64 GNU/Linux
- (failed) Darwin Maxims-MacBook.local Darwin Kernel Version 22.6.0: arm64
{code:java}
java.lang.UnsatisfiedLinkError: Can't load library:
/Users/m/Library/Caches/JNA/temp/jna3019109962359550762.tmp
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2638)
at java.base/java.lang.Runtime.load0(Runtime.java:768)
at java.base/java.lang.System.load(System.java:1850)
at
com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1018)
at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:988)
at com.sun.jna.Native.(Native.java:195)
at com.sun.jna.NativeLibrary.(NativeLibrary.java:87)
at
org.apache.cassandra.utils.NativeLibraryDarwin.(NativeLibraryDarwin.java:56)
at
org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:100)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:258)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
{code}
Instead of a conclusion, I think we can fix the dependency, but it's clearly
not a production case. Wdyt?
The patch is here:
https://github.com/apache/cassandra/pull/2767
was (Author: mmuzaf):
Hey, [~tsteinmaurer]
I've done some testing/CI and can now confirm that the 4.0 release only fails
for Apple M1 (Darwin) when running natively, but for the supported OS on the
arm64 the release works fine. I doubt anyone is running Cassandra on a Darwin
kernel in production environments, aren't they? JNA actually supports a wide
variety of platforms, which is mentioned below, so Cassandra does too:
[java-native-access -
Makefile|https://raw.githubusercontent.com/java-native-access/jna/master/native/Makefile]
There's no mention of the Darwin kernel in the Cassandra documentation for the
4.0 release, so it looks like the behaviour mentioned by you is correct, right?
[Getting started with
Cassandra|https://cassandra.apache.org/doc/4.0/cassandra/getting_started/installing.html]
Cassandra is actually available for the arm64 platform, here are Docker images
for it. I've tested this image locally with the 4.0.11 and it runs and works
fine:
[https://hub.docker.com/r/arm64v8/cassandra/]
One other point, which is worth mentioning here is that I have run CI for the
4.0 release (some of the off-heap dtests) and it also passed successfully on
cassandra-arm Jenkins agents, which seems to be the case we've been discussing
for a while:
[Cassandra-4.0-dtest-offheap-arm64|https://ci-cassandra.apache.org/view/Cassandra%204.0/job/Cassandra-4.0-dtest-offheap-arm64/],
the patch CI
[Cassandra-devbranch-dtest-offheap-arm64|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest-offheap-arm64/]
I did some local testing of the 4.0.11 release on my local virtual environments:
- (passed) Linux fedora-linux-38
[jira] [Comment Edited] (CASSANDRA-18891) Cassandra 4.0 - JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-18891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1778#comment-1778 ] Maxim Muzafarov edited comment on CASSANDRA-18891 at 10/20/23 1:39 PM: --- Sorry, for the misunderstanding, I should have been clearer :-) I have been testing the 4.0.11 release (the latest now available) which doesn't include the patch I provided and all the tests and my report accordingly were based on that release. Updating the JNA dependency up to 5.13.0 fixes the problem I've had locally with running a node on the Darwin kernel. was (Author: mmuzaf): Sorry, for the misunderstanding, I should have been clearer :-) I have been testing the 4.0.11 release (the latest now available) which doesn't include the patch I provided and all the tests and my report accordingly were based on that release. Updating the JNA dependency up to 5.13.0 fixes all the problems I've had locally with running a node on the Darwin kernel. > Cassandra 4.0 - JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-18891 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18891 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Thomas Steinmaurer >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.0.x > > Attachments: signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > As discussed on Slack: > [https://the-asf.slack.com/archives/CJZLTM05A/p1684745250901489] > Created this ticket as clone of CASSANDRA-17019, to ask for considering a JNA > library upgrade in Cassandra 4.0, so that we could utilize ARM-based AWS > Gravition instances e.g. m7g already with Cassandra 4.0. > From linked ticket: > "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." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18891) Cassandra 4.0 - JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-18891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1778#comment-1778 ] Maxim Muzafarov commented on CASSANDRA-18891: - Sorry, for the misunderstanding, I should have been clearer :-) I have been testing the 4.0.11 release (the latest now available) which doesn't include the patch I provided and all the tests and my report accordingly were based on that release. Updating the JNA dependency up to 5.13.0 fixes all the problems I've had locally with running a node on the Darwin kernel. > Cassandra 4.0 - JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-18891 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18891 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Thomas Steinmaurer >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.0.x > > Attachments: signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > As discussed on Slack: > [https://the-asf.slack.com/archives/CJZLTM05A/p1684745250901489] > Created this ticket as clone of CASSANDRA-17019, to ask for considering a JNA > library upgrade in Cassandra 4.0, so that we could utilize ARM-based AWS > Gravition instances e.g. m7g already with Cassandra 4.0. > From linked ticket: > "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." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18891) Cassandra 4.0 - JNA 5.6.0 does not support arm64
[
https://issues.apache.org/jira/browse/CASSANDRA-18891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1734#comment-1734
]
Maxim Muzafarov edited comment on CASSANDRA-18891 at 10/20/23 1:33 PM:
---
Hey, [~tsteinmaurer]
I've done some testing/CI and can now confirm that the 4.0 release only fails
for Apple M1 (Darwin) when running natively, but for the supported OS on the
arm64 the release works fine. I doubt anyone is running Cassandra on a Darwin
kernel in production environments, aren't they? JNA actually supports a wide
variety of platforms, which is mentioned below, so Cassandra does too:
[java-native-access -
Makefile|https://raw.githubusercontent.com/java-native-access/jna/master/native/Makefile]
There's no mention of the Darwin kernel in the Cassandra documentation for the
4.0 release, so it looks like the behaviour mentioned by you is correct, right?
[Getting started with
Cassandra|https://cassandra.apache.org/doc/4.0/cassandra/getting_started/installing.html]
Cassandra is actually available for the arm64 platform, here are Docker images
for it. I've tested this image locally with the 4.0.11 and it runs and works
fine:
[https://hub.docker.com/r/arm64v8/cassandra/]
One other point, which is worth mentioning here is that I have run CI for the
4.0 release (some of the off-heap dtests) and it also passed successfully on
cassandra-arm Jenkins agents, which seems to be the case we've been discussing
for a while:
[Cassandra-4.0-dtest-offheap-arm64|https://ci-cassandra.apache.org/view/Cassandra%204.0/job/Cassandra-4.0-dtest-offheap-arm64/],
the patch CI
[Cassandra-devbranch-dtest-offheap-arm64|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest-offheap-arm64/]
I did some local testing of the 4.0.11 release on my local virtual environments:
- (passed) Linux fedora-linux-38 6.5.7-200.fc38.aarch64 #1 aarch64 GNU/Linux
- (failed) Darwin Maxims-MacBook.local Darwin Kernel Version 22.6.0: arm64
{code:java}
java.lang.UnsatisfiedLinkError: Can't load library:
/Users/m/Library/Caches/JNA/temp/jna3019109962359550762.tmp
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2638)
at java.base/java.lang.Runtime.load0(Runtime.java:768)
at java.base/java.lang.System.load(System.java:1850)
at
com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1018)
at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:988)
at com.sun.jna.Native.(Native.java:195)
at com.sun.jna.NativeLibrary.(NativeLibrary.java:87)
at
org.apache.cassandra.utils.NativeLibraryDarwin.(NativeLibraryDarwin.java:56)
at
org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:100)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:258)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
{code}
Instead of a conclusion, I think we can fix the dependency, but it's clearly
not a production case. Wdyt?
The patch is here:
https://github.com/apache/cassandra/pull/2767
was (Author: mmuzaf):
Hey, [~tsteinmaurer]
I've done some testing/CI and can now confirm that the 4.0 release only fails
for Apple M1 (Darwin) when running natively, but for the supported OS on the
arm64 the release works fine. I doubt anyone is running Cassandra on a Darwin
kernel in production environments, aren't they? JNA actually supports a wide
variety of platforms, which is mentioned below, so Cassandra does too:
[java-native-access -
Makefile|https://raw.githubusercontent.com/java-native-access/jna/master/native/Makefile]
There's no mention of the Darwin kernel in the Cassandra documentation for the
4.0 release, so it looks like the behaviour mentioned by you is correct, right?
[Getting started with
Cassandra|https://cassandra.apache.org/doc/4.0/cassandra/getting_started/installing.html]
Cassandra is actually available for the arm64 platform, here are Docker images
for it. I've tested this image locally with the 4.0.11 and it runs and works
fine:
[https://hub.docker.com/r/arm64v8/cassandra/]
One other point, which is worth mentioning here is that I have run CI for the
4.0 release (some of the off-heap dtests) and it also passed successfully on
cassandra-arm Jenkins agents, which seems to be the case we've been discussing
for a while:
[Cassandra-4.0-dtest-offheap-arm64|https://ci-cassandra.apache.org/view/Cassandra%204.0/job/Cassandra-4.0-dtest-offheap-arm64/],
the patch CI
[Cassandra-devbranch-dtest-offheap-arm64|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest-offheap-arm64/]
I did some local testing of the 4.0 release on my local virtual environments:
- (passed) Linux fedora-linux-38 6.5.7-200.fc38.aarch64
[jira] [Commented] (CASSANDRA-18891) Cassandra 4.0 - JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-18891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1775#comment-1775 ] Brandon Williams commented on CASSANDRA-18891: -- I think I must be misunderstanding something here, were you not referring to 5.13.0 results when you said it failed? > Cassandra 4.0 - JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-18891 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18891 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Thomas Steinmaurer >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.0.x > > Attachments: signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > As discussed on Slack: > [https://the-asf.slack.com/archives/CJZLTM05A/p1684745250901489] > Created this ticket as clone of CASSANDRA-17019, to ask for considering a JNA > library upgrade in Cassandra 4.0, so that we could utilize ARM-based AWS > Gravition instances e.g. m7g already with Cassandra 4.0. > From linked ticket: > "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." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18891) Cassandra 4.0 - JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-18891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1772#comment-1772 ] Maxim Muzafarov commented on CASSANDRA-18891: - Yes, of course. The patch (the 5.13.0 update) fixes the problem with running a node on the Darwin kernel. > Cassandra 4.0 - JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-18891 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18891 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Thomas Steinmaurer >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.0.x > > Attachments: signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > As discussed on Slack: > [https://the-asf.slack.com/archives/CJZLTM05A/p1684745250901489] > Created this ticket as clone of CASSANDRA-17019, to ask for considering a JNA > library upgrade in Cassandra 4.0, so that we could utilize ARM-based AWS > Gravition instances e.g. m7g already with Cassandra 4.0. > From linked ticket: > "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." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18891) Cassandra 4.0 - JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-18891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1769#comment-1769 ] Brandon Williams commented on CASSANDRA-18891: -- 5.13 should have it too then? > Cassandra 4.0 - JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-18891 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18891 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Thomas Steinmaurer >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.0.x > > Attachments: signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > As discussed on Slack: > [https://the-asf.slack.com/archives/CJZLTM05A/p1684745250901489] > Created this ticket as clone of CASSANDRA-17019, to ask for considering a JNA > library upgrade in Cassandra 4.0, so that we could utilize ARM-based AWS > Gravition instances e.g. m7g already with Cassandra 4.0. > From linked ticket: > "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." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18891) Cassandra 4.0 - JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-18891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1769#comment-1769 ] Brandon Williams edited comment on CASSANDRA-18891 at 10/20/23 1:28 PM: 5.13.0 should have it too then? was (Author: brandon.williams): 5.13 should have it too then? > Cassandra 4.0 - JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-18891 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18891 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Thomas Steinmaurer >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.0.x > > Attachments: signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > As discussed on Slack: > [https://the-asf.slack.com/archives/CJZLTM05A/p1684745250901489] > Created this ticket as clone of CASSANDRA-17019, to ask for considering a JNA > library upgrade in Cassandra 4.0, so that we could utilize ARM-based AWS > Gravition instances e.g. m7g already with Cassandra 4.0. > From linked ticket: > "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." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18891) Cassandra 4.0 - JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-18891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1768#comment-1768 ] Maxim Muzafarov commented on CASSANDRA-18891: - They added it only in 5.7.0, no? https://github.com/java-native-access/jna/blob/master/CHANGES.md#features-7 > Cassandra 4.0 - JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-18891 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18891 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Thomas Steinmaurer >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.0.x > > Attachments: signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > As discussed on Slack: > [https://the-asf.slack.com/archives/CJZLTM05A/p1684745250901489] > Created this ticket as clone of CASSANDRA-17019, to ask for considering a JNA > library upgrade in Cassandra 4.0, so that we could utilize ARM-based AWS > Gravition instances e.g. m7g already with Cassandra 4.0. > From linked ticket: > "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." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18891) Cassandra 4.0 - JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-18891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1764#comment-1764 ] Brandon Williams commented on CASSANDRA-18891: -- bq. (failed) Darwin Maxims-MacBook.local Darwin Kernel Version 22.6.0: arm64 This seems a bit odd to me, since from my understanding of the JNA release notes, 64 bit Darwin should work. Is there any more to the exception about why it can't be loaded? > Cassandra 4.0 - JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-18891 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18891 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Thomas Steinmaurer >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.0.x > > Attachments: signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > As discussed on Slack: > [https://the-asf.slack.com/archives/CJZLTM05A/p1684745250901489] > Created this ticket as clone of CASSANDRA-17019, to ask for considering a JNA > library upgrade in Cassandra 4.0, so that we could utilize ARM-based AWS > Gravition instances e.g. m7g already with Cassandra 4.0. > From linked ticket: > "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." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18891) Cassandra 4.0 - JNA 5.6.0 does not support arm64
[ https://issues.apache.org/jira/browse/CASSANDRA-18891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-18891: Status: Patch Available (was: In Progress) > Cassandra 4.0 - JNA 5.6.0 does not support arm64 > > > Key: CASSANDRA-18891 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18891 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Thomas Steinmaurer >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.0.x > > Attachments: signature.asc > > Time Spent: 10m > Remaining Estimate: 0h > > As discussed on Slack: > [https://the-asf.slack.com/archives/CJZLTM05A/p1684745250901489] > Created this ticket as clone of CASSANDRA-17019, to ask for considering a JNA > library upgrade in Cassandra 4.0, so that we could utilize ARM-based AWS > Gravition instances e.g. m7g already with Cassandra 4.0. > From linked ticket: > "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." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18891) Cassandra 4.0 - JNA 5.6.0 does not support arm64
[
https://issues.apache.org/jira/browse/CASSANDRA-18891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1734#comment-1734
]
Maxim Muzafarov commented on CASSANDRA-18891:
-
Hey, [~tsteinmaurer]
I've done some testing/CI and can now confirm that the 4.0 release only fails
for Apple M1 (Darwin) when running natively, but for the supported OS on the
arm64 the release works fine. I doubt anyone is running Cassandra on a Darwin
kernel in production environments, aren't they? JNA actually supports a wide
variety of platforms, which is mentioned below, so Cassandra does too:
[java-native-access -
Makefile|https://raw.githubusercontent.com/java-native-access/jna/master/native/Makefile]
There's no mention of the Darwin kernel in the Cassandra documentation for the
4.0 release, so it looks like the behaviour mentioned by you is correct, right?
[Getting started with
Cassandra|https://cassandra.apache.org/doc/4.0/cassandra/getting_started/installing.html]
Cassandra is actually available for the arm64 platform, here are Docker images
for it. I've tested this image locally with the 4.0.11 and it runs and works
fine:
[https://hub.docker.com/r/arm64v8/cassandra/]
One other point, which is worth mentioning here is that I have run CI for the
4.0 release (some of the off-heap dtests) and it also passed successfully on
cassandra-arm Jenkins agents, which seems to be the case we've been discussing
for a while:
[Cassandra-4.0-dtest-offheap-arm64|https://ci-cassandra.apache.org/view/Cassandra%204.0/job/Cassandra-4.0-dtest-offheap-arm64/],
the patch CI
[Cassandra-devbranch-dtest-offheap-arm64|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest-offheap-arm64/]
I did some local testing of the 4.0 release on my local virtual environments:
- (passed) Linux fedora-linux-38 6.5.7-200.fc38.aarch64 #1 aarch64 GNU/Linux
- (failed) Darwin Maxims-MacBook.local Darwin Kernel Version 22.6.0: arm64
{code:java}
java.lang.UnsatisfiedLinkError: Can't load library:
/Users/m/Library/Caches/JNA/temp/jna3019109962359550762.tmp
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2638)
at java.base/java.lang.Runtime.load0(Runtime.java:768)
at java.base/java.lang.System.load(System.java:1850)
at
com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1018)
at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:988)
at com.sun.jna.Native.(Native.java:195)
at com.sun.jna.NativeLibrary.(NativeLibrary.java:87)
at
org.apache.cassandra.utils.NativeLibraryDarwin.(NativeLibraryDarwin.java:56)
at
org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:100)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:258)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:765)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:889)
{code}
Instead of a conclusion, I think we can fix the dependency, but it's clearly
not a production case. Wdyt?
The patch is here:
https://github.com/apache/cassandra/pull/2767
> Cassandra 4.0 - JNA 5.6.0 does not support arm64
>
>
> Key: CASSANDRA-18891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18891
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Thomas Steinmaurer
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: signature.asc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As discussed on Slack:
> [https://the-asf.slack.com/archives/CJZLTM05A/p1684745250901489]
> Created this ticket as clone of CASSANDRA-17019, to ask for considering a JNA
> library upgrade in Cassandra 4.0, so that we could utilize ARM-based AWS
> Gravition instances e.g. m7g already with Cassandra 4.0.
> From linked ticket:
> "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."
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18945) Unified Compaction Strategy is creating too many sstables
Branimir Lambov created CASSANDRA-18945:
---
Summary: Unified Compaction Strategy is creating too many sstables
Key: CASSANDRA-18945
URL: https://issues.apache.org/jira/browse/CASSANDRA-18945
Project: Cassandra
Issue Type: Bug
Components: Local/Compaction
Reporter: Branimir Lambov
The unified compaction strategy currently aims to create sstables with close to
the same size, defaulting to 1 GiB. Unfortunately tests show that Cassandra
starts to have performance problems when the number of sstables grows to the
order of a thousand, and in particular that even 1 TiB of data with the default
configuration is creating too many sstables for efficient processing. This
matters even more for SAI, where the number of sstables in the system can have
a proportional effect on the complexity of operations.
It is quite easy to create a configuration option that allows sstables to take
some part of the data growth by adding a multiplier to [the shard count
calculation|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.md#sharding]
formula, replacing
{{2 ^ round(log2(d / (t * b))) * b}}
with
{{2 ^ round((1 - 휆) * log2(d / (t * b))) * b}},
where 휆 is a parameter whose value is between 0 and 1.
With this, a 휆 of 0.5 would mean that shard count and sstable size grow in
parallel at the square root of the data size growth. 0 would result in no
growth, and 1 in always using the same number of shards.
It may also be valuable to introduce a threshold for engaging the base shard
count to avoid splitting lowest-level sstables into fragments that are too
small.
Once both of these are in place, we can set defaults that better suit all node
densities, including 10 TiB and beyond, for example:
- target size of 1 GiB
- 휆 of 1/3
- base shard count of 4
- minimum size 100 MiB
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-77) Upgrade vertx to version 4.4.6
[ https://issues.apache.org/jira/browse/CASSANDRASC-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1728#comment-1728 ] Francisco Guerrero commented on CASSANDRASC-77: --- CI: https://app.circleci.com/pipelines/github/frankgh/cassandra-sidecar?branch=CASSANDRASC-77 > Upgrade vertx to version 4.4.6 > -- > > Key: CASSANDRASC-77 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-77 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > Vertx 4.4.6 brings new features that we want to bring into Cassandra Sidecar: > 1. Hot reloading of SSL Certificates. With this feature, we can run Cassandra > Sidecar with TLS options configured, and when the certificate is expired, we > can instruct vertx to reload the certificate from disk without having to > restart the process. > 2. Traffic shaping options. This allows to introduce protections for the > service by providing ways to configure ingress/egress limits for the service, > as well as ingress limits for SSTable uploads. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-78) Fix token-ranges endpoint to handle gossip-info responses without 'status'
[
https://issues.apache.org/jira/browse/CASSANDRASC-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1727#comment-1727
]
Francisco Guerrero commented on CASSANDRASC-78:
---
+1 (nb) Looks good to me
> Fix token-ranges endpoint to handle gossip-info responses without 'status'
> --
>
> Key: CASSANDRASC-78
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-78
> Project: Sidecar for Apache Cassandra
> Issue Type: Bug
> Components: Rest API
>Reporter: Arjun Ashok
>Assignee: Arjun Ashok
>Priority: Normal
> Labels: pull-request-available
>
> This is a fix to look for the host status in ‘Status’ and ‘StatusWithPort’
> attributes in GossipInfo response to determine the ‘state’ of the node.
> Currently, we only check for ‘status’ which can be missing from gossipInfo in
> some cases, which will result in a replacement node status to be reported as
> `Joining` instead of `Replacing`.
> eg.
> {code:java}
> Found gossipInfoEntry={generation=1697736379,
> schema=6d6abc83-a600-35a4-8bbe-fe5edca6a63b, rack=rack1, heartbeat=119,
> releaseVersion=4.1.4-SNAPSHOT, hostId=--4000-8000-0006,
> nativeAddressAndPort=127.0.0.6:9042, load=76459.0,
> internalAddressAndPort=127.0.0.6:7012, sstableVersions=big-nb,
> tokens=, dc=datacenter1, netVersion=12,
> statusWithPort=BOOT_REPLACE,127.0.0.5:7012}{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18932) Harry-found CorruptSSTableException / RT Closer issue when reading entire partition
[
https://issues.apache.org/jira/browse/CASSANDRA-18932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-18932:
Fix Version/s: 5.x
> Harry-found CorruptSSTableException / RT Closer issue when reading entire
> partition
> ---
>
> Key: CASSANDRA-18932
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18932
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Alex Petrov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: node1_.zip, operation.log.zip
>
>
> While testing some new machinery for Harry, I have encountered a new RT
> closer / SSTable Corruption issue. I have grounds to believe this was
> introduced during the last year.
> Issue seems to happen because of intricate interleaving of flushes with
> writes and deletes.
> {code:java}
> ERROR [ReadStage-2] 2023-10-16 18:47:06,696 JVMStabilityInspector.java:76 -
> Exception in thread Thread[ReadStage-2,5,SharedPool]
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> RandomAccessReader:BufferManagingRebufferer.Aligned:CompressedChunkReader.Mmap(/Users/ifesdjeen/foss/java/apache-cassandra-4.0/data/data1/harry/table_1-07c35a606c0a11eeae7a4f6ca489eb0c/nc-5-big-Data.db
> - LZ4Compressor, chunk length 16384, data length 232569)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator$AbstractReader.hasNext(AbstractSSTableIterator.java:381)
> at
> org.apache.cassandra.io.sstable.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:242)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:376)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:188)
> at
> org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:157)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:534)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:402)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:95)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:151)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:101)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:86)
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:343)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:201)
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:186)
> at
> org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:48)
> at
> org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:346)
> at
> org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:2186)
> at
> org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2581)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$2.run(ExecutionFailure.java:163)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
> at
>
[jira] [Updated] (CASSANDRA-18943) http/2 vulnerability: CVE-2023-44487
[ https://issues.apache.org/jira/browse/CASSANDRA-18943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18943: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > http/2 vulnerability: CVE-2023-44487 > > > Key: CASSANDRA-18943 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18943 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > https://nvd.nist.gov/vuln/detail/CVE-2023-44487 > Basically anything using http/2 is covered by this, but we don't use it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18921) Describe statement may include inconsistent schema and schema version for paging
[
https://issues.apache.org/jira/browse/CASSANDRA-18921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1699#comment-1699
]
Jacek Lewandowski commented on CASSANDRA-18921:
---
ping [~e.dimitrova] / [~blerer] - I've rebased all branches after merging
CASSANDRA-18747, now it uses cleaner approach (note that although the test is
initially added to demonstrate the problem, after applying the fix, the test
makes no sense any longer, so it is removed in the other commit)
> Describe statement may include inconsistent schema and schema version for
> paging
>
>
> Key: CASSANDRA-18921
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18921
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.1
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> When the {{DescribeStatement}} is executed, it initially gets the current
> schema snapshot and the schema version with two separate unsynchronized
> calls. When the schema is being modified around that time, the schema
> snapshot and schema version may diverge which will result in failing or
> inconsistent paging. This is not super important but it is easy to fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16360) CRC32 is inefficient on x86
[ https://issues.apache.org/jira/browse/CASSANDRA-16360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-16360: Impacts: (was: Clients) > CRC32 is inefficient on x86 > --- > > Key: CASSANDRA-16360 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16360 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client, Messaging/Internode >Reporter: Avi Kivity >Assignee: Maxim Muzafarov >Priority: Normal > Labels: protocolv6 > Fix For: 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > The client/server protocol specifies CRC24 and CRC32 as the checksum > algorithm (cql_protocol_V5_framing.asc). Those however are expensive to > compute; this affects both the client and the server. > > A better checksum algorithm is CRC32C, which has hardware support on x86 (as > well as other modern architectures). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16360) CRC32 is inefficient on x86
[ https://issues.apache.org/jira/browse/CASSANDRA-16360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-16360: Complexity: Challenging (was: Normal) > CRC32 is inefficient on x86 > --- > > Key: CASSANDRA-16360 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16360 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client, Messaging/Internode >Reporter: Avi Kivity >Assignee: Maxim Muzafarov >Priority: Normal > Labels: protocolv6 > Fix For: 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > The client/server protocol specifies CRC24 and CRC32 as the checksum > algorithm (cql_protocol_V5_framing.asc). Those however are expensive to > compute; this affects both the client and the server. > > A better checksum algorithm is CRC32C, which has hardware support on x86 (as > well as other modern architectures). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16360) CRC32 is inefficient on x86
[ https://issues.apache.org/jira/browse/CASSANDRA-16360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-16360: Component/s: Messaging/Internode > CRC32 is inefficient on x86 > --- > > Key: CASSANDRA-16360 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16360 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client, Messaging/Internode >Reporter: Avi Kivity >Assignee: Maxim Muzafarov >Priority: Normal > Labels: protocolv6 > Fix For: 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > The client/server protocol specifies CRC24 and CRC32 as the checksum > algorithm (cql_protocol_V5_framing.asc). Those however are expensive to > compute; this affects both the client and the server. > > A better checksum algorithm is CRC32C, which has hardware support on x86 (as > well as other modern architectures). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18145) Run entire Cassandra Jenkins in an independent GKE account
[ https://issues.apache.org/jira/browse/CASSANDRA-18145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18145: --- Authors: Nishant Barola, Richa Mishra (was: Michael Semb Wever) > Run entire Cassandra Jenkins in an independent GKE account > -- > > Key: CASSANDRA-18145 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18145 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Henrik Ingo >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > > This exercise will help clarify whether the flakiness we're seeing in ASF CI > is due to the heterogenous execution environment (hardware), or due to the > configuration environment / runtime / DSL / etc (software). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18145) Run entire Cassandra Jenkins in an independent GKE account
[ https://issues.apache.org/jira/browse/CASSANDRA-18145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1669#comment-1669 ] Michael Semb Wever commented on CASSANDRA-18145: Updated wip: https://github.com/infracloudio/cassandra/compare/infracloud/cassandra-5.0...thelastpickle:cassandra:mck/infracloud/infracloud/cassandra-5.0/spinner_gke_clones_plus This work will be squashed into one PR (it's currently spread over two fork+branches). It is also based on 18594. > Run entire Cassandra Jenkins in an independent GKE account > -- > > Key: CASSANDRA-18145 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18145 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Henrik Ingo >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > > This exercise will help clarify whether the flakiness we're seeing in ASF CI > is due to the heterogenous execution environment (hardware), or due to the > configuration environment / runtime / DSL / etc (software). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18145) Run entire Cassandra Jenkins in an independent GKE account
[ https://issues.apache.org/jira/browse/CASSANDRA-18145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763338#comment-17763338 ] Michael Semb Wever edited comment on CASSANDRA-18145 at 10/20/23 9:41 AM: -- Working with [~richamishra006] and [~nbarola] (InfraCloud) on the patch. Work in progress can be found here: https://github.com/infracloudio/cassandra/tree/infracloud/cassandra-5.0 Previously an announcement was made to the Jenkins user groups about the initiative starting: - https://groups.google.com/g/jenkinsci-users/c/cDFAbOSrkbs/m/CubeOxAECQAJ?utm_medium=email_source=footer - https://community.jenkins.io/t/help-and-input-needed-repeatable-k8s-based-ci-for-apache-cassandra/8855?u=mck was (Author: michaelsembwever): Working with Richa and Nishant (InfraCloud) on the patch. Work in progress can be found here: https://github.com/infracloudio/cassandra/tree/infracloud/cassandra-5.0 Previously an announcement was made to the Jenkins user groups about the initiative starting: - https://groups.google.com/g/jenkinsci-users/c/cDFAbOSrkbs/m/CubeOxAECQAJ?utm_medium=email_source=footer - https://community.jenkins.io/t/help-and-input-needed-repeatable-k8s-based-ci-for-apache-cassandra/8855?u=mck > Run entire Cassandra Jenkins in an independent GKE account > -- > > Key: CASSANDRA-18145 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18145 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Henrik Ingo >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0.x, 5.x > > > This exercise will help clarify whether the flakiness we're seeing in ASF CI > is due to the heterogenous execution environment (hardware), or due to the > configuration environment / runtime / DSL / etc (software). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18836) Replace CRC32 w/ CRC32C in IndexFileUtils.ChecksummingWriter
[ https://issues.apache.org/jira/browse/CASSANDRA-18836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1643#comment-1643 ] Maxim Muzafarov commented on CASSANDRA-18836: - [~maedhroz] [~jasonstack] thank you for the review. I've reviewed the test results above and it outlines that I forgot to fix the assertion check in tests as the log output was slightly updated. The new results are below: 5.0: https://github.com/apache/cassandra/pull/2782 https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/453/workflows/472779e6-d904-4f19-b920-789f91225073 trunk: https://github.com/apache/cassandra/pull/2687 https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/450/workflows/51f51b0f-4d4a-4d08-a503-10249e6423fa > Replace CRC32 w/ CRC32C in IndexFileUtils.ChecksummingWriter > > > Key: CASSANDRA-18836 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18836 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index, Feature/SAI >Reporter: Caleb Rackliffe >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.0-alpha2, 5.x > > Time Spent: 5h > Remaining Estimate: 0h > > It seems that now we're on Java 11 for 5.0, there isn't much reason not to > use CRC32C as a drop-in replacement for CRC32. SAI isn't even released, so > has no binary compatibility entanglements, and this should be pretty > straightforward. > See https://github.com/apache/bookkeeper/pull/3309 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cep-21-tcm updated: Use pinned Harry version
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a commit to branch cep-21-tcm
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cep-21-tcm by this push:
new 97bf0f167b Use pinned Harry version
97bf0f167b is described below
commit 97bf0f167b0ef4b0d4492b62472b455d8f6d0a4a
Author: Alex Petrov
AuthorDate: Thu Oct 19 14:47:29 2023 +0200
Use pinned Harry version
---
.build/build-resolver.xml | 4
.build/parent-pom-template.xml| 5 +++--
lib/harry-0.0.2-internal-20221121.14211-2.jar | Bin 435204 -> 0 bytes
lib/harry-core-0.0.2-CASSANDRA-18768.jar | Bin 0 -> 458194 bytes
4 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/.build/build-resolver.xml b/.build/build-resolver.xml
index b5509da443..889dc11bde 100644
--- a/.build/build-resolver.xml
+++ b/.build/build-resolver.xml
@@ -267,6 +267,10 @@
+
+
+
+
diff --git a/.build/parent-pom-template.xml b/.build/parent-pom-template.xml
index 49878c3a42..eb9c86e65f 100644
--- a/.build/parent-pom-template.xml
+++ b/.build/parent-pom-template.xml
@@ -522,8 +522,9 @@
org.apache.cassandra
harry-core
-0.0.2-SNAPSHOT
-test
+harry-core-0.0.2-CASSANDRA-18768
+system
+
${test.lib}/harry-core-0.0.2-CASSANDRA-18768.jar
org.reflections
diff --git a/lib/harry-0.0.2-internal-20221121.14211-2.jar
b/lib/harry-0.0.2-internal-20221121.14211-2.jar
deleted file mode 100644
index 44bf1be4a3..00
Binary files a/lib/harry-0.0.2-internal-20221121.14211-2.jar and /dev/null
differ
diff --git a/lib/harry-core-0.0.2-CASSANDRA-18768.jar
b/lib/harry-core-0.0.2-CASSANDRA-18768.jar
new file mode 100644
index 00..292db01f06
Binary files /dev/null and b/lib/harry-core-0.0.2-CASSANDRA-18768.jar differ
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (3ab78488e -> e732d7888)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 3ab78488e generate docs for 1d0135e5 new e732d7888 generate docs for 1d0135e5 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (3ab78488e) \ N -- N -- N refs/heads/asf-staging (e732d7888) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4881412 -> 4881412 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (4747f3c3f -> 3ab78488e)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 4747f3c3f generate docs for 1d0135e5 new 3ab78488e generate docs for 1d0135e5 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (4747f3c3f) \ N -- N -- N refs/heads/asf-staging (3ab78488e) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4881412 -> 4881412 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
