[jira] [Commented] (CASSANDRA-18464) Enable Direct I/O For CommitLog Files
[ https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778885#comment-17778885 ] Maxwell Guo commented on CASSANDRA-18464: - Thanks for your reply [~brandon.williams]， I may not expressed it clearly, I have saw [commit log uts|https://github.com/apache/cassandra/tree/trunk/test/unit/org/apache/cassandra/db/commitlog] and some stress tests for commit log too. What I mean is that ,how to make sure the direct io flag takes effect ? Besides, I think we may also need to add some stress tests too. But looking at the pr's conservations , some questions for me have been resolved. :) > Enable Direct I/O For CommitLog Files > - > > Key: CASSANDRA-18464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18464 > Project: Cassandra > Issue Type: New Feature > Components: Local/Commit Log >Reporter: Josh McKenzie >Assignee: Amit Pawar >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CommitLogStressTest.patch, > EnableDirectIOForCommitLogUsingNativeAPI.patch, > PeriodicCommitLogStressTest.tar.bz2, SetCommitLogFileSize.patch, > UseDirectIOFeatureForCommitLogFiles.patch, image-2023-06-29-01-12-49-382.png > > > Relocating from [dev@ email > thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg] > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-22 and link to the thread is given > below. > [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n] > Basically, two solutions looked possible to improve the CommitLog I/O. > # Multi-threaded syncing > # Using Direct-IO through JNA > I worked on 2nd option considering the following benefit compared to the > first one > # Direct I/O read/write throughput is very high compared to non-Direct I/O. > Learnt through FIO benchmarking. > # Reduces kernel file cache uses which in-turn reduces kernel I/O activity > for Commitlog files only. > # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < > 30% for Commitlog syncer thread with Direct I/O feature > # Direct I/O implementation is easier compared to multi-threaded > As per the community suggestion, less in code complex is good to have. Direct > I/O enablement looked promising but there was one issue. > Java version 8 does not have native support to enable Direct I/O. So, JNA > library usage is must. The same implementation should also work across other > versions of Java (like 11 and beyond). > I have completed Direct I/O implementation and summary of the attached patch > changes are given below. > # This implementation is not using Java file channels and file is opened > through JNA to use Direct I/O feature. > # New Segment are defined named “DirectIOSegment” for Direct I/O and > “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose > only). > # JNA write call is used to flush the changes. > # New helper functions are defined in NativeLibrary.java and platform > specific file. Currently tested on Linux only. > # Patch allows user to configure optimum block size and alignment if > default values are not OK for CommitLog disk. > # Following configuration options are provided in Cassandra.yaml file > a. use_jna_for_commitlog_io : to use jna feature > b. use_direct_io_for_commitlog : to use Direct I/O feature. > c. direct_io_minimum_block_alignment: 512 (default) > d. nvme_disk_block_size: 32MiB (default and can be changed as per the > required size) > Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark > was tested. It works with both Java 8 and 11 versions. Compressed and > Encrypted based segments are not supported yet and it can be enabled later > based on the Community feedback. > Following improvement are seen with Direct I/O enablement. > # 32 cores >= ~15% > # 64 cores >= ~80% > Also, another observation would like to share here. Reading Commitlog files > with Direct I/O might help in reducing node bring-up time after the node > crash. > Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07 > The attached patch enables Direct I/O feature for Commitlog files. Please > check and share your feedback. -- 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-77) Upgrade vertx to version 4.4.6 to bring hot reloading and traffic shaping options
[ https://issues.apache.org/jira/browse/CASSANDRASC-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-77: - Fix Version/s: 1.0 Source Control Link: https://github.com/apache/cassandra-sidecar/commit/8045f8eedad4510ecbf66bb739d464eec741aced Resolution: Fixed Status: Resolved (was: Ready to Commit) > Upgrade vertx to version 4.4.6 to bring hot reloading and traffic shaping > options > - > > 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 > Fix For: 1.0 > > > 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-77) Upgrade vertx to version 4.4.6 to bring hot reloading and traffic shaping options
[ https://issues.apache.org/jira/browse/CASSANDRASC-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778870#comment-17778870 ] ASF subversion and git services commented on CASSANDRASC-77: Commit 8045f8eedad4510ecbf66bb739d464eec741aced in cassandra-sidecar's branch refs/heads/trunk from Francisco Guerrero [ https://gitbox.apache.org/repos/asf?p=cassandra-sidecar.git;h=8045f8e ] CASSANDRASC-77: Upgrade vertx to version 4.4.6 to bring hot reloading and traffic shaping options Vertx 4.4.6 brings two features that we integrate into Sidecar. 1. Hot reloading of SSL certificates. This allows a running cluster to reload certificates without having to restart the service. 2. Traffic shaping options. This allows to introduce protections for the service. It allows configuring ingress/egress limits. Additionally, this patch introduces the SidecarServerEvents messaging. It leverages vertx's EventBus to publish and consume messages when server starts, server stops, on CQL connection ready, or CQL disconnection, and when all CQL connections are ready. Patch by Francisco Guerrero; Reviewed by Dinesh Joshi, Yifan Cai for CASSANDRASC-77 > Upgrade vertx to version 4.4.6 to bring hot reloading and traffic shaping > options > - > > 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] [Updated] (CASSANDRASC-77) Upgrade vertx to version 4.4.6 to bring hot reloading and traffic shaping options
[ https://issues.apache.org/jira/browse/CASSANDRASC-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-77: - Status: Ready to Commit (was: Review In Progress) > Upgrade vertx to version 4.4.6 to bring hot reloading and traffic shaping > options > - > > 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] [Updated] (CASSANDRASC-77) Upgrade vertx to version 4.4.6 to bring hot reloading and traffic shaping options
[ https://issues.apache.org/jira/browse/CASSANDRASC-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-77: - Reviewers: Dinesh Joshi, Yifan Cai Status: Review In Progress (was: Patch Available) > Upgrade vertx to version 4.4.6 to bring hot reloading and traffic shaping > options > - > > 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] [Comment Edited] (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=17778842#comment-17778842 ] Dinesh Joshi edited comment on CASSANDRASC-77 at 10/23/23 10:30 PM: [~frankgh] could you please retitle this Jira since it is bringing new features to the sidecar in addition as a consequence of upgrading vert.x. +1, thanks for the patch! was (Author: djoshi3): +1, thanks for the patch! > 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] [Updated] (CASSANDRASC-77) Upgrade vertx to version 4.4.6 to bring hot reloading and traffic shaping options
[ https://issues.apache.org/jira/browse/CASSANDRASC-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRASC-77: -- Summary: Upgrade vertx to version 4.4.6 to bring hot reloading and traffic shaping options (was: Upgrade vertx to version 4.4.6) > Upgrade vertx to version 4.4.6 to bring hot reloading and traffic shaping > options > - > > 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-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=17778842#comment-17778842 ] Dinesh Joshi commented on CASSANDRASC-77: - +1, thanks for the patch! > 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] (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=17778837#comment-17778837 ] David Capwell commented on CASSANDRA-18952: --- bq. Looks like you raised these two PRs against the 5.0 branch, its only 1 PR and its for review. Once the review is close to done I will create a trunk version as well; keeping 2 in-sync is easier to get wrong IMO. bq. Do we need to write tests for these metrics? if people want I can add... I see them update in the existing tests; doesn't mean they won't break later on... > 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: 1h 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
[cassandra-website] branch asf-staging updated (3940349bb -> 616f25e81)
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 3940349bb generate docs for 207dbf1f new 616f25e81 generate docs for 207dbf1f 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 (3940349bb) \ N -- N -- N refs/heads/asf-staging (616f25e81) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4881412 -> 4881412 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (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:all-tabpanel
]
Yifan Cai updated CASSANDRASC-78:
-
Reviewers: Francisco Guerrero, Yifan Cai (was: Francisco Guerrero, Yifan
Cai, Yifan Cai)
> 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] (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:all-tabpanel
]
Yifan Cai updated CASSANDRASC-78:
-
Reviewers: Francisco Guerrero, Yifan Cai, Yifan Cai
Status: Review In Progress (was: Patch Available)
> 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] [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=17778823#comment-17778823
]
Arjun Ashok commented on CASSANDRASC-78:
CI:
https://app.circleci.com/pipelines/github/arjunashok/cassandra-sidecar/66/workflows/8ea22382-9f51-4535-bf40-c1bf49ae7f78
> 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] (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:all-tabpanel
]
Arjun Ashok updated CASSANDRASC-78:
---
Authors: Arjun Ashok
Test and Documentation Plan: Validated fix in unit tests and in-jvm-dtests
Status: Patch Available (was: In Progress)
> 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] [Comment Edited] (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=17778792#comment-17778792
]
Brandon Williams edited comment on CASSANDRA-18710 at 10/23/23 7:14 PM:
Dropping a CF eventually leads to CFS.onTableDropped, which then [force
recycles|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L3379]
the commit log segments, which leads to our flushes with COMMITLOG_DIRTY.
This was added in CASSANDRA-17071 which is in 4.1, though.
was (Author: brandon.williams):
Dropping a CF eventually leads to CFS.onDropped, which then [force
recycles|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L3379]
the commit log segments, which leads to our flushes with COMMITLOG_DIRTY.
This was added in CASSANDRA-17071 which is in 4.1, though.
> 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] [Comment Edited] (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=17778792#comment-17778792
]
Brandon Williams edited comment on CASSANDRA-18710 at 10/23/23 7:11 PM:
Dropping a CF eventually leads to CFS.onDropped, which then [force
recycles|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L3379]
the commit log segments, which leads to our flushes with COMMITLOG_DIRTY.
This was added in CASSANDRA-17071 which is in 4.1, though.
was (Author: brandon.williams):
Dropping a CF eventually leads to CFS.onDropped, which then [force
recycles|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L3379]
the commit log segments, which leads to our flushes with COMMITLOG_DIRTY.
> 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=17778792#comment-17778792
]
Brandon Williams commented on CASSANDRA-18710:
--
Dropping a CF eventually leads to CFS.onDropped, which then [force
recycles|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L3379]
the commit log segments, which leads to our flushes with COMMITLOG_DIRTY.
> 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] (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=17778791#comment-17778791
]
Yifan Cai commented on CASSANDRASC-78:
--
+1 to the patch with green CI run. Please include the CI link.
> 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
[cassandra-website] branch asf-staging updated (971f3cc9b -> 3940349bb)
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 971f3cc9b generate docs for 207dbf1f new 3940349bb generate docs for 207dbf1f 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 (971f3cc9b) \ N -- N -- N refs/heads/asf-staging (3940349bb) 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 (e422614e4 -> 971f3cc9b)
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 e422614e4 generate docs for dddbfce3 add 207dbf1f8 add glossary terms new 971f3cc9b generate docs for 207dbf1f 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 (e422614e4) \ N -- N -- N refs/heads/asf-staging (971f3cc9b) 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/_/glossary.html| 1220 ++-- .../managing/tools/nodetool/upgradesstables.html |3 +- .../managing/tools/nodetool/upgradesstables.html |3 +- content/search-index.js|2 +- .../source/modules/ROOT/pages/glossary.adoc| 430 ++- .../modules/ROOT/partials/a-nearest-neighbor.adoc |3 + .../source/modules/ROOT/partials/alphabet-nav.adoc |1 + .../source/modules/ROOT/partials/anti-entropy.adoc |3 + .../modules/ROOT/partials/authentication.adoc |3 + .../modules/ROOT/partials/authorization.adoc |3 + .../modules/ROOT/partials/back-pressure.adoc |3 + .../source/modules/ROOT/partials/bloom-filter.adoc |3 + .../source/modules/ROOT/partials/bootstrap.adoc|3 + .../source/modules/ROOT/partials/cardinality.adoc |8 + .../source/modules/ROOT/partials/cell.adoc |4 + .../source/modules/ROOT/partials/cluster.adoc |3 + .../modules/ROOT/partials/clustering-column.adoc |6 + .../source/modules/ROOT/partials/clustering.adoc |3 + .../modules/ROOT/partials/coalescing-strategy.adoc |4 + .../modules/ROOT/partials/column-family.adoc |4 + .../source/modules/ROOT/partials/column.adoc |4 + .../source/modules/ROOT/partials/commit-log.adoc |3 + .../source/modules/ROOT/partials/compaction.adoc |9 + .../ROOT/partials/composite-partition-key.adoc |3 + .../ROOT/partials/compound-primary-key.adoc|3 + .../modules/ROOT/partials/consistency-level.adoc |3 + .../source/modules/ROOT/partials/consistency.adoc |4 + .../modules/ROOT/partials/coordinator-node.adoc|3 + .../modules/ROOT/partials/cosine-similarity.adoc |3 + .../source/modules/ROOT/partials/cqlsh.adoc|3 + .../partials/cross-data-center-forwarding.adoc |4 + .../source/modules/ROOT/partials/data-type.adoc|3 + .../source/modules/ROOT/partials/datacenter.adoc |5 + .../modules/ROOT/partials/denormalization.adoc |4 + .../source/modules/ROOT/partials/ebnf.adoc |5 + .../source/modules/ROOT/partials/embeddings.adoc |3 + .../modules/ROOT/partials/euclidean-distance.adoc |3 + .../ROOT/partials/eventual-consistency.adoc|5 + .../modules/ROOT/partials/garbage-collector.adoc |4 + .../source/modules/ROOT/partials/gossip.adoc |3 + site-content/source/modules/ROOT/partials/hdd.adoc |4 + .../source/modules/ROOT/partials/hdfs.adoc |4 + .../source/modules/ROOT/partials/headroom.adoc |3 + .../source/modules/ROOT/partials/hint.adoc |3 + .../source/modules/ROOT/partials/idempotent.adoc |3 + .../source/modules/ROOT/partials/immutable.adoc|3 + .../source/modules/ROOT/partials/index.adoc|3 + .../modules/ROOT/partials/jaccard-similarity.adoc |3 + .../source/modules/ROOT/partials/keyspace.adoc |3 + site-content/source/modules/ROOT/partials/lcs.adoc |8 + .../ROOT/partials/linearizable-consistency.adoc|8 + .../modules/ROOT/partials/listen-address.adoc |3 + .../modules/ROOT/partials/machine-learning.adoc|3 + .../source/modules/ROOT/partials/mapreduce.adoc|4 + .../modules/ROOT/partials/materialized-view.adoc |4 + .../source/modules/ROOT/partials/memtable.adoc |3 + .../source/modules/ROOT/partials/mutation.adoc |3 + .../ROOT/partials/natural-language-processing.adoc |3 + .../source/modules/ROOT/partials/node-repair.adoc |3 + .../source/modules/ROOT/partials/node.adoc |3 +
[jira] [Commented] (CASSANDRA-18604) Write docs for CEP-30 Vector Search
[ https://issues.apache.org/jira/browse/CASSANDRA-18604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778774#comment-17778774 ] Michael Semb Wever commented on CASSANDRA-18604: Committed https://github.com/apache/cassandra-website/commit/207dbf1f831d50daa3b0b35caa348d3e9423959a (for https://github.com/apache/cassandra-website/pull/247 ) > Write docs for CEP-30 Vector Search > --- > > Key: CASSANDRA-18604 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18604 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: Normal > > Write docs for Vector search. -- 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-18923) BLOG - Apache Cassandra 5.0 Features: Dynamic Data Masking
[ https://issues.apache.org/jira/browse/CASSANDRA-18923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18923: --- Fix Version/s: NA Source Control Link: https://github.com/apache/cassandra-website/commit/327f02f610b9e7b664a316ac7c29754550b17095 Resolution: Fixed Status: Resolved (was: Ready to Commit) > BLOG - Apache Cassandra 5.0 Features: Dynamic Data Masking > -- > > Key: CASSANDRA-18923 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18923 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Fix For: NA > > > This ticket is to capture the work associated with publishing the blog > "Apache Cassandra 5.0 Features: Dynamic Data Masking" > This blog can be published as soon as possible, but if it cannot be published > within a week of the noted publish date *(October 11)*, please contact me, > suggest changes, or correct the date when possible in the pull request for > the appropriate time that the blog will go live (on both the blog.adoc and > the blog post's file). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: add glossary terms
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 207dbf1f8 add glossary terms 207dbf1f8 is described below commit 207dbf1f831d50daa3b0b35caa348d3e9423959a Author: Lorina Poland AuthorDate: Tue Oct 17 15:37:58 2023 -0700 add glossary terms patch by Lorina Poland; reviewed by Mick Semb Wever for CASSANDRA-18604 --- .../source/modules/ROOT/pages/glossary.adoc| 430 +++-- .../modules/ROOT/partials/a-nearest-neighbor.adoc | 3 + .../source/modules/ROOT/partials/alphabet-nav.adoc | 1 + .../source/modules/ROOT/partials/anti-entropy.adoc | 3 + .../modules/ROOT/partials/authentication.adoc | 3 + .../modules/ROOT/partials/authorization.adoc | 3 + .../modules/ROOT/partials/back-pressure.adoc | 3 + .../source/modules/ROOT/partials/bloom-filter.adoc | 3 + .../source/modules/ROOT/partials/bootstrap.adoc| 3 + .../source/modules/ROOT/partials/cardinality.adoc | 8 + .../source/modules/ROOT/partials/cell.adoc | 4 + .../source/modules/ROOT/partials/cluster.adoc | 3 + .../modules/ROOT/partials/clustering-column.adoc | 6 + .../source/modules/ROOT/partials/clustering.adoc | 3 + .../modules/ROOT/partials/coalescing-strategy.adoc | 4 + .../modules/ROOT/partials/column-family.adoc | 4 + .../source/modules/ROOT/partials/column.adoc | 4 + .../source/modules/ROOT/partials/commit-log.adoc | 3 + .../source/modules/ROOT/partials/compaction.adoc | 9 + .../ROOT/partials/composite-partition-key.adoc | 3 + .../ROOT/partials/compound-primary-key.adoc| 3 + .../modules/ROOT/partials/consistency-level.adoc | 3 + .../source/modules/ROOT/partials/consistency.adoc | 4 + .../modules/ROOT/partials/coordinator-node.adoc| 3 + .../modules/ROOT/partials/cosine-similarity.adoc | 3 + .../source/modules/ROOT/partials/cqlsh.adoc| 3 + .../partials/cross-data-center-forwarding.adoc | 4 + .../source/modules/ROOT/partials/data-type.adoc| 3 + .../source/modules/ROOT/partials/datacenter.adoc | 5 + .../modules/ROOT/partials/denormalization.adoc | 4 + .../source/modules/ROOT/partials/ebnf.adoc | 5 + .../source/modules/ROOT/partials/embeddings.adoc | 3 + .../modules/ROOT/partials/euclidean-distance.adoc | 3 + .../ROOT/partials/eventual-consistency.adoc| 5 + .../modules/ROOT/partials/garbage-collector.adoc | 4 + .../source/modules/ROOT/partials/gossip.adoc | 3 + site-content/source/modules/ROOT/partials/hdd.adoc | 4 + .../source/modules/ROOT/partials/hdfs.adoc | 4 + .../source/modules/ROOT/partials/headroom.adoc | 3 + .../source/modules/ROOT/partials/hint.adoc | 3 + .../source/modules/ROOT/partials/idempotent.adoc | 3 + .../source/modules/ROOT/partials/immutable.adoc| 3 + .../source/modules/ROOT/partials/index.adoc| 3 + .../modules/ROOT/partials/jaccard-similarity.adoc | 3 + .../source/modules/ROOT/partials/keyspace.adoc | 3 + site-content/source/modules/ROOT/partials/lcs.adoc | 8 + .../ROOT/partials/linearizable-consistency.adoc| 8 + .../modules/ROOT/partials/listen-address.adoc | 3 + .../modules/ROOT/partials/machine-learning.adoc| 3 + .../source/modules/ROOT/partials/mapreduce.adoc| 4 + .../modules/ROOT/partials/materialized-view.adoc | 4 + .../source/modules/ROOT/partials/memtable.adoc | 3 + .../source/modules/ROOT/partials/mutation.adoc | 3 + .../ROOT/partials/natural-language-processing.adoc | 3 + .../source/modules/ROOT/partials/node-repair.adoc | 3 + .../source/modules/ROOT/partials/node.adoc | 3 + .../modules/ROOT/partials/normalization.adoc | 4 + .../source/modules/ROOT/partials/oltp.adoc | 3 + .../modules/ROOT/partials/partition-index.adoc | 3 + .../modules/ROOT/partials/partition-key.adoc | 6 + .../modules/ROOT/partials/partition-range.adoc | 4 + .../modules/ROOT/partials/partition-summary.adoc | 4 + .../source/modules/ROOT/partials/partition.adoc| 5 + .../source/modules/ROOT/partials/partitioner.adoc | 4 + .../source/modules/ROOT/partials/primary-key.adoc | 3 + .../modules/ROOT/partials/range-movement.adoc | 3 + .../source/modules/ROOT/partials/read-repair.adoc | 3 + .../ROOT/partials/replica-placement-strategy.adoc | 3 + .../source/modules/ROOT/partials/replica.adoc | 3 + .../modules/ROOT/partials/replication-factor.adoc | 8 + .../modules/ROOT/partials/replication-group.adoc | 3 + .../source/modules/ROOT/partials/role.adoc | 4 + .../modules/ROOT/partials/rolling-restart.adoc | 4 + .../source/modules/ROOT/partials/row-cache.adoc| 11
[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
]
Brandon Williams updated CASSANDRA-18946:
-
Status: Ready to Commit (was: Review In Progress)
> 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
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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 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
> 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-18946) Add cqlsh autocompletion for the vector data type
[
https://issues.apache.org/jira/browse/CASSANDRA-18946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778769#comment-17778769
]
Brandon Williams commented on CASSANDRA-18946:
--
I see you've already got CASSANDRA-18944 open for ShortPaxosSimulationTest and
the rest lgtm, +1.
> 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
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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 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
> 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
[cassandra] branch Tim deleted (was afde441448)
This is an automated email from the ASF dual-hosted git repository. aweisberg pushed a change to branch Tim in repository https://gitbox.apache.org/repos/asf/cassandra.git was afde441448 Merge branch 'cassandra-5.0' into trunk The revisions that were on this branch are still contained in other references; therefore, this change does not discard any commits from the repository. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch Tim deleted (was afde441448)
This is an automated email from the ASF dual-hosted git repository. aweisberg pushed a change to branch Tim in repository https://gitbox.apache.org/repos/asf/cassandra.git was afde441448 Merge branch 'cassandra-5.0' into trunk The revisions that were on this branch are still contained in other references; therefore, this change does not discard any commits from the repository. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch Tim created (now afde441448)
This is an automated email from the ASF dual-hosted git repository. aweisberg pushed a change to branch Tim in repository https://gitbox.apache.org/repos/asf/cassandra.git at afde441448 Merge branch 'cassandra-5.0' into trunk No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch Tim created (now afde441448)
This is an automated email from the ASF dual-hosted git repository. aweisberg pushed a change to branch Tim in repository https://gitbox.apache.org/repos/asf/cassandra.git at afde441448 Merge branch 'cassandra-5.0' into trunk No new revisions were added by this update. - 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
]
Brandon Williams updated CASSANDRA-18946:
-
Reviewers: Brandon Williams
Status: Review In Progress (was: Patch Available)
> 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
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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 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
> 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-18946) Add cqlsh autocompletion for the vector data type
[
https://issues.apache.org/jira/browse/CASSANDRA-18946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778753#comment-17778753
]
Andres de la Peña commented on CASSANDRA-18946:
---
Right, thanks. Here we go again:
||PR||CI||
|[5.0
|https://github.com/apache/cassandra/pull/2834]|[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/3263/workflows/0218dd74-dd46-439d-8a4d-cc310d9042df]
[j17|https://app.circleci.com/pipelines/github/adelapena/cassandra/3263/workflows/284f4227-7944-4e39-b233-37442f201963]|
I've also fixed a mistake on the completion for the number of dimensions, both
in the patch and in the ticket description (it shouldn't suggest a negative
number of dimensions).
> 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
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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 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
> 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] [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
]
Andres de la Peña updated CASSANDRA-18946:
--
Description:
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 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
cqlsh> INSERT INTO t(k, v) VALUES ( 0,
)>
{code}
was:
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}
> 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
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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 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
> 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-18935) Fix nodetool enable/disablebinary to correctly set rpc
[
https://issues.apache.org/jira/browse/CASSANDRA-18935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778746#comment-17778746
]
Stefan Miklosovic commented on CASSANDRA-18935:
---
passed
https://app.circleci.com/pipelines/github/driftx/cassandra/1346/workflows/b3fec612-e901-4166-a18a-8e1c88128f42/jobs/59243
> Fix nodetool enable/disablebinary to correctly set rpc
> --
>
> Key: CASSANDRA-18935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18935
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Attachments: 18935-3.11.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
>
> {code:java}
> if ((nativeFlag != null && Boolean.parseBoolean(nativeFlag)) ||
> (nativeFlag == null && DatabaseDescriptor.startNativeTransport()))
> {
> startNativeTransport();
> StorageService.instance.setRpcReady(true);
> } {code}
> The startup code here only sets RpcReady if native transport is enabled. If
> you call
> {code:java}
> nodetool enablebinary{code}
> then this flag doesn't get set.
> But with the change from CASSANDRA-13043 it requires RpcReady set to true in
> order to get a leader for the counter update.
> Not sure what the correct fix is here, seems to only really use this flag for
> counters. So thinking perhaps the fix is to just move this outside the if
> condition.
>
--
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=17778743#comment-17778743 ] Francisco Guerrero commented on CASSANDRASC-77: --- Green CI after applying PR feedback: https://app.circleci.com/pipelines/github/frankgh/cassandra-sidecar/334 > 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] (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=17778735#comment-17778735
]
Caleb Rackliffe commented on CASSANDRA-18896:
-
I've also, for fun/practice, attached results for the 5.0 branch from the
non-Circle CI platform we'll be using. It's clean, except for a random
unrelated Python dtest timeout.
> 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
>
> Attachments: ci_summary.html, result_details.tar.gz
>
> Time Spent: 1h
> 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:
Attachment: ci_summary.html
> 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
>
> Attachments: ci_summary.html, result_details.tar.gz
>
> Time Spent: 1h
> 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:
Attachment: result_details.tar.gz
> 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
>
> Attachments: ci_summary.html, result_details.tar.gz
>
> Time Spent: 1h
> 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-18954) Transformations should be pure so that replaying them results in the same outcome regardless of the node state or configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18954: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Consistency(12989) Complexity: Normal Component/s: Transactional Cluster Metadata Discovered By: Code Inspection Severity: Normal Status: Open (was: Triage Needed) > Transformations should be pure so that replaying them results in the same > outcome regardless of the node state or configuration > --- > > Key: CASSANDRA-18954 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18954 > Project: Cassandra > Issue Type: Bug > Components: Transactional Cluster Metadata >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > > Discussed on Slack -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18954) Transformations should be pure so that replaying them results in the same outcome regardless of the node state or configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski reassigned CASSANDRA-18954: - Assignee: Jacek Lewandowski > Transformations should be pure so that replaying them results in the same > outcome regardless of the node state or configuration > --- > > Key: CASSANDRA-18954 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18954 > Project: Cassandra > Issue Type: Bug >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > > Discussed on Slack -- 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-18954) Transformations should be pure so that replaying them results in the same outcome regardless of the node state or configuration
Jacek Lewandowski created CASSANDRA-18954: - Summary: Transformations should be pure so that replaying them results in the same outcome regardless of the node state or configuration Key: CASSANDRA-18954 URL: https://issues.apache.org/jira/browse/CASSANDRA-18954 Project: Cassandra Issue Type: Bug Reporter: Jacek Lewandowski Discussed on Slack -- 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-18946) Add cqlsh autocompletion for the vector data type
[
https://issues.apache.org/jira/browse/CASSANDRA-18946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778713#comment-17778713
]
Brandon Williams commented on CASSANDRA-18946:
--
codestyle bit you :(
> 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
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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] [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
]
Andres de la Peña updated CASSANDRA-18946:
--
Test and Documentation Plan:
||PR||CI||
|[5.0
|https://github.com/apache/cassandra/pull/2834]|[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/3262/workflows/23fb5349-355b-446a-811b-61e0bf8c4735]
[j17|https://app.circleci.com/pipelines/github/adelapena/cassandra/3262/workflows/8aa877cc-4959-41b1-9900-615321e4ebe4]|
Status: Patch Available (was: In Progress)
> 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
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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-18946) Add cqlsh autocompletion for the vector data type
[
https://issues.apache.org/jira/browse/CASSANDRA-18946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778711#comment-17778711
]
Andres de la Peña commented on CASSANDRA-18946:
---
Here is the PR for trunk:
||PR||CI||
|[5.0
|https://github.com/apache/cassandra/pull/2834]|[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/3262/workflows/23fb5349-355b-446a-811b-61e0bf8c4735]
[j17|https://app.circleci.com/pipelines/github/adelapena/cassandra/3262/workflows/8aa877cc-4959-41b1-9900-615321e4ebe4]|
I have found that how cqlsh deals with generics on collections and tuples is a
bit outdated and we should improve it. That's something that we can do on a
separate ticket. This one puts autocompletion for the new vector type at the
same level as collections and tuples.
I'll add a PR for trunk if this one looks good.
> 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
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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-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=17778704#comment-17778704
]
Caleb Rackliffe commented on CASSANDRA-18896:
-
[~bereng] [~blerer] Tests and repeats look clean...anything else you want to
see before we commit here?
> 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: 1h
> 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-18464) Enable Direct I/O For CommitLog Files
[ https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778668#comment-17778668 ] Brandon Williams commented on CASSANDRA-18464: -- bq. I found that there is no test for this pr, and I also want to know how to test this pr We already have plenty of commitlog tests, I would think enabling direct IO for them is enough. > Enable Direct I/O For CommitLog Files > - > > Key: CASSANDRA-18464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18464 > Project: Cassandra > Issue Type: New Feature > Components: Local/Commit Log >Reporter: Josh McKenzie >Assignee: Amit Pawar >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CommitLogStressTest.patch, > EnableDirectIOForCommitLogUsingNativeAPI.patch, > PeriodicCommitLogStressTest.tar.bz2, SetCommitLogFileSize.patch, > UseDirectIOFeatureForCommitLogFiles.patch, image-2023-06-29-01-12-49-382.png > > > Relocating from [dev@ email > thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg] > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-22 and link to the thread is given > below. > [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n] > Basically, two solutions looked possible to improve the CommitLog I/O. > # Multi-threaded syncing > # Using Direct-IO through JNA > I worked on 2nd option considering the following benefit compared to the > first one > # Direct I/O read/write throughput is very high compared to non-Direct I/O. > Learnt through FIO benchmarking. > # Reduces kernel file cache uses which in-turn reduces kernel I/O activity > for Commitlog files only. > # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < > 30% for Commitlog syncer thread with Direct I/O feature > # Direct I/O implementation is easier compared to multi-threaded > As per the community suggestion, less in code complex is good to have. Direct > I/O enablement looked promising but there was one issue. > Java version 8 does not have native support to enable Direct I/O. So, JNA > library usage is must. The same implementation should also work across other > versions of Java (like 11 and beyond). > I have completed Direct I/O implementation and summary of the attached patch > changes are given below. > # This implementation is not using Java file channels and file is opened > through JNA to use Direct I/O feature. > # New Segment are defined named “DirectIOSegment” for Direct I/O and > “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose > only). > # JNA write call is used to flush the changes. > # New helper functions are defined in NativeLibrary.java and platform > specific file. Currently tested on Linux only. > # Patch allows user to configure optimum block size and alignment if > default values are not OK for CommitLog disk. > # Following configuration options are provided in Cassandra.yaml file > a. use_jna_for_commitlog_io : to use jna feature > b. use_direct_io_for_commitlog : to use Direct I/O feature. > c. direct_io_minimum_block_alignment: 512 (default) > d. nvme_disk_block_size: 32MiB (default and can be changed as per the > required size) > Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark > was tested. It works with both Java 8 and 11 versions. Compressed and > Encrypted based segments are not supported yet and it can be enabled later > based on the Community feedback. > Following improvement are seen with Direct I/O enablement. > # 32 cores >= ~15% > # 64 cores >= ~80% > Also, another observation would like to share here. Reading Commitlog files > with Direct I/O might help in reducing node bring-up time after the node > crash. > Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07 > The attached patch enables Direct I/O feature for Commitlog files. Please > check and share your feedback. -- 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-18935) Fix nodetool enable/disablebinary to correctly set rpc
[
https://issues.apache.org/jira/browse/CASSANDRA-18935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778662#comment-17778662
]
Brandon Williams commented on CASSANDRA-18935:
--
[Upgrade
tests|https://app.circleci.com/pipelines/github/driftx/cassandra/1346/workflows/b3fec612-e901-4166-a18a-8e1c88128f42].
> Fix nodetool enable/disablebinary to correctly set rpc
> --
>
> Key: CASSANDRA-18935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18935
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Attachments: 18935-3.11.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
>
> {code:java}
> if ((nativeFlag != null && Boolean.parseBoolean(nativeFlag)) ||
> (nativeFlag == null && DatabaseDescriptor.startNativeTransport()))
> {
> startNativeTransport();
> StorageService.instance.setRpcReady(true);
> } {code}
> The startup code here only sets RpcReady if native transport is enabled. If
> you call
> {code:java}
> nodetool enablebinary{code}
> then this flag doesn't get set.
> But with the change from CASSANDRA-13043 it requires RpcReady set to true in
> order to get a leader for the counter update.
> Not sure what the correct fix is here, seems to only really use this flag for
> counters. So thinking perhaps the fix is to just move this outside the if
> condition.
>
--
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-18936) CI jvm-dtest-upgrade breakage
[ https://issues.apache.org/jira/browse/CASSANDRA-18936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18936: --- Fix Version/s: 5.0 > CI jvm-dtest-upgrade breakage > - > > Key: CASSANDRA-18936 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18936 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0-alpha2, 5.0, 5.1 > > > git clean failing when reusing the dtest sub clone. > ref: https://the-asf.slack.com/archives/CK23JSY2K/p1697465832946299 -- 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-18935) Fix nodetool enable/disablebinary to correctly set rpc
[
https://issues.apache.org/jira/browse/CASSANDRA-18935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18935:
--
Status: Ready to Commit (was: Review In Progress)
> Fix nodetool enable/disablebinary to correctly set rpc
> --
>
> Key: CASSANDRA-18935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18935
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Attachments: 18935-3.11.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
>
> {code:java}
> if ((nativeFlag != null && Boolean.parseBoolean(nativeFlag)) ||
> (nativeFlag == null && DatabaseDescriptor.startNativeTransport()))
> {
> startNativeTransport();
> StorageService.instance.setRpcReady(true);
> } {code}
> The startup code here only sets RpcReady if native transport is enabled. If
> you call
> {code:java}
> nodetool enablebinary{code}
> then this flag doesn't get set.
> But with the change from CASSANDRA-13043 it requires RpcReady set to true in
> order to get a leader for the counter update.
> Not sure what the correct fix is here, seems to only really use this flag for
> counters. So thinking perhaps the fix is to just move this outside the if
> condition.
>
--
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-18935) Fix nodetool enable/disablebinary to correctly set rpc
[
https://issues.apache.org/jira/browse/CASSANDRA-18935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18935:
--
Reviewers: Brandon Williams
Status: Review In Progress (was: Needs Committer)
> Fix nodetool enable/disablebinary to correctly set rpc
> --
>
> Key: CASSANDRA-18935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18935
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Legacy/CQL
>Reporter: Cameron Zemek
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Attachments: 18935-3.11.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
>
> {code:java}
> if ((nativeFlag != null && Boolean.parseBoolean(nativeFlag)) ||
> (nativeFlag == null && DatabaseDescriptor.startNativeTransport()))
> {
> startNativeTransport();
> StorageService.instance.setRpcReady(true);
> } {code}
> The startup code here only sets RpcReady if native transport is enabled. If
> you call
> {code:java}
> nodetool enablebinary{code}
> then this flag doesn't get set.
> But with the change from CASSANDRA-13043 it requires RpcReady set to true in
> order to get a leader for the counter update.
> Not sure what the correct fix is here, seems to only really use this flag for
> counters. So thinking perhaps the fix is to just move this outside the if
> condition.
>
--
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-18936) CI jvm-dtest-upgrade breakage
[ https://issues.apache.org/jira/browse/CASSANDRA-18936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18936: -- Status: Ready to Commit (was: Review In Progress) > CI jvm-dtest-upgrade breakage > - > > Key: CASSANDRA-18936 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18936 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0-alpha2, 5.1 > > > git clean failing when reusing the dtest sub clone. > ref: https://the-asf.slack.com/archives/CK23JSY2K/p1697465832946299 -- 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-18936) CI jvm-dtest-upgrade breakage
[ https://issues.apache.org/jira/browse/CASSANDRA-18936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18936: -- Resolution: Fixed Status: Resolved (was: Ready to Commit) additional ninja merged in https://github.com/apache/cassandra/commit/e2d2bd61f479fa7128f97a1b5b1623632855ffd0 > CI jvm-dtest-upgrade breakage > - > > Key: CASSANDRA-18936 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18936 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0-alpha2, 5.1 > > > git clean failing when reusing the dtest sub clone. > ref: https://the-asf.slack.com/archives/CK23JSY2K/p1697465832946299 -- 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 (bf321d7951 -> afde441448)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from bf321d7951 Merge branch 'cassandra-5.0' into trunk add e2d2bd61f4 ninja-fix nested cassandra clone for dtest jar building re-use check new afde441448 Merge branch 'cassandra-5.0' into trunk 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: .build/run-tests.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-5.0' into trunk
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit afde441448e69246d47894f9751dc08f0bca9ba8 Merge: bf321d7951 e2d2bd61f4 Author: Stefan Miklosovic AuthorDate: Mon Oct 23 12:47:29 2023 +0200 Merge branch 'cassandra-5.0' into trunk .build/run-tests.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-5.0 updated (07df26778b -> e2d2bd61f4)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-5.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 07df26778b Change the checksum algorithm SAI-related files use from CRC32 to CRC32C add e2d2bd61f4 ninja-fix nested cassandra clone for dtest jar building re-use check No new revisions were added by this update. Summary of changes: .build/run-tests.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18464) Enable Direct I/O For CommitLog Files
[ https://issues.apache.org/jira/browse/CASSANDRA-18464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778614#comment-17778614 ] Maxwell Guo commented on CASSANDRA-18464: - [~amit_pawar]Any update on this ? If you need, I think I can do some help too. > Enable Direct I/O For CommitLog Files > - > > Key: CASSANDRA-18464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18464 > Project: Cassandra > Issue Type: New Feature > Components: Local/Commit Log >Reporter: Josh McKenzie >Assignee: Amit Pawar >Priority: Normal > Fix For: 5.0.x, 5.x > > Attachments: CommitLogStressTest.patch, > EnableDirectIOForCommitLogUsingNativeAPI.patch, > PeriodicCommitLogStressTest.tar.bz2, SetCommitLogFileSize.patch, > UseDirectIOFeatureForCommitLogFiles.patch, image-2023-06-29-01-12-49-382.png > > > Relocating from [dev@ email > thread.|https://lists.apache.org/thread/j6ny17q2rhkp7jxvwxm69dd6v1dozjrg] > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-22 and link to the thread is given > below. > [https://lists.apache.org/thread/xc5ocog2qz2v2gnj4xlw5hbthfqytx2n] > Basically, two solutions looked possible to improve the CommitLog I/O. > # Multi-threaded syncing > # Using Direct-IO through JNA > I worked on 2nd option considering the following benefit compared to the > first one > # Direct I/O read/write throughput is very high compared to non-Direct I/O. > Learnt through FIO benchmarking. > # Reduces kernel file cache uses which in-turn reduces kernel I/O activity > for Commitlog files only. > # Overall CPU usage reduced for flush activity. JVisualvm shows CPU usage < > 30% for Commitlog syncer thread with Direct I/O feature > # Direct I/O implementation is easier compared to multi-threaded > As per the community suggestion, less in code complex is good to have. Direct > I/O enablement looked promising but there was one issue. > Java version 8 does not have native support to enable Direct I/O. So, JNA > library usage is must. The same implementation should also work across other > versions of Java (like 11 and beyond). > I have completed Direct I/O implementation and summary of the attached patch > changes are given below. > # This implementation is not using Java file channels and file is opened > through JNA to use Direct I/O feature. > # New Segment are defined named “DirectIOSegment” for Direct I/O and > “NonDirectIOSegment” for non-direct I/O (NonDirectIOSegment is test purpose > only). > # JNA write call is used to flush the changes. > # New helper functions are defined in NativeLibrary.java and platform > specific file. Currently tested on Linux only. > # Patch allows user to configure optimum block size and alignment if > default values are not OK for CommitLog disk. > # Following configuration options are provided in Cassandra.yaml file > a. use_jna_for_commitlog_io : to use jna feature > b. use_direct_io_for_commitlog : to use Direct I/O feature. > c. direct_io_minimum_block_alignment: 512 (default) > d. nvme_disk_block_size: 32MiB (default and can be changed as per the > required size) > Test matrix is complex so CommitLog related testcases and TPCx-IOT benchmark > was tested. It works with both Java 8 and 11 versions. Compressed and > Encrypted based segments are not supported yet and it can be enabled later > based on the Community feedback. > Following improvement are seen with Direct I/O enablement. > # 32 cores >= ~15% > # 64 cores >= ~80% > Also, another observation would like to share here. Reading Commitlog files > with Direct I/O might help in reducing node bring-up time after the node > crash. > Tested with commit ID: 91f6a9aca8d3c22a03e68aa901a0b154d960ab07 > The attached patch enables Direct I/O feature for Commitlog files. Please > check and share your feedback. -- 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-18936) CI jvm-dtest-upgrade breakage
[ https://issues.apache.org/jira/browse/CASSANDRA-18936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18936: -- Reviewers: Stefan Miklosovic, Stefan Miklosovic (was: Stefan Miklosovic) Stefan Miklosovic, Stefan Miklosovic (was: Stefan Miklosovic) Status: Review In Progress (was: Patch Available) > CI jvm-dtest-upgrade breakage > - > > Key: CASSANDRA-18936 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18936 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0-alpha2, 5.1 > > > git clean failing when reusing the dtest sub clone. > ref: https://the-asf.slack.com/archives/CK23JSY2K/p1697465832946299 -- 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=17778601#comment-17778601
]
Stefan Miklosovic commented on CASSANDRA-18775:
---
I am definitely for a complete removal if it is possible to rewrite it without
it.
I think there is a new process api in Java 9+ like this which is worth to
explore.
https://docs.oracle.com/javase/9/docs/api/java/lang/ProcessHandle.html#pid--
> 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-18945) Unified Compaction Strategy is creating too many sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778600#comment-17778600
]
Stefan Miklosovic commented on CASSANDRA-18945:
---
Can you elaborate what performance problems you saw? I was testing UCS by
loading around 1TB (more like 800G) and I have not see any problem in
cassandra-stress. It was still responsive and write throughput was not affected.
> 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] [Comment Edited] (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:comment-tabpanel=17778600#comment-17778600
]
Stefan Miklosovic edited comment on CASSANDRA-18945 at 10/23/23 9:41 AM:
-
Can you elaborate what performance problems you saw? I was testing UCS by
loading around 1TB (more like 800G) and I have not seen any problem in
cassandra-stress. It was still responsive and write throughput was not affected.
was (Author: smiklosovic):
Can you elaborate what performance problems you saw? I was testing UCS by
loading around 1TB (more like 800G) and I have not see any problem in
cassandra-stress. It was still responsive and write throughput was not affected.
> 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-18936) CI jvm-dtest-upgrade breakage
[ https://issues.apache.org/jira/browse/CASSANDRA-18936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-18936: --- Status: Patch Available (was: Open) > CI jvm-dtest-upgrade breakage > - > > Key: CASSANDRA-18936 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18936 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 5.0-alpha2, 5.1 > > > git clean failing when reusing the dtest sub clone. > ref: https://the-asf.slack.com/archives/CK23JSY2K/p1697465832946299 -- 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-18936) CI jvm-dtest-upgrade breakage
[
https://issues.apache.org/jira/browse/CASSANDRA-18936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-18936:
---
Resolution: (was: Fixed)
Status: Open (was: Resolved)
Breakage still ongoing…
In various scenarios the {{${TMP_DIR}/cassandra-dtest-jars}} directory existed
but was not a git clone, and then the {{`git -C ${TMP_DIR}/cassandra-dtest-jars
remote get-url origin`}} was returning the git info from the parent cassandra
directory.
Fix is to test on {{${TMP_DIR}/cassandra-dtest-jars/.git}} (instead of
{{${TMP_DIR}/cassandra-dtest-jars}}).
Patches
- 5.0
https://github.com/apache/cassandra/compare/cassandra-5.0...thelastpickle:cassandra:mck/18936/5.0
- trunk
https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/18936-1/trunk
> CI jvm-dtest-upgrade breakage
> -
>
> Key: CASSANDRA-18936
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18936
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.0-alpha2, 5.1
>
>
> git clean failing when reusing the dtest sub clone.
> ref: https://the-asf.slack.com/archives/CK23JSY2K/p1697465832946299
--
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-18953) Refactor TCM configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-18953: -- Change Category: Code Clarity Complexity: Low Hanging Fruit Status: Open (was: Triage Needed) > Refactor TCM configuration > -- > > Key: CASSANDRA-18953 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18953 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > > Refactor TCM configuration so that: > - yaml has all TCM based options under a common "cms" root > - system properties related to TCM all starts with "cms." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18953) Refactor TCM configuration
[ https://issues.apache.org/jira/browse/CASSANDRA-18953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski reassigned CASSANDRA-18953: - Assignee: Jacek Lewandowski > Refactor TCM configuration > -- > > Key: CASSANDRA-18953 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18953 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > > Refactor TCM configuration so that: > - yaml has all TCM based options under a common "cms" root > - system properties related to TCM all starts with "cms." -- 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-18953) Refactor TCM configuration
Jacek Lewandowski created CASSANDRA-18953: - Summary: Refactor TCM configuration Key: CASSANDRA-18953 URL: https://issues.apache.org/jira/browse/CASSANDRA-18953 Project: Cassandra Issue Type: Improvement Components: Local/Config Reporter: Jacek Lewandowski Refactor TCM configuration so that: - yaml has all TCM based options under a common "cms" root - system properties related to TCM all starts with "cms." -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16565) Remove dependency on sigar
[ https://issues.apache.org/jira/browse/CASSANDRA-16565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren reassigned CASSANDRA-16565: - Assignee: Claude Warren > Remove dependency on sigar > -- > > Key: CASSANDRA-16565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16565 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: Claude Warren >Priority: Normal > Fix For: 5.x > > > sigar is used to check if the environment has good settings for running C*, > but requires we bundle a lot of native libraries to perform this check (which > can also be done elsewhere). This project also appears to be dead as the > last commit was around 6 years ago. > With the move to resolve artifacts rather than commit them, removing this > dependency would remove majority of the artifacts fetched from GitHub. -- 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-16565) Remove dependency on sigar
[ https://issues.apache.org/jira/browse/CASSANDRA-16565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17778533#comment-17778533 ] Claude Warren commented on CASSANDRA-16565: --- After the discussion on the mailing list [1] CASSANDRA-18775 was closed as "won't do" . I will look into removing lib/sigar from the project. [1]https://lists.apache.org/thread/6gzyh1zhxnkz50lld7hlgq172xc0pg3t > Remove dependency on sigar > -- > > Key: CASSANDRA-16565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16565 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Priority: Normal > Fix For: 5.x > > > sigar is used to check if the environment has good settings for running C*, > but requires we bundle a lot of native libraries to perform this check (which > can also be done elsewhere). This project also appears to be dead as the > last commit was around 6 years ago. > With the move to resolve artifacts rather than commit them, removing this > dependency would remove majority of the artifacts fetched from GitHub. -- 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-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:all-tabpanel
]
Claude Warren updated CASSANDRA-18775:
--
Resolution: Won't Do
Status: Resolved (was: Open)
Discussion on dev mailing list indicated that this approach is not supported.
Mailing list thread:
https://lists.apache.org/thread/6gzyh1zhxnkz50lld7hlgq172xc0pg3t
> 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
