[jira] [Commented] (CASSANDRA-19666) Split the metrics collection into smaller groups
[
https://issues.apache.org/jira/browse/CASSANDRA-19666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850472#comment-17850472
]
Maxim Muzafarov commented on CASSANDRA-19666:
-
To be clear, by "dynamic" I meant that when a new keyspace is created, it gets
a corresponding virtual table without having to be registered statically.
For example, a user creates a "myks", and as new MBeans are automatically
registered for this new keyspace, and metrics are started to be visible via
JMX, a new corresponding "system_metrics.keyspaces_myks" is also created in a
system_metrics virtual keyspace.
> Split the metrics collection into smaller groups
>
>
> Key: CASSANDRA-19666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19666
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Urgent
> Fix For: 5.x
>
>
> Historically, all metrics are stored in a single collection indexed by a
> unique metric name - {{{}ConcurrentMap{}}}. This storage
> technique doesn't offer any advantages over other options we might have
> below, and causes some performance and usability issues when we need to
> traverse this huge collection while filtering the metrics.
> The following possible solutions could be used:
> - Use
> https://www.javadoc.io/doc/io.dropwizard.metrics/metrics-core/4.0.2/com/codahale/metrics/SharedMetricRegistries.html
> , which provides a way to store metrics in their dedicated groups;
> - Implement a hierarchical storage structure, based on the knowledge of how
> the metric key is formed. For example,
> https://the-asf.slack.com/archives/CK23JSY2K/p1716568216701789?thread_ts=1716324924.466269=CK23JSY2K
> Each of the above options assumes, that the metric groups are statically
> registered and known at the time a node starts. This may also be an option to
> consider for dynamically registering metric groups and in turn registering
> corresponding virtual tables and JmxMbean. In the latter case, we'll need to
> implement the notification mechanism for the drivers, as they are not
> currently notified about newly created virtual tables.
--
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-19666) Split the metrics collection into smaller groups
[
https://issues.apache.org/jira/browse/CASSANDRA-19666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19666:
Priority: Urgent (was: Normal)
> Split the metrics collection into smaller groups
>
>
> Key: CASSANDRA-19666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19666
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Urgent
> Fix For: 5.x
>
>
> Historically, all metrics are stored in a single collection indexed by a
> unique metric name - {{{}ConcurrentMap{}}}. This storage
> technique doesn't offer any advantages over other options we might have
> below, and causes some performance and usability issues when we need to
> traverse this huge collection while filtering the metrics.
> The following possible solutions could be used:
> - Use
> https://www.javadoc.io/doc/io.dropwizard.metrics/metrics-core/4.0.2/com/codahale/metrics/SharedMetricRegistries.html
> , which provides a way to store metrics in their dedicated groups;
> - Implement a hierarchical storage structure, based on the knowledge of how
> the metric key is formed. For example,
> https://the-asf.slack.com/archives/CK23JSY2K/p1716568216701789?thread_ts=1716324924.466269=CK23JSY2K
> Each of the above options assumes, that the metric groups are statically
> registered and known at the time a node starts. This may also be an option to
> consider for dynamically registering metric groups and in turn registering
> corresponding virtual tables and JmxMbean. In the latter case, we'll need to
> implement the notification mechanism for the drivers, as they are not
> currently notified about newly created virtual tables.
--
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-19666) Split the metrics collection into smaller groups
[
https://issues.apache.org/jira/browse/CASSANDRA-19666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19666:
Change Category: Performance
Complexity: Normal
Status: Open (was: Triage Needed)
> Split the metrics collection into smaller groups
>
>
> Key: CASSANDRA-19666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19666
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
>
> Historically, all metrics are stored in a single collection indexed by a
> unique metric name - {{{}ConcurrentMap{}}}. This storage
> technique doesn't offer any advantages over other options we might have
> below, and causes some performance and usability issues when we need to
> traverse this huge collection while filtering the metrics.
> The following possible solutions could be used:
> - Use
> https://www.javadoc.io/doc/io.dropwizard.metrics/metrics-core/4.0.2/com/codahale/metrics/SharedMetricRegistries.html
> , which provides a way to store metrics in their dedicated groups;
> - Implement a hierarchical storage structure, based on the knowledge of how
> the metric key is formed. For example,
> https://the-asf.slack.com/archives/CK23JSY2K/p1716568216701789?thread_ts=1716324924.466269=CK23JSY2K
> Each of the above options assumes, that the metric groups are statically
> registered and known at the time a node starts. This may also be an option to
> consider for dynamically registering metric groups and in turn registering
> corresponding virtual tables and JmxMbean. In the latter case, we'll need to
> implement the notification mechanism for the drivers, as they are not
> currently notified about newly created virtual tables.
--
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-19666) Split the metrics collection into smaller groups
[
https://issues.apache.org/jira/browse/CASSANDRA-19666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19666:
Fix Version/s: 5.x
> Split the metrics collection into smaller groups
>
>
> Key: CASSANDRA-19666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19666
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
>
> Historically, all metrics are stored in a single collection indexed by a
> unique metric name - {{{}ConcurrentMap{}}}. This storage
> technique doesn't offer any advantages over other options we might have
> below, and causes some performance and usability issues when we need to
> traverse this huge collection while filtering the metrics.
> The following possible solutions could be used:
> - Use
> https://www.javadoc.io/doc/io.dropwizard.metrics/metrics-core/4.0.2/com/codahale/metrics/SharedMetricRegistries.html
> , which provides a way to store metrics in their dedicated groups;
> - Implement a hierarchical storage structure, based on the knowledge of how
> the metric key is formed. For example,
> https://the-asf.slack.com/archives/CK23JSY2K/p1716568216701789?thread_ts=1716324924.466269=CK23JSY2K
> Each of the above options assumes, that the metric groups are statically
> registered and known at the time a node starts. This may also be an option to
> consider for dynamically registering metric groups and in turn registering
> corresponding virtual tables and JmxMbean. In the latter case, we'll need to
> implement the notification mechanism for the drivers, as they are not
> currently notified about newly created virtual tables.
--
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-19666) Split the metrics collection into smaller groups
Maxim Muzafarov created CASSANDRA-19666:
---
Summary: Split the metrics collection into smaller groups
Key: CASSANDRA-19666
URL: https://issues.apache.org/jira/browse/CASSANDRA-19666
Project: Cassandra
Issue Type: Improvement
Components: Observability/Metrics
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
Historically, all metrics are stored in a single collection indexed by a unique
metric name - {{{}ConcurrentMap{}}}. This storage technique
doesn't offer any advantages over other options we might have below, and causes
some performance and usability issues when we need to traverse this huge
collection while filtering the metrics.
The following possible solutions could be used:
- Use
https://www.javadoc.io/doc/io.dropwizard.metrics/metrics-core/4.0.2/com/codahale/metrics/SharedMetricRegistries.html
, which provides a way to store metrics in their dedicated groups;
- Implement a hierarchical storage structure, based on the knowledge of how the
metric key is formed. For example,
https://the-asf.slack.com/archives/CK23JSY2K/p1716568216701789?thread_ts=1716324924.466269=CK23JSY2K
Each of the above options assumes, that the metric groups are statically
registered and known at the time a node starts. This may also be an option to
consider for dynamically registering metric groups and in turn registering
corresponding virtual tables and JmxMbean. In the latter case, we'll need to
implement the notification mechanism for the drivers, as they are not currently
notified about newly created virtual tables.
--
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-19619) Enforce contract for internal metrics naming
[
https://issues.apache.org/jira/browse/CASSANDRA-19619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19619:
Fix Version/s: 5.0-beta2
5.0
5.1
(was: 5.x)
(was: 5.0.x)
(was: 5.0-rc)
Source Control Link:
https://github.com/apache/cassandra/commit/ccdeb12419a70afb00e9aa3958fc05eb4617ee44
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
[~maedhroz] thank you for the review and running CI.
[~mck] thank you for the review either.
Committed to 5.0 and the trunk.
> Enforce contract for internal metrics naming
>
>
> Key: CASSANDRA-19619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19619
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-beta2, 5.0, 5.1
>
> Attachments: ci_summary-1.html, ci_summary.html
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Metrics have their internal representation which uniquely identifies a
> particular metric name. The name is formed as {{. type>..}}. For some metrics, the scope includes a
> metric name that is not necessary for uniqueness, this can be simplified.
> For example,
> {code}
> // AS IS
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics.BalancedTreeIntersectionEarlyExits
> // TO BE
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics
> {code}
> The metrics are filtered based on knowledge of how they are formatted, so
> having a metric scope without a built-in metric name also simplifies the way
> we filter metrics.
--
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-19619) Enforce contract for internal metrics naming
[
https://issues.apache.org/jira/browse/CASSANDRA-19619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19619:
Reviewers: Caleb Rackliffe, Michael Semb Wever (was: Caleb Rackliffe)
> Enforce contract for internal metrics naming
>
>
> Key: CASSANDRA-19619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19619
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
> Attachments: ci_summary-1.html, ci_summary.html
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Metrics have their internal representation which uniquely identifies a
> particular metric name. The name is formed as {{. type>..}}. For some metrics, the scope includes a
> metric name that is not necessary for uniqueness, this can be simplified.
> For example,
> {code}
> // AS IS
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics.BalancedTreeIntersectionEarlyExits
> // TO BE
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics
> {code}
> The metrics are filtered based on knowledge of how they are formatted, so
> having a metric scope without a built-in metric name also simplifies the way
> we filter metrics.
--
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-19619) Enforce contract for internal metrics naming
[
https://issues.apache.org/jira/browse/CASSANDRA-19619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843767#comment-17843767
]
Maxim Muzafarov edited comment on CASSANDRA-19619 at 5/6/24 2:57 PM:
-
[~e.dimitrova] yes, we've agreed with [~maedhroz] to include these changes into
the 5.0. The changes should be pretty straightforward, but verification is
needed. I'm trying to run everything locally so far as I've exhausted my OS
credits on CircleCi.
was (Author: mmuzaf):
[~e.dimitrova] yes, we've agreed with [~maedhroz] to include these changes into
the 5.0. The changes should be pretty straightforward, but verification is
needed. I'm trying to run everything locally so far as I'm exhausted my OS
credits on CircleCi.
> Enforce contract for internal metrics naming
>
>
> Key: CASSANDRA-19619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19619
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Metrics have their internal representation which uniquely identifies a
> particular metric name. The name is formed as {{. type>..}}. For some metrics, the scope includes a
> metric name that is not necessary for uniqueness, this can be simplified.
> For example,
> {code}
> // AS IS
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics.BalancedTreeIntersectionEarlyExits
> // TO BE
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics
> {code}
> The metrics are filtered based on knowledge of how they are formatted, so
> having a metric scope without a built-in metric name also simplifies the way
> we filter metrics.
--
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-19619) Enforce contract for internal metrics naming
[
https://issues.apache.org/jira/browse/CASSANDRA-19619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843767#comment-17843767
]
Maxim Muzafarov commented on CASSANDRA-19619:
-
[~e.dimitrova] yes, we've agreed with [~maedhroz] to include these changes into
the 5.0. The changes should be pretty straightforward, but verification is
needed. I'm trying to run everything locally so far as I'm exhausted my OS
credits on CircleCi.
> Enforce contract for internal metrics naming
>
>
> Key: CASSANDRA-19619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19619
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Metrics have their internal representation which uniquely identifies a
> particular metric name. The name is formed as {{. type>..}}. For some metrics, the scope includes a
> metric name that is not necessary for uniqueness, this can be simplified.
> For example,
> {code}
> // AS IS
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics.BalancedTreeIntersectionEarlyExits
> // TO BE
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics
> {code}
> The metrics are filtered based on knowledge of how they are formatted, so
> having a metric scope without a built-in metric name also simplifies the way
> we filter metrics.
--
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-19619) Enforce contract for internal metrics naming
[
https://issues.apache.org/jira/browse/CASSANDRA-19619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843372#comment-17843372
]
Maxim Muzafarov commented on CASSANDRA-19619:
-
trunk:
[https://github.com/apache/cassandra/pull/3291/files]
5.0:
https://github.com/apache/cassandra/pull/3292/files
> Enforce contract for internal metrics naming
>
>
> Key: CASSANDRA-19619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19619
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Metrics have their internal representation which uniquely identifies a
> particular metric name. The name is formed as {{. type>..}}. For some metrics, the scope includes a
> metric name that is not necessary for uniqueness, this can be simplified.
> For example,
> {code}
> // AS IS
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics.BalancedTreeIntersectionEarlyExits
> // TO BE
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics
> {code}
> The metrics are filtered based on knowledge of how they are formatted, so
> having a metric scope without a built-in metric name also simplifies the way
> we filter metrics.
--
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-19619) Enforce contract for internal metrics naming
Maxim Muzafarov created CASSANDRA-19619:
---
Summary: Enforce contract for internal metrics naming
Key: CASSANDRA-19619
URL: https://issues.apache.org/jira/browse/CASSANDRA-19619
Project: Cassandra
Issue Type: Task
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
Metrics have their internal representation which uniquely identifies a
particular metric name. The name is formed as {{...}}. For some metrics, the scope includes a
metric name that is not necessary for uniqueness, this can be simplified.
For example,
{code}
// AS IS
org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics.BalancedTreeIntersectionEarlyExits
// TO BE
org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics
{code}
The metrics are filtered based on knowledge of how they are formatted, so
having a metric scope without a built-in metric name also simplifies the way we
filter metrics.
--
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-19619) Enforce contract for internal metrics naming
[
https://issues.apache.org/jira/browse/CASSANDRA-19619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19619:
Fix Version/s: 5.0-rc
5.0.x
5.x
> Enforce contract for internal metrics naming
>
>
> Key: CASSANDRA-19619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19619
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.0-rc, 5.0.x, 5.x
>
>
> Metrics have their internal representation which uniquely identifies a
> particular metric name. The name is formed as {{. type>..}}. For some metrics, the scope includes a
> metric name that is not necessary for uniqueness, this can be simplified.
> For example,
> {code}
> // AS IS
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics.BalancedTreeIntersectionEarlyExits
> // TO BE
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics
> {code}
> The metrics are filtered based on knowledge of how they are formatted, so
> having a metric scope without a built-in metric name also simplifies the way
> we filter metrics.
--
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-19619) Enforce contract for internal metrics naming
[
https://issues.apache.org/jira/browse/CASSANDRA-19619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19619:
Change Category: Semantic
Complexity: Low Hanging Fruit
Component/s: Observability/Metrics
Status: Open (was: Triage Needed)
> Enforce contract for internal metrics naming
>
>
> Key: CASSANDRA-19619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19619
> Project: Cassandra
> Issue Type: Task
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
>
> Metrics have their internal representation which uniquely identifies a
> particular metric name. The name is formed as {{. type>..}}. For some metrics, the scope includes a
> metric name that is not necessary for uniqueness, this can be simplified.
> For example,
> {code}
> // AS IS
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics.BalancedTreeIntersectionEarlyExits
> // TO BE
> org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics
> {code}
> The metrics are filtered based on knowledge of how they are formatted, so
> having a metric scope without a built-in metric name also simplifies the way
> we filter metrics.
--
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-19567) Minimize the heap consumption when registering metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19567:
Since Version: 5.1
Source Control Link:
https://github.com/apache/cassandra/commit/8619010cdca8bce471754e4fbeb861f036535007
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
[~maedhroz] Thank you for the review.
Committed to the trunk branch.
> Minimize the heap consumption when registering metrics
> --
>
> Key: CASSANDRA-19567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19567
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.1
>
> Attachments: ci_summary.html, summary.png
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> The problem is only reproducible on the x86 machine, the problem is not
> reproducible on the arm64. A quick analysis showed a lot of MetricName
> objects stored in the heap, although the real cause could be related to
> something else, the MetricName object requires extra attention.
> To reproduce run the command run locally:
> {code}
> ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.ReadRepairTest
> {code}
> The error:
> {code:java}
> [junit-timeout] Exception in thread "main" java.lang.OutOfMemoryError: Java
> heap space
> [junit-timeout] at
> java.base/java.lang.StringLatin1.newString(StringLatin1.java:769)
> [junit-timeout] at
> java.base/java.lang.StringBuffer.toString(StringBuffer.java:716)
> [junit-timeout] at
> org.apache.cassandra.CassandraBriefJUnitResultFormatter.endTestSuite(CassandraBriefJUnitResultFormatter.java:191)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.fireEndTestSuite(JUnitTestRunner.java:854)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:578)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1197)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1042)
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> org.apache.cassandra.distributed.test.ReadRepairTest:readRepairRTRangeMovementTest-cassandra.testtag_IS_UNDEFINED:
> Caused an ERROR
> [junit-timeout] Forked Java VM exited abnormally. Please note the time in the
> report does not reflect the time until the VM exit.
> [junit-timeout] junit.framework.AssertionFailedError: Forked Java VM exited
> abnormally. Please note the time in the report does not reflect the time
> until the VM exit.
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.distributed.test.ReadRepairTest
> FAILED (crashed)BUILD FAILED
> {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:
[jira] [Updated] (CASSANDRA-19567) Minimize the heap consumption when registering metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19567:
Status: Ready to Commit (was: Review In Progress)
> Minimize the heap consumption when registering metrics
> --
>
> Key: CASSANDRA-19567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19567
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.1
>
> Attachments: ci_summary.html, summary.png
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> The problem is only reproducible on the x86 machine, the problem is not
> reproducible on the arm64. A quick analysis showed a lot of MetricName
> objects stored in the heap, although the real cause could be related to
> something else, the MetricName object requires extra attention.
> To reproduce run the command run locally:
> {code}
> ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.ReadRepairTest
> {code}
> The error:
> {code:java}
> [junit-timeout] Exception in thread "main" java.lang.OutOfMemoryError: Java
> heap space
> [junit-timeout] at
> java.base/java.lang.StringLatin1.newString(StringLatin1.java:769)
> [junit-timeout] at
> java.base/java.lang.StringBuffer.toString(StringBuffer.java:716)
> [junit-timeout] at
> org.apache.cassandra.CassandraBriefJUnitResultFormatter.endTestSuite(CassandraBriefJUnitResultFormatter.java:191)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.fireEndTestSuite(JUnitTestRunner.java:854)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:578)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1197)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1042)
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> org.apache.cassandra.distributed.test.ReadRepairTest:readRepairRTRangeMovementTest-cassandra.testtag_IS_UNDEFINED:
> Caused an ERROR
> [junit-timeout] Forked Java VM exited abnormally. Please note the time in the
> report does not reflect the time until the VM exit.
> [junit-timeout] junit.framework.AssertionFailedError: Forked Java VM exited
> abnormally. Please note the time in the report does not reflect the time
> until the VM exit.
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.distributed.test.ReadRepairTest
> FAILED (crashed)BUILD FAILED
> {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-19567) Minimize the heap consumption when registering metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842035#comment-17842035
]
Maxim Muzafarov commented on CASSANDRA-19567:
-
I've fixed all the comments and the failed tests. The changes are here:
https://github.com/apache/cassandra/pull/3267
Additionally, I've prepared a branch that contains a new assertion on a metric
remove operation to ensure the contract. As I previously mentioned, this
assertion can be tricky as I assume some of the metrics with the same name can
be removed in parallel, it shouldn't happen in a normal way, but it could
because of the lack of tests and/or parallel removal the same metrics e.g.
Memtables share the same instances of metrics. Anyway, the same as above
changes, but with an assertion are here:
https://github.com/Mmuzaf/cassandra/tree/cassandra-19567-assert
I'll check that.
> Minimize the heap consumption when registering metrics
> --
>
> Key: CASSANDRA-19567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19567
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: summary.png
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> The problem is only reproducible on the x86 machine, the problem is not
> reproducible on the arm64. A quick analysis showed a lot of MetricName
> objects stored in the heap, although the real cause could be related to
> something else, the MetricName object requires extra attention.
> To reproduce run the command run locally:
> {code}
> ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.ReadRepairTest
> {code}
> The error:
> {code:java}
> [junit-timeout] Exception in thread "main" java.lang.OutOfMemoryError: Java
> heap space
> [junit-timeout] at
> java.base/java.lang.StringLatin1.newString(StringLatin1.java:769)
> [junit-timeout] at
> java.base/java.lang.StringBuffer.toString(StringBuffer.java:716)
> [junit-timeout] at
> org.apache.cassandra.CassandraBriefJUnitResultFormatter.endTestSuite(CassandraBriefJUnitResultFormatter.java:191)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.fireEndTestSuite(JUnitTestRunner.java:854)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:578)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1197)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1042)
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> org.apache.cassandra.distributed.test.ReadRepairTest:readRepairRTRangeMovementTest-cassandra.testtag_IS_UNDEFINED:
> Caused an ERROR
> [junit-timeout] Forked Java VM exited abnormally. Please note the time in the
> report does not reflect the time until the VM exit.
> [junit-timeout] junit.framework.AssertionFailedError: Forked Java VM exited
> abnormally. Please note the time in the report does not reflect the time
> until the VM exit.
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
>
[jira] [Commented] (CASSANDRA-19567) Minimize the heap consumption when registering metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839260#comment-17839260
]
Maxim Muzafarov commented on CASSANDRA-19567:
-
!summary.png|width=900!
> Minimize the heap consumption when registering metrics
> --
>
> Key: CASSANDRA-19567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19567
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: summary.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The problem is only reproducible on the x86 machine, the problem is not
> reproducible on the arm64. A quick analysis showed a lot of MetricName
> objects stored in the heap, although the real cause could be related to
> something else, the MetricName object requires extra attention.
> To reproduce run the command run locally:
> {code}
> ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.ReadRepairTest
> {code}
> The error:
> {code:java}
> [junit-timeout] Exception in thread "main" java.lang.OutOfMemoryError: Java
> heap space
> [junit-timeout] at
> java.base/java.lang.StringLatin1.newString(StringLatin1.java:769)
> [junit-timeout] at
> java.base/java.lang.StringBuffer.toString(StringBuffer.java:716)
> [junit-timeout] at
> org.apache.cassandra.CassandraBriefJUnitResultFormatter.endTestSuite(CassandraBriefJUnitResultFormatter.java:191)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.fireEndTestSuite(JUnitTestRunner.java:854)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:578)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1197)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1042)
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> org.apache.cassandra.distributed.test.ReadRepairTest:readRepairRTRangeMovementTest-cassandra.testtag_IS_UNDEFINED:
> Caused an ERROR
> [junit-timeout] Forked Java VM exited abnormally. Please note the time in the
> report does not reflect the time until the VM exit.
> [junit-timeout] junit.framework.AssertionFailedError: Forked Java VM exited
> abnormally. Please note the time in the report does not reflect the time
> until the VM exit.
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.distributed.test.ReadRepairTest
> FAILED (crashed)BUILD FAILED
> {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-19567) Minimize the heap consumption when registering metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839260#comment-17839260
]
Maxim Muzafarov edited comment on CASSANDRA-19567 at 4/20/24 4:33 PM:
--
!summary.png|width=800!
was (Author: mmuzaf):
!summary.png|width=900!
> Minimize the heap consumption when registering metrics
> --
>
> Key: CASSANDRA-19567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19567
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: summary.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The problem is only reproducible on the x86 machine, the problem is not
> reproducible on the arm64. A quick analysis showed a lot of MetricName
> objects stored in the heap, although the real cause could be related to
> something else, the MetricName object requires extra attention.
> To reproduce run the command run locally:
> {code}
> ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.ReadRepairTest
> {code}
> The error:
> {code:java}
> [junit-timeout] Exception in thread "main" java.lang.OutOfMemoryError: Java
> heap space
> [junit-timeout] at
> java.base/java.lang.StringLatin1.newString(StringLatin1.java:769)
> [junit-timeout] at
> java.base/java.lang.StringBuffer.toString(StringBuffer.java:716)
> [junit-timeout] at
> org.apache.cassandra.CassandraBriefJUnitResultFormatter.endTestSuite(CassandraBriefJUnitResultFormatter.java:191)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.fireEndTestSuite(JUnitTestRunner.java:854)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:578)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1197)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1042)
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> org.apache.cassandra.distributed.test.ReadRepairTest:readRepairRTRangeMovementTest-cassandra.testtag_IS_UNDEFINED:
> Caused an ERROR
> [junit-timeout] Forked Java VM exited abnormally. Please note the time in the
> report does not reflect the time until the VM exit.
> [junit-timeout] junit.framework.AssertionFailedError: Forked Java VM exited
> abnormally. Please note the time in the report does not reflect the time
> until the VM exit.
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.distributed.test.ReadRepairTest
> FAILED (crashed)BUILD FAILED
> {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-19567) Minimize the heap consumption when registering metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19567:
Attachment: summary.png
> Minimize the heap consumption when registering metrics
> --
>
> Key: CASSANDRA-19567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19567
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
> Attachments: summary.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The problem is only reproducible on the x86 machine, the problem is not
> reproducible on the arm64. A quick analysis showed a lot of MetricName
> objects stored in the heap, although the real cause could be related to
> something else, the MetricName object requires extra attention.
> To reproduce run the command run locally:
> {code}
> ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.ReadRepairTest
> {code}
> The error:
> {code:java}
> [junit-timeout] Exception in thread "main" java.lang.OutOfMemoryError: Java
> heap space
> [junit-timeout] at
> java.base/java.lang.StringLatin1.newString(StringLatin1.java:769)
> [junit-timeout] at
> java.base/java.lang.StringBuffer.toString(StringBuffer.java:716)
> [junit-timeout] at
> org.apache.cassandra.CassandraBriefJUnitResultFormatter.endTestSuite(CassandraBriefJUnitResultFormatter.java:191)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.fireEndTestSuite(JUnitTestRunner.java:854)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:578)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1197)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1042)
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> org.apache.cassandra.distributed.test.ReadRepairTest:readRepairRTRangeMovementTest-cassandra.testtag_IS_UNDEFINED:
> Caused an ERROR
> [junit-timeout] Forked Java VM exited abnormally. Please note the time in the
> report does not reflect the time until the VM exit.
> [junit-timeout] junit.framework.AssertionFailedError: Forked Java VM exited
> abnormally. Please note the time in the report does not reflect the time
> until the VM exit.
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.distributed.test.ReadRepairTest
> FAILED (crashed)BUILD FAILED
> {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] [Assigned] (CASSANDRA-19571) Avoid ConcurrentModificationException when removing metrics from CassandraMetricsRegistry
[
https://issues.apache.org/jira/browse/CASSANDRA-19571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov reassigned CASSANDRA-19571:
---
Assignee: Maxim Muzafarov
> Avoid ConcurrentModificationException when removing metrics from
> CassandraMetricsRegistry
> -
>
> Key: CASSANDRA-19571
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19571
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Maxim Muzafarov
>Priority: Normal
>
> Multiple threads can modify the lists in {{CassandraMetricsRegistry}}
> {{ALIASES}} map values. We have seen this CME when removing metrics, but
> could possibly affect other paths using those lists
> Adding a small delay (10ms) when map:ing to {{getMetricName}} in
> {{CassandraMetricsRegistry.remove(name)}} makes this reproduce when running
> {{TransientRangeMovementTest.testLeave}}
> Caused by CASSANDRA-14572
--
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-19571) Avoid ConcurrentModificationException when removing metrics from CassandraMetricsRegistry
[
https://issues.apache.org/jira/browse/CASSANDRA-19571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19571:
Fix Version/s: 5.x
> Avoid ConcurrentModificationException when removing metrics from
> CassandraMetricsRegistry
> -
>
> Key: CASSANDRA-19571
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19571
> Project: Cassandra
> Issue Type: Bug
>Reporter: Marcus Eriksson
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
>
> Multiple threads can modify the lists in {{CassandraMetricsRegistry}}
> {{ALIASES}} map values. We have seen this CME when removing metrics, but
> could possibly affect other paths using those lists
> Adding a small delay (10ms) when map:ing to {{getMetricName}} in
> {{CassandraMetricsRegistry.remove(name)}} makes this reproduce when running
> {{TransientRangeMovementTest.testLeave}}
> Caused by CASSANDRA-14572
--
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-19567) Minimize the heap consumption when registering metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19567:
Discovered By: DTest (was: User Report)
> Minimize the heap consumption when registering metrics
> --
>
> Key: CASSANDRA-19567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19567
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
>
> The problem is only reproducible on the x86 machine, the problem is not
> reproducible on the arm64. A quick analysis showed a lot of MetricName
> objects stored in the heap, although the real cause could be related to
> something else, the MetricName object requires extra attention.
> To reproduce run the command run locally:
> {code}
> ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.ReadRepairTest
> {code}
> The error:
> {code:java}
> [junit-timeout] Exception in thread "main" java.lang.OutOfMemoryError: Java
> heap space
> [junit-timeout] at
> java.base/java.lang.StringLatin1.newString(StringLatin1.java:769)
> [junit-timeout] at
> java.base/java.lang.StringBuffer.toString(StringBuffer.java:716)
> [junit-timeout] at
> org.apache.cassandra.CassandraBriefJUnitResultFormatter.endTestSuite(CassandraBriefJUnitResultFormatter.java:191)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.fireEndTestSuite(JUnitTestRunner.java:854)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:578)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1197)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1042)
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> org.apache.cassandra.distributed.test.ReadRepairTest:readRepairRTRangeMovementTest-cassandra.testtag_IS_UNDEFINED:
> Caused an ERROR
> [junit-timeout] Forked Java VM exited abnormally. Please note the time in the
> report does not reflect the time until the VM exit.
> [junit-timeout] junit.framework.AssertionFailedError: Forked Java VM exited
> abnormally. Please note the time in the report does not reflect the time
> until the VM exit.
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.distributed.test.ReadRepairTest
> FAILED (crashed)BUILD FAILED
> {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-19567) Minimize the heap consumption when registering metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19567:
Bug Category: Parent values: Degradation(12984)Level 1 values: Resource
Management(12995)
Complexity: Normal
Discovered By: User Report
Fix Version/s: 5.x
Platform: x86 (was: All)
Severity: Normal
Status: Open (was: Triage Needed)
> Minimize the heap consumption when registering metrics
> --
>
> Key: CASSANDRA-19567
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19567
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.x
>
>
> The problem is only reproducible on the x86 machine, the problem is not
> reproducible on the arm64. A quick analysis showed a lot of MetricName
> objects stored in the heap, although the real cause could be related to
> something else, the MetricName object requires extra attention.
> To reproduce run the command run locally:
> {code}
> ant test-jvm-dtest-some
> -Dtest.name=org.apache.cassandra.distributed.test.ReadRepairTest
> {code}
> The error:
> {code:java}
> [junit-timeout] Exception in thread "main" java.lang.OutOfMemoryError: Java
> heap space
> [junit-timeout] at
> java.base/java.lang.StringLatin1.newString(StringLatin1.java:769)
> [junit-timeout] at
> java.base/java.lang.StringBuffer.toString(StringBuffer.java:716)
> [junit-timeout] at
> org.apache.cassandra.CassandraBriefJUnitResultFormatter.endTestSuite(CassandraBriefJUnitResultFormatter.java:191)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.fireEndTestSuite(JUnitTestRunner.java:854)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:578)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1197)
> [junit-timeout] at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1042)
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> [junit-timeout] Testsuite:
> org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> org.apache.cassandra.distributed.test.ReadRepairTest:readRepairRTRangeMovementTest-cassandra.testtag_IS_UNDEFINED:
> Caused an ERROR
> [junit-timeout] Forked Java VM exited abnormally. Please note the time in the
> report does not reflect the time until the VM exit.
> [junit-timeout] junit.framework.AssertionFailedError: Forked Java VM exited
> abnormally. Please note the time in the report does not reflect the time
> until the VM exit.
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout] at
> jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.distributed.test.ReadRepairTest
> FAILED (crashed)BUILD FAILED
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19567) Minimize the heap consumption when registering metrics
Maxim Muzafarov created CASSANDRA-19567:
---
Summary: Minimize the heap consumption when registering metrics
Key: CASSANDRA-19567
URL: https://issues.apache.org/jira/browse/CASSANDRA-19567
Project: Cassandra
Issue Type: Bug
Components: Observability/Metrics
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
The problem is only reproducible on the x86 machine, the problem is not
reproducible on the arm64. A quick analysis showed a lot of MetricName objects
stored in the heap, although the real cause could be related to something else,
the MetricName object requires extra attention.
To reproduce run the command run locally:
{code}
ant test-jvm-dtest-some
-Dtest.name=org.apache.cassandra.distributed.test.ReadRepairTest
{code}
The error:
{code:java}
[junit-timeout] Exception in thread "main" java.lang.OutOfMemoryError: Java
heap space
[junit-timeout] at
java.base/java.lang.StringLatin1.newString(StringLatin1.java:769)
[junit-timeout] at
java.base/java.lang.StringBuffer.toString(StringBuffer.java:716)
[junit-timeout] at
org.apache.cassandra.CassandraBriefJUnitResultFormatter.endTestSuite(CassandraBriefJUnitResultFormatter.java:191)
[junit-timeout] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.fireEndTestSuite(JUnitTestRunner.java:854)
[junit-timeout] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:578)
[junit-timeout] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1197)
[junit-timeout] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1042)
[junit-timeout] Testsuite:
org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
[junit-timeout] Testsuite:
org.apache.cassandra.distributed.test.ReadRepairTest-cassandra.testtag_IS_UNDEFINED
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec
[junit-timeout]
[junit-timeout] Testcase:
org.apache.cassandra.distributed.test.ReadRepairTest:readRepairRTRangeMovementTest-cassandra.testtag_IS_UNDEFINED:
Caused an ERROR
[junit-timeout] Forked Java VM exited abnormally. Please note the time in the
report does not reflect the time until the VM exit.
[junit-timeout] junit.framework.AssertionFailedError: Forked Java VM exited
abnormally. Please note the time in the report does not reflect the time until
the VM exit.
[junit-timeout] at
jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[junit-timeout] at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
[junit-timeout] at
jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[junit-timeout] at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit-timeout] at
jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[junit-timeout] at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit-timeout] at java.base/java.util.Vector.forEach(Vector.java:1365)
[junit-timeout] at
jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[junit-timeout] at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit-timeout] at
jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[junit-timeout] at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit-timeout]
[junit-timeout]
[junit-timeout] Test org.apache.cassandra.distributed.test.ReadRepairTest
FAILED (crashed)BUILD FAILED
{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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838166#comment-17838166
]
Maxim Muzafarov commented on CASSANDRA-14572:
-
[~maedhroz] Do you have a dump or any CI result links? The patch might increase
the heap usage a bit. While trying to keep the memory footprint low, it was
necessary to add the Map> to keep track of metric
alias names (they usually appear when a metric is renamed) and use them to
deregister the metrics when it's needed (e.g. a keyspace drop).
Due to the number of metrics, it may take some extra heap space, but shouldn't
be too much. My calculations and tests that I'd made showed that for each
metric we need ~ 10x8bytes for refs + some space for extra strings that
survive the eden gc ( e.g. ~10 symbols string 2 byte each x 6 fields) = 200
bytes for each metric. Considering 77k metrics in my tests above it will be ~
15Mb extra heap space (a JFR is attached in [the comment
above|https://issues.apache.org/jira/browse/CASSANDRA-14572?focusedCommentId=17809602=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17809602]
for the reference). I might be miscalculated something, of course.
We can create a new issue to fix that, and I'll try to find a solution for that.
As for the feature flag, I don't think it's necessary since the flag can't help
the way we handle metrics internally, plus a new keyspace and virtual tables
stand apart the core components. What we can do here in addition is to note in
the documentation that these new tables are experimental in the next upcoming
release.
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.1
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 7h 50m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-19476) CQL Management API
[
https://issues.apache.org/jira/browse/CASSANDRA-19476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837675#comment-17837675
]
Maxim Muzafarov edited comment on CASSANDRA-19476 at 4/16/24 8:20 PM:
--
I've spent some time prototyping the changes and the plan may be the following,
splitting by the issues:
# _Replace the airline with the picocli._ CASSANDRA-17445 The airlift library
is now used to expose the management commands via the CLI. We can reuse this
approach to keep the number of changes low, however, we need to replace the
library with the picocli as the airlift has drawbacks. It prevents us from
building JMX and CQL APIs in follows:
## The airlift library is no longer supported. It doesn't make sense to build
a new code on top of deprecated annotations;
## The library handles the `[ ...]` as a single input
argument, but we need to handle it independently as two input arguments
`keyspace` and `tables` to build JMX and CQL APIs;
## All commands right now have host, port, username, and password options etc.
which are not relevant to other types of public APIs;
# {_}Create an adapter that builds dynamic JMX MBeans{_}, and parses the
picocli annotations of the commands we already have. This will expose these
commands with the same parameters and options that they have in the CLI,
matching the nodetool CLI input. The management MBeans of the internal
components e.g. StorageServiceMBean can be injected into the commands directly
when the command context is initialized.
# _Create a CQL command adapter._ Based on the commands annotations we can
create a new adapter that handles command parameters received from the binary
protocol, this is basically the same as new dynamic MBeans with the caveat that
the binary protocol have to be improved to support new operation types.
Options 2 and 3 can be implemented independently.
was (Author: mmuzaf):
I've spent some time prototyping the changes and the plan may be the following,
splitting by the issues:
# _Replace the airline with the picocli._ CASSANDRA-17445 The airlift library
is now used to expose the management commands via the CLI. We can reuse this
approach to keep the number of changes low, however, we need to replace the
library with the picocli as the airlift has drawbacks. It prevents us from
building JMX and CQL APIs in follows:
## The airlift library is no longer supported;
## The library handles the `[ ...]` as a single input
argument, but we need to handle it independently as two input arguments
`keyspace` and `tables` to build JMX and CQL APIs;
## All commands right now have host, port, username, and password options etc.
which are not relevant to other types of interfaces;
# {_}Create an adapter that builds dynamic JMX MBeans{_}, and parses the
picocli annotations of the commands we already have. This will expose these
commands with the same parameters and options that they have in the CLI,
matching the nodetool CLI input. The management MBeans of the internal
components e.g. StorageServiceMBean can be injected into the commands directly
when the command context is initialized.
# _Create a CQL command adapter._ Based on the commands annotations we can
create a new adapter that handles command parameters received from the binary
protocol, this is basically the same as new dynamic MBeans with the caveat that
the binary protocol have to be improved to support new operation types.
Options 2 and 3 can be implemented independently.
> CQL Management API
> --
>
> Key: CASSANDRA-19476
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19476
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter, CQL/Syntax, Tool/nodetool
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: High
> Labels: CEP-38
> Fix For: 5.x
>
>
> We want to run management commands via CQL.
> The goals are:
> * To provide a way to run predefined management commands via CQL;
> * To provide a mechanism for retrieving command definitions and metadata via
> CQL;
> * To provide information on all available management commands via virtual
> tables;
> * To provide a registry that stores all C* commands and their metadata
> accordingly;
> * To internal instrumentation and a reasonable plan for migrating cluster
> management from JMX to CQL, taking into account backward compatibility and
> adopted deprecation policies;
> The discussion on the ML:
> https://lists.apache.org/thread/pow83q92m666nqtwyw4m3b18nnkgj2y8
> The design document:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe,
[jira] [Comment Edited] (CASSANDRA-19476) CQL Management API
[
https://issues.apache.org/jira/browse/CASSANDRA-19476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837675#comment-17837675
]
Maxim Muzafarov edited comment on CASSANDRA-19476 at 4/16/24 12:08 PM:
---
I've spent some time prototyping the changes and the plan may be the following,
splitting by the issues:
# _Replace the airline with the picocli._ CASSANDRA-17445 The airlift library
is now used to expose the management commands via the CLI. We can reuse this
approach to keep the number of changes low, however, we need to replace the
library with the picocli as the airlift has drawbacks. It prevents us from
building JMX and CQL APIs in follows:
## The airlift library is no longer supported;
## The library handles the `[ ...]` as a single input
argument, but we need to handle it independently as two input arguments
`keyspace` and `tables` to build JMX and CQL APIs;
## All commands right now have host, port, username, and password options etc.
which are not relevant to other types of interfaces;
# {_}Create an adapter that builds dynamic JMX MBeans{_}, and parses the
picocli annotations of the commands we already have. This will expose these
commands with the same parameters and options that they have in the CLI,
matching the nodetool CLI input. The management MBeans of the internal
components e.g. StorageServiceMBean can be injected into the commands directly
when the command context is initialized.
# _Create a CQL command adapter._ Based on the commands annotations we can
create a new adapter that handles command parameters received from the binary
protocol, this is basically the same as new dynamic MBeans with the caveat that
the binary protocol have to be improved to support new operation types.
Options 2 and 3 can be implemented independently.
was (Author: mmuzaf):
I've spent some time prototyping the changes and the plan may be the following,
splitting by the issues:
# _Replace the airline with the picocli._ CASSANDRA-17445 The airlift library
is now used to expose the management commands via the CLI. We can reuse this
approach to keep the number of changes low, however, we need to replace the
library with the picocli as the airlift has drawbacks. It prevents us from
building JMX and CQL APIs in follows: the airlift library is no longer
supported, the library handles the `[ ...]` as a single input
argument, but we need to handle it independently as two input arguments
`keyspace` and `tables` to build JMX and CQL APIs.
# _Create an adapter that builds dynamic JMX MBeans_, and parses the picocli
annotations of the commands we already have. This will expose these commands
with the same parameters and options that they have in the CLI, matching the
nodetool CLI input. The management MBeans of the internal components e.g.
StorageServiceMBean can be injected into the commands directly when the command
context is initialized.
# _Create a CQL command adapter._ Based on the commands annotations we can
create a new adapter that handles command parameters received from the binary
protocol, this is basically the same as new dynamic MBeans with the caveat that
the binary protocol have to be improved to support new operation types.
Options 2 and 3 can be implemented independently.
> CQL Management API
> --
>
> Key: CASSANDRA-19476
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19476
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter, CQL/Syntax, Tool/nodetool
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: High
> Labels: CEP-38
> Fix For: 5.x
>
>
> We want to run management commands via CQL.
> The goals are:
> * To provide a way to run predefined management commands via CQL;
> * To provide a mechanism for retrieving command definitions and metadata via
> CQL;
> * To provide information on all available management commands via virtual
> tables;
> * To provide a registry that stores all C* commands and their metadata
> accordingly;
> * To internal instrumentation and a reasonable plan for migrating cluster
> management from JMX to CQL, taking into account backward compatibility and
> adopted deprecation policies;
> The discussion on the ML:
> https://lists.apache.org/thread/pow83q92m666nqtwyw4m3b18nnkgj2y8
> The design document:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API
--
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-19476) CQL Management API
[ https://issues.apache.org/jira/browse/CASSANDRA-19476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837675#comment-17837675 ] Maxim Muzafarov edited comment on CASSANDRA-19476 at 4/16/24 11:18 AM: --- I've spent some time prototyping the changes and the plan may be the following, splitting by the issues: # _Replace the airline with the picocli._ CASSANDRA-17445 The airlift library is now used to expose the management commands via the CLI. We can reuse this approach to keep the number of changes low, however, we need to replace the library with the picocli as the airlift has drawbacks. It prevents us from building JMX and CQL APIs in follows: the airlift library is no longer supported, the library handles the `[ ...]` as a single input argument, but we need to handle it independently as two input arguments `keyspace` and `tables` to build JMX and CQL APIs. # _Create an adapter that builds dynamic JMX MBeans_, and parses the picocli annotations of the commands we already have. This will expose these commands with the same parameters and options that they have in the CLI, matching the nodetool CLI input. The management MBeans of the internal components e.g. StorageServiceMBean can be injected into the commands directly when the command context is initialized. # _Create a CQL command adapter._ Based on the commands annotations we can create a new adapter that handles command parameters received from the binary protocol, this is basically the same as new dynamic MBeans with the caveat that the binary protocol have to be improved to support new operation types. Options 2 and 3 can be implemented independently. was (Author: mmuzaf): I've spent some time prototyping the changes and the plan may be the following, splitting by the issues: # _Replace the airline with the picocli._ CASSANDRA-17445 The airlift library is now used to expose the management commands via the CLI. We can reuse this approach to keep the number of changes low, however, we need to replace the library with the picocli as the airlift has drawbacks. It prevents us from building JMX and CQL APIs in follows: the airlift library is no longer supported, the library handles the `[ ...]` as a single input argument, but we need to handle it independently for JMX and CQL APIs. # _Create an adapter that builds dynamic JMX MBeans_, and parses the picocli annotations of the commands we already have. This will expose these commands with the same parameters and options that they have in the CLI, matching the nodetool CLI input. The management MBeans of the internal components e.g. StorageServiceMBean can be injected into the commands directly when the command context is initialized. # _Create a CQL command adapter._ Based on the commands annotations we can create a new adapter that handles command parameters received from the binary protocol, this is basically the same as new dynamic MBeans with the caveat that the binary protocol have to be improved to support new operation types. Options 2 and 3 can be implemented independently. > CQL Management API > -- > > Key: CASSANDRA-19476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19476 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter, CQL/Syntax, Tool/nodetool >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: High > Labels: CEP-38 > Fix For: 5.x > > > We want to run management commands via CQL. > The goals are: > * To provide a way to run predefined management commands via CQL; > * To provide a mechanism for retrieving command definitions and metadata via > CQL; > * To provide information on all available management commands via virtual > tables; > * To provide a registry that stores all C* commands and their metadata > accordingly; > * To internal instrumentation and a reasonable plan for migrating cluster > management from JMX to CQL, taking into account backward compatibility and > adopted deprecation policies; > The discussion on the ML: > https://lists.apache.org/thread/pow83q92m666nqtwyw4m3b18nnkgj2y8 > The design document: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API -- 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-19476) CQL Management API
[ https://issues.apache.org/jira/browse/CASSANDRA-19476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837675#comment-17837675 ] Maxim Muzafarov commented on CASSANDRA-19476: - I've spent some time prototyping the changes and the plan may be the following, splitting by the issues: # _Replace the airline with the picocli._ CASSANDRA-17445 The airlift library is now used to expose the management commands via the CLI. We can reuse this approach to keep the number of changes low, however, we need to replace the library with the picocli as the airlift has drawbacks. It prevents us from building JMX and CQL APIs in follows: the airlift library is no longer supported, the library handles the `[ ...]` as a single input argument, but we need to handle it independently for JMX and CQL APIs. # _Create an adapter that builds dynamic JMX MBeans_, and parses the picocli annotations of the commands we already have. This will expose these commands with the same parameters and options that they have in the CLI, matching the nodetool CLI input. The management MBeans of the internal components e.g. StorageServiceMBean can be injected into the commands directly when the command context is initialized. # _Create a CQL command adapter._ Based on the commands annotations we can create a new adapter that handles command parameters received from the binary protocol, this is basically the same as new dynamic MBeans with the caveat that the binary protocol have to be improved to support new operation types. Options 2 and 3 can be implemented independently. > CQL Management API > -- > > Key: CASSANDRA-19476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19476 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter, CQL/Syntax, Tool/nodetool >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: High > Labels: CEP-38 > Fix For: 5.x > > > We want to run management commands via CQL. > The goals are: > * To provide a way to run predefined management commands via CQL; > * To provide a mechanism for retrieving command definitions and metadata via > CQL; > * To provide information on all available management commands via virtual > tables; > * To provide a registry that stores all C* commands and their metadata > accordingly; > * To internal instrumentation and a reasonable plan for migrating cluster > management from JMX to CQL, taking into account backward compatibility and > adopted deprecation policies; > The discussion on the ML: > https://lists.apache.org/thread/pow83q92m666nqtwyw4m3b18nnkgj2y8 > The design document: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API -- 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-19476) CQL Management API
[ https://issues.apache.org/jira/browse/CASSANDRA-19476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-19476: Component/s: CQL/Interpreter Tool/nodetool > CQL Management API > -- > > Key: CASSANDRA-19476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19476 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter, CQL/Syntax, Tool/nodetool >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: High > Labels: CEP-38 > Fix For: 5.x > > > We want to run management commands via CQL. > The goals are: > * To provide a way to run predefined management commands via CQL; > * To provide a mechanism for retrieving command definitions and metadata via > CQL; > * To provide information on all available management commands via virtual > tables; > * To provide a registry that stores all C* commands and their metadata > accordingly; > * To internal instrumentation and a reasonable plan for migrating cluster > management from JMX to CQL, taking into account backward compatibility and > adopted deprecation policies; > The discussion on the ML: > https://lists.apache.org/thread/pow83q92m666nqtwyw4m3b18nnkgj2y8 > The design document: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API -- 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-19486) enrich system_views.pending_hints with hints sizes
[ https://issues.apache.org/jira/browse/CASSANDRA-19486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833996#comment-17833996 ] Maxim Muzafarov commented on CASSANDRA-19486: - [~smiklosovic] I'll take a look, sorry for the delay! > enrich system_views.pending_hints with hints sizes > -- > > Key: CASSANDRA-19486 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19486 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Hints >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 50m > Remaining Estimate: 0h > > I am happy to close this if somebody shows me how to get total size of all > hints or all hints per particular node via JMX. > I could find StorageMetrics.totalHints but that is how many hints there are, > not their sizes. We also have > org.apache.cassandra.metrics:type=HintedHandOffManager name= > org.apache.cassandra.metrics:type=HintsService name= > But that is again showing other metrics not sizes. > I would add two methods into HintsServiceMBean returning this. Seems to be > very easy to do once we do CASSANDRA-19477. -- 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-19486) enrich system_views.pending_hints with hints sizes
[ https://issues.apache.org/jira/browse/CASSANDRA-19486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-19486: Reviewers: Maxim Muzafarov > enrich system_views.pending_hints with hints sizes > -- > > Key: CASSANDRA-19486 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19486 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Hints >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 50m > Remaining Estimate: 0h > > I am happy to close this if somebody shows me how to get total size of all > hints or all hints per particular node via JMX. > I could find StorageMetrics.totalHints but that is how many hints there are, > not their sizes. We also have > org.apache.cassandra.metrics:type=HintedHandOffManager name= > org.apache.cassandra.metrics:type=HintsService name= > But that is again showing other metrics not sizes. > I would add two methods into HintsServiceMBean returning this. Seems to be > very easy to do once we do CASSANDRA-19477. -- 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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-14572:
Fix Version/s: 5.1
(was: 5.x)
Source Control Link:
https://github.com/apache/cassandra/commit/2e7def7626fe299318e0cf4c2bf8138a6c31e149
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
In addition, all the tests have been verified locally.
I ran the single-node cluster locally and checked all the added virtual tables.
The changes have been merged into the trunk branch.
Thank you everyone for all the reviews and comments.
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.1
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 7h 40m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833682#comment-17833682
]
Maxim Muzafarov commented on CASSANDRA-14572:
-
Rebased the patch at the top of the trunk branch, new test results are here:
https://app.circleci.com/pipelines/github/driftx/cassandra/1561/workflows/98e55dfa-07d2-4b31-a8dd-2327d84de7b9
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 7h 40m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-19502) PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties
[ https://issues.apache.org/jira/browse/CASSANDRA-19502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-19502: Fix Version/s: 5.1 (was: 5.x) Since Version: 5.x Source Control Link: https://github.com/apache/cassandra/commit/154ef814bd2b7cf5290bf5f94484dd077b442449 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed to the trunk. [~claude] Thank you for your contribution. > PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties > - > > Key: CASSANDRA-19502 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19502 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Normal > Fix For: 5.1 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > While this is not an issue for CI test or other items that replace the file > on a development system the file is left in its modified state and under risk > of being accidentally checked into the repository. -- 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-19502) PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties
[ https://issues.apache.org/jira/browse/CASSANDRA-19502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-19502: Reviewers: Brandon Williams, Maxim Muzafarov (was: Maxim Muzafarov) > PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties > - > > Key: CASSANDRA-19502 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19502 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > While this is not an issue for CI test or other items that replace the file > on a development system the file is left in its modified state and under risk > of being accidentally checked into the repository. -- 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-19502) PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties
[ https://issues.apache.org/jira/browse/CASSANDRA-19502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-19502: Status: Ready to Commit (was: Review In Progress) > PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties > - > > Key: CASSANDRA-19502 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19502 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > While this is not an issue for CI test or other items that replace the file > on a development system the file is left in its modified state and under risk > of being accidentally checked into the repository. -- 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-19502) PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties
[ https://issues.apache.org/jira/browse/CASSANDRA-19502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833534#comment-17833534 ] Maxim Muzafarov commented on CASSANDRA-19502: - [~brandon.williams] thanks Brandon, looks like the tests have passed. Are you +1 too ? :-) > PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties > - > > Key: CASSANDRA-19502 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19502 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > While this is not an issue for CI test or other items that replace the file > on a development system the file is left in its modified state and under risk > of being accidentally checked into the repository. -- 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-19502) PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties
[ https://issues.apache.org/jira/browse/CASSANDRA-19502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833525#comment-17833525 ] Maxim Muzafarov commented on CASSANDRA-19502: - j17: https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/623/workflows/7ef17f66-df13-44cf-92a6-ed856d7e30ac j11: https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/623/workflows/03e77259-9da0-4adf-9ad2-9cb771bae1fe > PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties > - > > Key: CASSANDRA-19502 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19502 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > While this is not an issue for CI test or other items that replace the file > on a development system the file is left in its modified state and under risk > of being accidentally checked into the repository. -- 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-19502) PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties
[ https://issues.apache.org/jira/browse/CASSANDRA-19502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833519#comment-17833519 ] Maxim Muzafarov commented on CASSANDRA-19502: - I reviewed the changes, LGTM. > PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties > - > > Key: CASSANDRA-19502 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19502 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > While this is not an issue for CI test or other items that replace the file > on a development system the file is left in its modified state and under risk > of being accidentally checked into the repository. -- 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-19502) PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties
[ https://issues.apache.org/jira/browse/CASSANDRA-19502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-19502: Status: Needs Committer (was: Patch Available) > PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties > - > > Key: CASSANDRA-19502 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19502 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Normal > Time Spent: 1h 10m > Remaining Estimate: 0h > > While this is not an issue for CI test or other items that replace the file > on a development system the file is left in its modified state and under risk > of being accidentally checked into the repository. -- 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-19502) PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties
[ https://issues.apache.org/jira/browse/CASSANDRA-19502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-19502: Bug Category: Parent values: Correctness(12982) Complexity: Low Hanging Fruit Component/s: Test/unit Discovered By: Unit Test Severity: Low Status: Open (was: Triage Needed) > PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties > - > > Key: CASSANDRA-19502 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19502 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Normal > Time Spent: 1h 10m > Remaining Estimate: 0h > > While this is not an issue for CI test or other items that replace the file > on a development system the file is left in its modified state and under risk > of being accidentally checked into the repository. -- 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-19502) PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties
[ https://issues.apache.org/jira/browse/CASSANDRA-19502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-19502: Fix Version/s: 5.x > PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties > - > > Key: CASSANDRA-19502 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19502 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > While this is not an issue for CI test or other items that replace the file > on a development system the file is left in its modified state and under risk > of being accidentally checked into the repository. -- 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-19502) PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties
[ https://issues.apache.org/jira/browse/CASSANDRA-19502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-19502: Test and Documentation Plan: Run `ant test` locally. Status: Patch Available (was: Open) > PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties > - > > Key: CASSANDRA-19502 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19502 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Normal > Time Spent: 1h 10m > Remaining Estimate: 0h > > While this is not an issue for CI test or other items that replace the file > on a development system the file is left in its modified state and under risk > of being accidentally checked into the repository. -- 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-19502) PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties
[ https://issues.apache.org/jira/browse/CASSANDRA-19502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-19502: Reviewers: Maxim Muzafarov > PropertyFileSnitchTest overwrites test/conf/cassandra-topology.properties > - > > Key: CASSANDRA-19502 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19502 > Project: Cassandra > Issue Type: Bug >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Normal > Time Spent: 1h 10m > Remaining Estimate: 0h > > While this is not an issue for CI test or other items that replace the file > on a development system the file is left in its modified state and under risk > of being accidentally checked into the repository. -- 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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-14572:
Reviewers: Chris Lohfink, Stefan Miklosovic (was: Aleksey Yeschenko,
Stefan Miklosovic)
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 7h 40m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-14572:
Status: Ready to Commit (was: Review In Progress)
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 7h 40m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830990#comment-17830990
]
Maxim Muzafarov commented on CASSANDRA-14572:
-
Thanks to Brandon for running the tests:
j17
https://app.circleci.com/pipelines/github/driftx/cassandra/1539/workflows/31fe6cd5-e653-46f3-b44c-113568e275cf
j11
https://app.circleci.com/pipelines/github/driftx/cassandra/1539/workflows/fe10e6be-7095-4f13-94fa-ccb0c9cd2555/jobs/79506/parallel-runs/20
gossip_test.py::TestGossip::test_assassinate_valid_node -> CASSANDRA-18753
org.apache.cassandra.tcm.DiscoverySimulationTest -> I think, the test failed
because of the network glitch (passes locally a few times)
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest ->
CASSANDRA-19281
The other seems to be just fine.
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 7h 40m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-18753) Add an optimized default configuration to tests and make it available for new users
[
https://issues.apache.org/jira/browse/CASSANDRA-18753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830932#comment-17830932
]
Maxim Muzafarov commented on CASSANDRA-18753:
-
Sorry, if I got the status of the changes wrong. I haven't followed the
discussion.
The changes have been merged into the trunk, but the issue is still unresolved
and only points to the 5.0.x (the commit message refers to this issue). I think
there is a mistake here, right? (the changes should be either rollbacked or the
issue must have the right status).
[https://github.com/apache/cassandra/commit/06ed1afc34128523298020e7601dad148f2b2fb6]
It's also worth mentioning that some of the dtests are broken due to the
changes in the trunk branch.
It can be reproduced locally with a 100% chance.
{code:java}
memtable:
configurations:
skiplist:
class_name: SkipListMemtable
trie:
class_name: TrieMemtable
default:
inherits: skiplist
{code}
For example, the broken test (the trunk branch in the main project and the
trunk branch in the dtests are used):
{code:java}
pytest --cassandra-dir=/Users/mm/IdeaProjects/cassandra
gossip_test.py::TestGossip::test_assassinate_valid_node
{code}
The exception:
{code:java}
node1: ERROR [main] 2024-03-26 13:27:38,909 CassandraDaemon.java:900 -
Exception encountered during startup
java.lang.ExceptionInInitializerError: null
at
org.apache.cassandra.schema.TableParams$Builder.(TableParams.java:362)
at org.apache.cassandra.schema.TableParams.builder(TableParams.java:127)
at
org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:60)
at
org.apache.cassandra.cql3.statements.schema.CreateTableStatement.builder(CreateTableStatement.java:196)
at
org.apache.cassandra.cql3.statements.schema.CreateTableStatement.parse(CreateTableStatement.java:474)
at
org.apache.cassandra.schema.SchemaKeyspace.parse(SchemaKeyspace.java:278)
at
org.apache.cassandra.schema.SchemaKeyspace.(SchemaKeyspace.java:92)
at org.apache.cassandra.schema.Schema.initialize(Schema.java:77)
at org.apache.cassandra.schema.Schema.(Schema.java:72)
at org.apache.cassandra.db.Keyspace.setInitialized(Keyspace.java:124)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:261)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:728)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)
Caused by: org.apache.cassandra.exceptions.ConfigurationException:
Configuration definition inherits unknown skiplist. A configuration can only
extend one defined earlier or "default".
at
org.apache.cassandra.config.InheritingClass.resolve(InheritingClass.java:54)
at
org.apache.cassandra.schema.MemtableParams.expandDefinitions(MemtableParams.java:151)
at
org.apache.cassandra.schema.MemtableParams.(MemtableParams.java:101)
... 13 common frames omitted
{code}
Posting the stacktrace for visibility.
> Add an optimized default configuration to tests and make it available for new
> users
> ---
>
> Key: CASSANDRA-18753
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18753
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Branimir Lambov
>Assignee: Branimir Lambov
>Priority: Urgent
> Fix For: 5.0-rc, 5.x
>
> Attachments:
> CCM_Add_support_for_specifying_the_name_of_the_file_to_use_as_cassandra_YAML_.patch,
>
> DTEST_Add_support_for_specifying_the_name_of_the_file_to_use_as_cassandra_YAML_.patch
>
> Time Spent: 12h 20m
> Remaining Estimate: 0h
>
> We currently offer only one sample configuration file with Cassandra, and
> that file is deliberately configured to disable all new functionality and
> incompatible improvements. This works well for legacy users that want to have
> a painless upgrade, but is a very bad choice for new users, or anyone wanting
> to make comparisons between Cassandra versions or between Cassandra and other
> databases.
> We offer very little indication, in the database packaging itself, that there
> are well-tested configuration choices that can solve known problems and
> dramatically improve performance. This is guaranteed to paint the database in
> a worse light than it deserves, and will very likely hurt adoption.
> We should find a way to offer a very easy way of choosing between "optimized"
> and "compatible" defaults. At minimal, we could provide alternate yaml files.
> Alternatively, we could build on the {{storage_compatibility_mode}} concept
> to grow it into a setting that not only enables/disables certain settings,
>
[jira] [Updated] (CASSANDRA-13855) Implement Http Seed provider
[ https://issues.apache.org/jira/browse/CASSANDRA-13855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-13855: Reviewers: Jon Haddad, Maxim Muzafarov, Stefan Miklosovic (was: Jacek Lewandowski, Jon Haddad, Stefan Miklosovic) Status: Review In Progress (was: Needs Committer) > Implement Http Seed provider > > > Key: CASSANDRA-13855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13855 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination, Legacy/Core >Reporter: Jon Haddad >Assignee: Claude Warren >Priority: Low > Labels: lhf > Fix For: 5.x > > Attachments: 0001-Add-URL-Seed-Provider-trunk.txt, signature.asc, > signature.asc, signature.asc > > Time Spent: 4.5h > Remaining Estimate: 0h > > Seems like including a dead simple seed provider that can fetch from a URL, 1 > line per seed, would be useful. -- 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-13855) Implement Http Seed provider
[ https://issues.apache.org/jira/browse/CASSANDRA-13855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-13855: Status: Changes Suggested (was: Review In Progress) > Implement Http Seed provider > > > Key: CASSANDRA-13855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13855 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination, Legacy/Core >Reporter: Jon Haddad >Assignee: Claude Warren >Priority: Low > Labels: lhf > Fix For: 5.x > > Attachments: 0001-Add-URL-Seed-Provider-trunk.txt, signature.asc, > signature.asc, signature.asc > > Time Spent: 4.5h > Remaining Estimate: 0h > > Seems like including a dead simple seed provider that can fetch from a URL, 1 > line per seed, would be useful. -- 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-19332) Dropwizard Meter causes timeouts when infrequently used
[
https://issues.apache.org/jira/browse/CASSANDRA-19332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830659#comment-17830659
]
Maxim Muzafarov commented on CASSANDRA-19332:
-
My +1 here as well.
> Dropwizard Meter causes timeouts when infrequently used
> ---
>
> Key: CASSANDRA-19332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19332
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0, 5.1
>
> Attachments: ci_summary_4.1.html, ci_summary_5.0.html,
> ci_summary_trunk.html, result_details_4.1.tar.gz, result_details_5.0.tar.gz,
> result_details_trunk.tar.gz
>
>
> Observed instances of timeouts on clusters with long uptime and infrequently
> used tables and possibly just request paths such as not using CAS for large
> fractions of a year.
> CAS seems to be more severely impacted because it has more metrics in the
> request path such as latency measurements for prepare, propose, and the read
> from the underlying table.
> Tracing showed ~600-800 milliseconds for these operations in between the
> “appending to memtable” and “sending a response” events. Reads had a delay
> between finishing the construction of the iterator and sending the read
> response.
> Stack traces dumped every 100 milliseconds using {{sjk}} shows that in
> prepare and propose a lot of time was being spent in
> {{{}Meter.tickIfNecessary{}}}.
> {code:java}
> Thread [2537] RUNNABLE at 2024-01-25T21:14:48.218 - MutationStage-2
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:71)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.prepare(PaxosState.java:92)
> Thread [2539] RUNNABLE at 2024-01-25T21:14:48.520 - MutationStage-4
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:72)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.propose(PaxosState.java:127){code}
> {{tickIfNecessary}} does a linear amount of work proportional to the time
> since the last time the metric was updated/read/created and this can actually
> take a measurable amount of time even in a tight loop. On my M2 MBP it was
> 1.5 milliseconds for a day, ~200 days took ~74 milliseconds. Before it warmed
> up it was 140 milliseconds.
> A quick fix is to schedule a task to read all the meters once a day so it
> isn’t done in the request path and we have a more incremental amount to
> process at a time.
> Also observed that {{tickIfNecessary}} is not 100% thread safe in that if it
> takes longer than 5 seconds to run the loop it can end up with multiple
> threads attempting to run the loop at once and then they will concurrently
> run {{EWMA.tick}} which probably results in some ticks not being performed.
> This issue is still present in the latest version of {{Metrics}} if using
> {{{}EWMA{}}}, but {{SlidingWindowTimeAverages}} looks like it has a bounded
> amount of work required to tick. Switching would change how our metrics work
> since the two don't have the same behavior.
--
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-13855) Implement Http Seed provider
[ https://issues.apache.org/jira/browse/CASSANDRA-13855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830597#comment-17830597 ] Maxim Muzafarov edited comment on CASSANDRA-13855 at 3/25/24 4:59 PM: -- I've left some comments on the PR. was (Author: mmuzaf): I've lest some comments to the PR. > Implement Http Seed provider > > > Key: CASSANDRA-13855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13855 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination, Legacy/Core >Reporter: Jon Haddad >Assignee: Claude Warren >Priority: Low > Labels: lhf > Fix For: 5.x > > Attachments: 0001-Add-URL-Seed-Provider-trunk.txt, signature.asc, > signature.asc, signature.asc > > Time Spent: 4h > Remaining Estimate: 0h > > Seems like including a dead simple seed provider that can fetch from a URL, 1 > line per seed, would be useful. -- 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-13855) Implement Http Seed provider
[ https://issues.apache.org/jira/browse/CASSANDRA-13855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830597#comment-17830597 ] Maxim Muzafarov commented on CASSANDRA-13855: - I've lest some comments to the PR. > Implement Http Seed provider > > > Key: CASSANDRA-13855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13855 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Coordination, Legacy/Core >Reporter: Jon Haddad >Assignee: Claude Warren >Priority: Low > Labels: lhf > Fix For: 5.x > > Attachments: 0001-Add-URL-Seed-Provider-trunk.txt, signature.asc, > signature.asc, signature.asc > > Time Spent: 4h > Remaining Estimate: 0h > > Seems like including a dead simple seed provider that can fetch from a URL, 1 > line per seed, would be useful. -- 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-13855) Implement Http Seed provider
[
https://issues.apache.org/jira/browse/CASSANDRA-13855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829900#comment-17829900
]
Maxim Muzafarov commented on CASSANDRA-13855:
-
As I said I have nothing against the HttpSeedProvider, I'll review the current
changes.
Regarding Cloud SeedProviders, I think it should be possible to get a node tag
from the pod metadata in json format as we do now, so we probably don't need to
add any extra dependencies. Once each the seed metadata info is initialized, we
can put that in the ClusterMetadata as we did it for the rack parameter, this
should work, however I haven't tried implementing it on my end.
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/AbstractCloudMetadataServiceSnitch.java#L72
{code}
if (endpoint.equals(FBUtilities.getBroadcastAddressAndPort()))
return getLocalRack();
ClusterMetadata metadata = ClusterMetadata.current();
NodeId nodeId = metadata.directory.peerId(endpoint);
if (nodeId == null)
return DEFAULT_RACK;
return metadata.directory.location(nodeId).rack;
{code}
I'm going to create an issue so we don't mix it up here.
> Implement Http Seed provider
>
>
> Key: CASSANDRA-13855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13855
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Coordination, Legacy/Core
>Reporter: Jon Haddad
>Assignee: Claude Warren
>Priority: Low
> Labels: lhf
> Fix For: 5.x
>
> Attachments: 0001-Add-URL-Seed-Provider-trunk.txt, signature.asc,
> signature.asc, signature.asc
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Seems like including a dead simple seed provider that can fetch from a URL, 1
> line per seed, would be useful.
--
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-13855) Implement Http Seed provider
[
https://issues.apache.org/jira/browse/CASSANDRA-13855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829689#comment-17829689
]
Maxim Muzafarov commented on CASSANDRA-13855:
-
Hey,
I've checked the implementation and I'd like to throw a new idea on the table.
I have nothing against the HttpSeedProvider itself, but I guess for the end
user it is more interesting to have cloud-related stuff that they are already
configured with (the same as we provide for the snitches - Azure, EC2, Google).
Here are the SeedProviders that can be found on the GitHub:
https://github.com/search?q=SeedProvider=repositories
So, I guess we don't need to create a parallel hierarchy of classes for the
SeedProvider interface and can do the following:
# Either extend the IEndpointSnitch or create a new interface new a new :
{code}
public String getRack(InetAddressAndPort endpoint);
public String getDatacenter(InetAddressAndPort endpoint);
/** {@code true} if the endpoint is the seed node. */
default public boolean isSeed(InetAddressAndPort endpoint) {};
{code}
# Implement a new {{isSeed}} method for each cloud adapter we are interested in
e.g. EC2, Azure, Google etc. that fetches the seed status from a tag.
https://github.com/kryptnostic/ec2-cassandra-seedprovider/blob/master/src/main/java/com/kryptnostic/Ec2SeedProvider.java#L35
# Create a new adapter that implements the SeedProvider interface and wraps the
{{IEndpointSnitch}} e.g. new CloudSeedProvider(IEndpointSnitch snitch).
WDYT?
> Implement Http Seed provider
>
>
> Key: CASSANDRA-13855
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13855
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Coordination, Legacy/Core
>Reporter: Jon Haddad
>Assignee: Claude Warren
>Priority: Low
> Labels: lhf
> Fix For: 5.x
>
> Attachments: 0001-Add-URL-Seed-Provider-trunk.txt, signature.asc,
> signature.asc, signature.asc
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Seems like including a dead simple seed provider that can fetch from a URL, 1
> line per seed, would be useful.
--
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-19476) CQL Management API
[ https://issues.apache.org/jira/browse/CASSANDRA-19476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-19476: Labels: CEP-38 (was: ) > CQL Management API > -- > > Key: CASSANDRA-19476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19476 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Syntax >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: High > Labels: CEP-38 > Fix For: 5.x > > > We want to run management commands via CQL. > The goals are: > * To provide a way to run predefined management commands via CQL; > * To provide a mechanism for retrieving command definitions and metadata via > CQL; > * To provide information on all available management commands via virtual > tables; > * To provide a registry that stores all C* commands and their metadata > accordingly; > * To internal instrumentation and a reasonable plan for migrating cluster > management from JMX to CQL, taking into account backward compatibility and > adopted deprecation policies; > The discussion on the ML: > https://lists.apache.org/thread/pow83q92m666nqtwyw4m3b18nnkgj2y8 > The design document: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API -- 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-19476) CQL Management API
[ https://issues.apache.org/jira/browse/CASSANDRA-19476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-19476: Change Category: Operability Complexity: Challenging Fix Version/s: 5.x Priority: High (was: Normal) Status: Open (was: Triage Needed) > CQL Management API > -- > > Key: CASSANDRA-19476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19476 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Syntax >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: High > Fix For: 5.x > > > We want to run management commands via CQL. > The goals are: > * To provide a way to run predefined management commands via CQL; > * To provide a mechanism for retrieving command definitions and metadata via > CQL; > * To provide information on all available management commands via virtual > tables; > * To provide a registry that stores all C* commands and their metadata > accordingly; > * To internal instrumentation and a reasonable plan for migrating cluster > management from JMX to CQL, taking into account backward compatibility and > adopted deprecation policies; > The discussion on the ML: > https://lists.apache.org/thread/pow83q92m666nqtwyw4m3b18nnkgj2y8 > The design document: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API -- 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-19476) CQL Management API
Maxim Muzafarov created CASSANDRA-19476: --- Summary: CQL Management API Key: CASSANDRA-19476 URL: https://issues.apache.org/jira/browse/CASSANDRA-19476 Project: Cassandra Issue Type: Improvement Components: CQL/Syntax Reporter: Maxim Muzafarov Assignee: Maxim Muzafarov We want to run management commands via CQL. The goals are: * To provide a way to run predefined management commands via CQL; * To provide a mechanism for retrieving command definitions and metadata via CQL; * To provide information on all available management commands via virtual tables; * To provide a registry that stores all C* commands and their metadata accordingly; * To internal instrumentation and a reasonable plan for migrating cluster management from JMX to CQL, taking into account backward compatibility and adopted deprecation policies; The discussion on the ML: https://lists.apache.org/thread/pow83q92m666nqtwyw4m3b18nnkgj2y8 The design document: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API -- 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-19447) Register the measurements of the bootstrap as Dropwizard metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19447:
Fix Version/s: 5.1
(was: 5.x)
Source Control Link:
https://github.com/apache/cassandra/commit/81a2cb782eed932961b0c89fbd40199c7269c662
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Verified repeated run locally against the trunk branch, everything passes. I've
also checked the {{FailedBootstapTest}} on the trunk branch without my changes
and on the PR branch, so it passes all the time in both cases.
The patch merged here:
https://github.com/apache/cassandra/commit/81a2cb782eed932961b0c89fbd40199c7269c662
[~smiklosovic] Thank you for the review.
> Register the measurements of the bootstrap as Dropwizard metrics
>
>
> Key: CASSANDRA-19447
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19447
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/JMX, Observability/Metrics
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 5.1
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently, we can view the node's bootstrap state in the following ways:
> - via the nodetool cli tool, e.g. by running the "resume" command;
> - querying the bootstrapped column of the system_veis.local virtual table;
> In addition, we can also expose the status and state of the node's bootstrap
> via JMX. This is used by third-party tools that rely entirely on the JMX API
> and don't have access to the CQL interface. The operator will be able to get
> all the information they need from the dashboards without having to use CLIs.
--
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-19447) Register the measurements of the bootstrap as Dropwizard metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-19447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824393#comment-17824393 ] Maxim Muzafarov edited comment on CASSANDRA-19447 at 3/7/24 3:58 PM: - Fixed all the comments. Tests: j17 https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/610/workflows/f898c14b-b248-4579-9c80-3de79f3ee505 j11 https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/610/workflows/40feba6e-3bae-43c3-b1ec-6e6c7e82f254 was (Author: mmuzaf): Fixed all the comments. Tests: https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/610/workflows/f898c14b-b248-4579-9c80-3de79f3ee505 > Register the measurements of the bootstrap as Dropwizard metrics > > > Key: CASSANDRA-19447 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19447 > Project: Cassandra > Issue Type: Improvement > Components: Observability/JMX, Observability/Metrics >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > Currently, we can view the node's bootstrap state in the following ways: > - via the nodetool cli tool, e.g. by running the "resume" command; > - querying the bootstrapped column of the system_veis.local virtual table; > In addition, we can also expose the status and state of the node's bootstrap > via JMX. This is used by third-party tools that rely entirely on the JMX API > and don't have access to the CQL interface. The operator will be able to get > all the information they need from the dashboards without having to use CLIs. -- 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-19447) Register the measurements of the bootstrap as Dropwizard metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-19447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824393#comment-17824393 ] Maxim Muzafarov commented on CASSANDRA-19447: - Fixed all the comments. Tests: https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/610/workflows/f898c14b-b248-4579-9c80-3de79f3ee505 > Register the measurements of the bootstrap as Dropwizard metrics > > > Key: CASSANDRA-19447 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19447 > Project: Cassandra > Issue Type: Improvement > Components: Observability/JMX, Observability/Metrics >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Time Spent: 1h > Remaining Estimate: 0h > > Currently, we can view the node's bootstrap state in the following ways: > - via the nodetool cli tool, e.g. by running the "resume" command; > - querying the bootstrapped column of the system_veis.local virtual table; > In addition, we can also expose the status and state of the node's bootstrap > via JMX. This is used by third-party tools that rely entirely on the JMX API > and don't have access to the CQL interface. The operator will be able to get > all the information they need from the dashboards without having to use CLIs. -- 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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823214#comment-17823214
]
Maxim Muzafarov commented on CASSANDRA-14572:
-
[~smiklosovic] I agree, no need to commit the script to the patch itself. I was
thinking of putting it here in the comments, or on the gist. That way everyone
can use it.
Anyway, thank you for the comments, I've fixed all of them.
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 7h
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821847#comment-17821847
]
Maxim Muzafarov commented on CASSANDRA-14572:
-
Hello [~smiklosovic], thank you for your comments. I'm also in favour of the
simple plain approach without incorporating the annotation processor build
logic into the build process. I have fixed your suggestions based on the given
branch.
https://github.com/apache/cassandra/pull/3152/files (the link was fixed to the
PR from a fork).
I wouldn't go into coupling the CounterMetricRow and
RowWalker classes, as it has no benefit other than saving
lines of code. Merging these classes results in a tedious implementation each
time a new representation is required, and it is also less error-prone as we
have to keep the metadata in sync.
I'm not holding out for this particular implementation, but since we've removed
the annotation processor, we'd better add a shell script next to this PR (in a
JIRA comment or somewhere on the GitHub) that helps to generate these "walkers".
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820831#comment-17820831
]
Maxim Muzafarov edited comment on CASSANDRA-14572 at 2/28/24 6:06 PM:
--
These pull requests compare approaches with and without the annotation
processor (the diff in the source code lines is not too big).
With the annotation processor:
https://github.com/apache/cassandra/pull/2958/files
+3,646 −419
Without the annotation processor:
https://github.com/apache/cassandra/pull/3152/files
+3,884 −418
was (Author: mmuzaf):
These pull requests compare approaches with and without the annotation
processor (the diff in the source code lines is not too big).
With the annotation processor:
https://github.com/apache/cassandra/pull/2958/files
+3,646 −419
Without the annotation processor:
https://github.com/apache/cassandra/pull/3137/files
+3,884 −418
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-19447) Register the measurements of the bootstrap as Dropwizard metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-19447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821749#comment-17821749 ] Maxim Muzafarov commented on CASSANDRA-19447: - Run tests here: https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/592/workflows/e6d73c3c-45cb-4cfc-83e4-5fa75b7cff37 > Register the measurements of the bootstrap as Dropwizard metrics > > > Key: CASSANDRA-19447 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19447 > Project: Cassandra > Issue Type: Improvement > Components: Observability/JMX, Observability/Metrics >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, we can view the node's bootstrap state in the following ways: > - via the nodetool cli tool, e.g. by running the "resume" command; > - querying the bootstrapped column of the system_veis.local virtual table; > In addition, we can also expose the status and state of the node's bootstrap > via JMX. This is used by third-party tools that rely entirely on the JMX API > and don't have access to the CQL interface. The operator will be able to get > all the information they need from the dashboards without having to use CLIs. -- 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-19447) Register the measurements of the bootstrap as Dropwizard metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-19447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-19447: Test and Documentation Plan: Run BootstrapTest and FailedBootstrapTest which are a part of the patch. Run CI Status: Patch Available (was: Open) > Register the measurements of the bootstrap as Dropwizard metrics > > > Key: CASSANDRA-19447 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19447 > Project: Cassandra > Issue Type: Improvement > Components: Observability/JMX, Observability/Metrics >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently, we can view the node's bootstrap state in the following ways: > - via the nodetool cli tool, e.g. by running the "resume" command; > - querying the bootstrapped column of the system_veis.local virtual table; > In addition, we can also expose the status and state of the node's bootstrap > via JMX. This is used by third-party tools that rely entirely on the JMX API > and don't have access to the CQL interface. The operator will be able to get > all the information they need from the dashboards without having to use CLIs. -- 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-19447) Register the measurements of the bootstrap as Dropwizard metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-19447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-19447: Fix Version/s: 5.x > Register the measurements of the bootstrap as Dropwizard metrics > > > Key: CASSANDRA-19447 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19447 > Project: Cassandra > Issue Type: Improvement > Components: Observability/JMX, Observability/Metrics >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, we can view the node's bootstrap state in the following ways: > - via the nodetool cli tool, e.g. by running the "resume" command; > - querying the bootstrapped column of the system_veis.local virtual table; > In addition, we can also expose the status and state of the node's bootstrap > via JMX. This is used by third-party tools that rely entirely on the JMX API > and don't have access to the CQL interface. The operator will be able to get > all the information they need from the dashboards without having to use CLIs. -- 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-19447) Register the measurements of the bootstrap as Dropwizard metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-19447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-19447: Change Category: Operability Complexity: Normal Component/s: Observability/JMX Observability/Metrics Status: Open (was: Triage Needed) > Register the measurements of the bootstrap as Dropwizard metrics > > > Key: CASSANDRA-19447 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19447 > Project: Cassandra > Issue Type: Improvement > Components: Observability/JMX, Observability/Metrics >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Currently, we can view the node's bootstrap state in the following ways: > - via the nodetool cli tool, e.g. by running the "resume" command; > - querying the bootstrapped column of the system_veis.local virtual table; > In addition, we can also expose the status and state of the node's bootstrap > via JMX. This is used by third-party tools that rely entirely on the JMX API > and don't have access to the CQL interface. The operator will be able to get > all the information they need from the dashboards without having to use CLIs. -- 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-19447) Register the measurements of the bootstrap as Dropwizard metrics
Maxim Muzafarov created CASSANDRA-19447: --- Summary: Register the measurements of the bootstrap as Dropwizard metrics Key: CASSANDRA-19447 URL: https://issues.apache.org/jira/browse/CASSANDRA-19447 Project: Cassandra Issue Type: Improvement Reporter: Maxim Muzafarov Assignee: Maxim Muzafarov Currently, we can view the node's bootstrap state in the following ways: - via the nodetool cli tool, e.g. by running the "resume" command; - querying the bootstrapped column of the system_veis.local virtual table; In addition, we can also expose the status and state of the node's bootstrap via JMX. This is used by third-party tools that rely entirely on the JMX API and don't have access to the CQL interface. The operator will be able to get all the information they need from the dashboards without having to use CLIs. -- 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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820831#comment-17820831
]
Maxim Muzafarov commented on CASSANDRA-14572:
-
These pull requests compare approaches with and without the annotation
processor (the diff in the source code lines is not too big).
With the annotation processor:
https://github.com/apache/cassandra/pull/2958/files
+3,646 −419
Without the annotation processor:
https://github.com/apache/cassandra/pull/3137/files
+3,884 −418
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-17062) Refactor structure of caching metrics to weighted and unweighted
[ https://issues.apache.org/jira/browse/CASSANDRA-17062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815326#comment-17815326 ] Maxim Muzafarov commented on CASSANDRA-17062: - I've reviewed the changes [1], +1 LGMT [1] https://github.com/apache/cassandra/pull/3002 > Refactor structure of caching metrics to weighted and unweighted > - > > Key: CASSANDRA-17062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17062 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables, Observability/Metrics, > Tool/nodetool >Reporter: Aleksei Zotov >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 7h 50m > Remaining Estimate: 0h > > Unlike to other caches (row, key, counter), Auth Caches lack some monitoring > capabilities. Here are a few particular changes to get this inequity fixed: > # Add auth caches to _system_views.caches_ VT > # Expose auth caches metrics via JMX > # Add auth caches details to _nodetool info_ > -- 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-19332) Dropwizard Meter causes timeouts when infrequently used
[
https://issues.apache.org/jira/browse/CASSANDRA-19332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811415#comment-17811415
]
Maxim Muzafarov commented on CASSANDRA-19332:
-
Should we also create an issue for the Dropwizard Metrics?
https://github.com/dropwizard/metrics/issues
> Dropwizard Meter causes timeouts when infrequently used
> ---
>
> Key: CASSANDRA-19332
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19332
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Metrics
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Observed instances of timeouts on clusters with long uptime and infrequently
> used tables and possibly just request paths such as not using CAS for large
> fractions of a year.
> CAS seems to be more severely impacted because it has more metrics in the
> request path such as latency measurements for prepare, propose, and the read
> from the underlying table.
> Tracing showed ~600-800 milliseconds for these operations in between the
> “appending to memtable” and “sending a response” events. Reads had a delay
> between finishing the construction of the iterator and sending the read
> response.
> Stack traces dumped every 100 milliseconds using {{sjk}} shows that in
> prepare and propose a lot of time was being spent in
> {{{}Meter.tickIfNecessary{}}}.
> {code:java}
> Thread [2537] RUNNABLE at 2024-01-25T21:14:48.218 - MutationStage-2
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:71)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.prepare(PaxosState.java:92)
> Thread [2539] RUNNABLE at 2024-01-25T21:14:48.520 - MutationStage-4
> com.codahale.metrics.Meter.tickIfNecessary(Meter.java:72)
> com.codahale.metrics.Meter.mark(Meter.java:55)
> com.codahale.metrics.Meter.mark(Meter.java:46)
> com.codahale.metrics.Timer.update(Timer.java:150)
> com.codahale.metrics.Timer.update(Timer.java:86)
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:159)
> org.apache.cassandra.service.paxos.PaxosState.propose(PaxosState.java:127){code}
> {{tickIfNecessary}} does a linear amount of work proportional to the time
> since the last time the metric was updated/read/created and this can actually
> take a measurable amount of time even in a tight loop. On my M2 MBP it was
> 1.5 milliseconds for a day, ~200 days took ~74 milliseconds. Before it warmed
> up it was 140 milliseconds.
> A quick fix is to schedule a task to read all the meters once a day so it
> isn’t done in the request path and we have a more incremental amount to
> process at a time.
> Also observed that {{tickIfNecessary}} is not 100% thread safe in that if it
> takes longer than 5 seconds to run the loop it can end up with multiple
> threads attempting to run the loop at once and then they will concurrently
> run {{EWMA.tick}} which probably results in some ticks not being performed.
> This issue is still present in the latest version of {{Metrics}} if using
> {{{}EWMA{}}}, but {{SlidingWindowTimeAverages}} looks like it has a bounded
> amount of work required to tick. Switching would change how our metrics work
> since the two don't have the same behavior.
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811370#comment-17811370
]
Maxim Muzafarov edited comment on CASSANDRA-14572 at 1/26/24 7:12 PM:
--
[~mck] I've fixed your comments.
[~djoshi], [~cnlwsu], [~smiklosovic], [~aleksey] Would you mind looking at
these changes? I have a lot of hope that we can make some progress here, I've
spent a lot of time polishing it :-)
https://github.com/apache/cassandra/pull/2958/files
was (Author: mmuzaf):
[~mck] I've fixed your comments.
[~djoshi], [~cnlwsu], [~smiklosovic], [~aleksey] Would you mind looking at
these changes? I have a lot of hope that we can make some progress here, I've
spent a lot of time polishing them :-)
https://github.com/apache/cassandra/pull/2958/files
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811370#comment-17811370
]
Maxim Muzafarov commented on CASSANDRA-14572:
-
[~mck] I've fixed your comments.
[~djoshi], [~cnlwsu], [~smiklosovic], [~aleksey] Would you mind looking at
these changes? I have a lot of hope that we can make some progress here, I've
spent a lot of time polishing them :-)
https://github.com/apache/cassandra/pull/2958/files
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809602#comment-17809602
]
Maxim Muzafarov edited comment on CASSANDRA-14572 at 1/22/24 8:11 PM:
--
I think we can add a rate limiter or guardrail in a follow-up issue to prevent
unwise use of metric polling, but currently, I think it is beyond the issue's
scope as there should be no difference in a pattern usage for JMX and/or CQL
polling. Accessing a metric by metric name is super efficient while selecting a
large range of metrics from a large metrics set is not efficient since it
requires the MetrciRegisty collection to be filtered each time for the required
subset of metrics, but it doesn't cause any problems or OOMs.
As I mentioned earlier, I've created 1000 keyspaces with one table each,
resulting in 77k metrics, you can check [the
latest|https://issues.apache.org/jira/browse/CASSANDRA-14572?focusedCommentId=17800388=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17800388]
benchmark for polling a metric.
The JFR for that run is here:
[^flight_recording_1270017199_13.jfr]
The
{code:java}
cqlsh> select count(*) from system_metrics.keyspace_group ;
count
---
77462
(1 rows)
{code}
The query that I used selects a metric by partition:
{code:java}
select * from system_metrics.keyspace_group where name = ?
{code}
was (Author: mmuzaf):
I think we can add a rate limiter or guardrail in a follow-up issue to prevent
unwise use of metric polling, but currently, I think it is beyond the issue's
scope as there should be no difference in a pattern usage for JMX and/or CQL
polling. Accessing a metric by metric name is super efficient while selecting a
large range of metrics from a large metrics set is not efficient since it
requires the MetrciRegisty collection to be filtered each time for the required
subset of metrics, but it doesn't cause any problems or OOMs.
As I mentioned earlier, I've created 1000 keyspaces with one table, which
resulted in 77k metrics you can check the latest benchmark for polling a
metric.
The JFR for that run is here:
[^flight_recording_1270017199_13.jfr]
The
{code:java}
cqlsh> select count(*) from system_metrics.keyspace_group ;
count
---
77462
(1 rows)
{code}
The query that I used selects a metric by partition:
{code:java}
select * from system_metrics.keyspace_group where name = ?
{code}
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809602#comment-17809602
]
Maxim Muzafarov commented on CASSANDRA-14572:
-
I think we can add a rate limiter or guardrail in a follow-up issue to prevent
unwise use of metric polling, but currently, I think it is beyond the issue's
scope as there should be no difference in a pattern usage for JMX and/or CQL
polling. Accessing a metric by metric name is super efficient while selecting a
large range of metrics from a large metrics set is not efficient since it
requires the MetrciRegisty collection to be filtered each time for the required
subset of metrics, but it doesn't cause any problems or OOMs.
As I mentioned earlier, I've created 1000 keyspaces with one table, which
resulted in 77k metrics you can check the latest benchmark for polling a
metric.
The JFR for that run is here:
[^flight_recording_1270017199_13.jfr]
The
{code:java}
cqlsh> select count(*) from system_metrics.keyspace_group ;
count
---
77462
(1 rows)
{code}
The query that I used selects a metric by partition:
{code:java}
select * from system_metrics.keyspace_group where name = ?
{code}
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-14572:
Attachment: flight_recording_1270017199_13.jfr
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809407#comment-17809407
]
Maxim Muzafarov commented on CASSANDRA-14572:
-
It is implemented so that continuous polling of a metric does not cause
problems, as shown in the benchmarks above :) I did a lot of testing for that
to verify the final result.
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: keyspayces_group responses times.png, keyspayces_group
> summary.png, select keyspaces_group by string prefix.png, select
> keyspaces_group compare with wo.png, select keyspaces_group without
> value.png, systemv_views.metrics_dropped_message.png, thread_pools
> benchmark.png
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14867) Histogram overflows potentially leading to writes failing
[
https://issues.apache.org/jira/browse/CASSANDRA-14867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-14867:
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Fix Version/s: 5.x
Since Version: 3.11.1
> Histogram overflows potentially leading to writes failing
> -
>
> Key: CASSANDRA-14867
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14867
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Streaming and Messaging
> Environment: cassandra 3.11.1 on ubuntu 16.04
>Reporter: David
>Priority: Normal
> Fix For: 5.x
>
>
> I observed the following in cassandra logs on 1 host of a 6-node cluster:
> {code}
> ERROR [ScheduledTasks:1] 2018-11-01 17:26:41,277 CassandraDaemon.java:228 -
> Exception in thread Thread[ScheduledTasks:1,5,main]
> java.lang.IllegalStateException: Unable to compute when histogram overflowed
> at
> org.apache.cassandra.metrics.DecayingEstimatedHistogramReservoir$EstimatedHistogramReservoirSnapshot.getMean(DecayingEstimatedHistogramReservoir.java:472)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.net.MessagingService.getDroppedMessagesLogs(MessagingService.java:1263)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.net.MessagingService.logDroppedMessages(MessagingService.java:1236)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.net.MessagingService.access$200(MessagingService.java:87)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.net.MessagingService$4.run(MessagingService.java:507)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_172]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_172]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_172]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_172]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [na:1.8.0_172]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [na:1.8.0_172]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
> [apache-cassandra-3.11.1.jar:3.11.1]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_172]
> {code}
> At the same time, this node was failing all writes issued to it. Restarting
> cassandra on the node brought the cluster into a good state and we stopped
> seeing the histogram overflow errors.
> Has this issue been observed before? Could the histogram overflows cause
> writes to fail?
--
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-19082) Histogram overflow causes client timeouts and message drops
[
https://issues.apache.org/jira/browse/CASSANDRA-19082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-19082:
Resolution: Duplicate
Status: Resolved (was: Triage Needed)
Closing this issue as it's being duplicated by CASSANDRA-14867
Feel free to reopen the issue if you think the cause is different.
> Histogram overflow causes client timeouts and message drops
> ---
>
> Key: CASSANDRA-19082
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19082
> Project: Cassandra
> Issue Type: Bug
>Reporter: Zbyszek Z
>Priority: Normal
>
> Hi,
> We have recently noticed that sometimes this exception happens on our
> Cassandra cluster:
> {code:java}
> ERROR [ScheduledTasks:1] 2023-11-24 06:24:12,680 CassandraDaemon.java:244 -
> Exception in thread Thread[ScheduledTasks:1,5,main]
> java.lang.IllegalStateException: Unable to compute when histogram overflowed
> at
> org.apache.cassandra.metrics.DecayingEstimatedHistogramReservoir$EstimatedHistogramReservoirSnapshot.getMean(DecayingEstimatedHistogramReservoir.java:472)
> at
> org.apache.cassandra.net.MessagingService.getDroppedMessagesLogs(MessagingService.java:1272)
> at
> org.apache.cassandra.net.MessagingService.logDroppedMessages(MessagingService.java:1244)
> at
> org.apache.cassandra.net.MessagingService.access$200(MessagingService.java:84)
> at
> org.apache.cassandra.net.MessagingService$4.run(MessagingService.java:512)
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
> at java.lang.Thread.run(Thread.java:750)
> {code}
> It happens on all 6 nodes at the same time. Also we see increased client
> timeouts and dropped READ and READ_RESPONSE messages. Our Cassandra is
> 3.11.16, 2 DC setup, 6 node in each DC. RF is 3. I have searched issues but
> could not find exactly same issue causing messages to be dropped. Any
> suggestion would be appreciated.
--
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-19082) Histogram overflow causes client timeouts and message drops
[
https://issues.apache.org/jira/browse/CASSANDRA-19082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800666#comment-17800666
]
Maxim Muzafarov commented on CASSANDRA-19082:
-
Hi [~kolargol] , this is a duplicate of CASSANDRA-14867 ?
> Histogram overflow causes client timeouts and message drops
> ---
>
> Key: CASSANDRA-19082
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19082
> Project: Cassandra
> Issue Type: Bug
>Reporter: Zbyszek Z
>Priority: Normal
>
> Hi,
> We have recently noticed that sometimes this exception happens on our
> Cassandra cluster:
> {code:java}
> ERROR [ScheduledTasks:1] 2023-11-24 06:24:12,680 CassandraDaemon.java:244 -
> Exception in thread Thread[ScheduledTasks:1,5,main]
> java.lang.IllegalStateException: Unable to compute when histogram overflowed
> at
> org.apache.cassandra.metrics.DecayingEstimatedHistogramReservoir$EstimatedHistogramReservoirSnapshot.getMean(DecayingEstimatedHistogramReservoir.java:472)
> at
> org.apache.cassandra.net.MessagingService.getDroppedMessagesLogs(MessagingService.java:1272)
> at
> org.apache.cassandra.net.MessagingService.logDroppedMessages(MessagingService.java:1244)
> at
> org.apache.cassandra.net.MessagingService.access$200(MessagingService.java:84)
> at
> org.apache.cassandra.net.MessagingService$4.run(MessagingService.java:512)
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
> at java.lang.Thread.run(Thread.java:750)
> {code}
> It happens on all 6 nodes at the same time. Also we see increased client
> timeouts and dropped READ and READ_RESPONSE messages. Our Cassandra is
> 3.11.16, 2 DC setup, 6 node in each DC. RF is 3. I have searched issues but
> could not find exactly same issue causing messages to be dropped. Any
> suggestion would be appreciated.
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800388#comment-17800388
]
Maxim Muzafarov commented on CASSANDRA-14572:
-
Here is the latest benchmark for selecting a metric by its name (no GC pressure
and low latency):
{code:bash}
SUMMARY STATS
═
Elapsed time [s] 60.001
CPU time [s] 56.884
CPU utilisation [%]9.5
Cycles [op] 15877269
Errors [op] 0
└─ [%]0.0
Requests [req] 15877269
└─ [req/op]1.0
Rows [row] 15877269
└─ [row/req]1.0
Samples 60
Mean sample size [op] 264621
└─ [req] 264621
Concurrency [req] 95 ± 0
└─ [%] 74
Throughput[op/s] 264620 ± 32548
├─ [req/s] 264620 ± 32548
└─ [row/s] 264620 ± 32548
Mean cycle time [ms] 0.380 ± 0.054
Mean resp. time [ms] 0.379 ± 0.054
RESPONSE TIMES [ms]
══
Min 0.254 ± 0.007
25 0.332 ± 0.023
50 0.355 ± 0.042
75 0.393 ± 0.067
90 0.460 ± 0.096
95 0.515 ± 0.128
98 0.597 ± 0.191
99 0.687 ± 0.299
99.9 1.564 ± 1.852
99.994.751 ± 3.954
Max 5.140 ± 4.801
RESPONSE TIME DISTRIBUTION
═══
── Resp. time [ms] ── ─── Count
─
0.0 ... 0.1 0 0.00%
0.1 ... 0.2 12 0.00%
0.2 ... 0.5 14383348 90.59%
0.5 ... 1.01414480 8.91%
1.0 ... 2.2 64692 0.41%
2.2 ... 4.6 9087 0.06%
4.6 ... 10.0 4593 0.03%
10.0 ... 21.5504 0.00%
21.5 ... 46.4466 0.00%
46.4 ...100.0 87 0.00%
{code}
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: keyspayces_group
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800171#comment-17800171
]
Maxim Muzafarov edited comment on CASSANDRA-14572 at 12/24/23 1:46 PM:
---
Hi [~djoshi],
You're right, it is better to discuss the solution design first, and only then
dig into the source code.
1. I've managed to remove the GC pressure in the last few commits, so it should
now be fine to pull a metric value from the virtual table by metric name, but
we still have to iterate over a collection to find a metric.
The CollectionVirtualTableAdapter is a general approach to export any internal
collections as virtual tables, it accepts the Iterable interface as a data
container. We can also implement narrower adapters e.g. one that accepts
Map as a data container, and if we solidify the vt model that the
map key is always equal to the virtual table partition key (which is at least
true for the metric collections), pulling will be slightly faster then. Such a
trade-off depends on the usage pattern for virtual tables with metrics, pulling
metrics every ~10-20 sec should be acceptable with the Iterable interface
(histograms are still expensive to pull often).
2. This is another compromise we have to make, each of these options has its
pros and cons. I see three options here:
- Commit the RawWalker implementations along with the model classes. Pros:
classes are plain, keep the ant build simple, easy to debug. Cons: maintain
cost if the RawWalker interface changes often, increase the amount of changes
in the patch.
- use an annotation processor to generate RawWalker implementation. Pros: no
boilerplate implementation in the code, uses plain java, no extra dependency.
Cons: additional code to maintain, increase the build complexity.
- use a templating engine (e.g. the [javapoet,
|https://github.com/square/javapoet]you meant something like that, right?) to
generate implementations. Pros: no boilerplate code, a framework to create
classes. Cons: increase the code complexity as we have to be aware of a new
library, an extra dependency.
I assume that the RawWalker interface is relatively stable and rarely changes,
so we don't need to change the implementation too often and/or generate it on
the fly. In case we want to add a new column to a model, changes are also easy.
So, if we want to remove the annotation processor, I would rather choose the
first option.
This is still a compromise, so please share your thoughts.
Here is how the generated code looks like:
{code:java}
public class MetricRowWalker implements RowWalker
{
/** {@inheritDoc} */
@Override public void visitMeta(RowWalker.MetadataVisitor visitor)
{
visitor.accept(Column.Type.PARTITION_KEY, "name",
java.lang.String.class);
visitor.accept(Column.Type.REGULAR, "scope", java.lang.String.class);
visitor.accept(Column.Type.REGULAR, "type", java.lang.String.class);
visitor.accept(Column.Type.REGULAR, "value", java.lang.String.class);
}
/** {@inheritDoc} */
@Override public void visitRow(MetricRow row, RowWalker.RowMetadataVisitor
visitor)
{
visitor.accept(Column.Type.PARTITION_KEY, "name",
java.lang.String.class, () -> row.name());
visitor.accept(Column.Type.REGULAR, "scope", java.lang.String.class, ()
-> row.scope());
visitor.accept(Column.Type.REGULAR, "type", java.lang.String.class, ()
-> row.type());
visitor.accept(Column.Type.REGULAR, "value", java.lang.String.class, ()
-> row.value());
}
/** {@inheritDoc} */
@Override
public int count(Column.Type type)
{
switch (type)
{
case PARTITION_KEY: return 1;
case REGULAR: return 3;
case CLUSTERING: return 0;
default: throw new IllegalStateException("Unknown column type: " +
type);
}
}
}
{code}
was (Author: mmuzaf):
Hi [~djoshi],
You're right, it is better to discuss the solution design first, and only then
dig into the source code.
1. I've managed to remove the GC pressure in the last few commits, so it should
now be fine to pull a metric value from the virtual table by metric name, but
we still have to iterate over a collection to find a metric.
The CollectionVirtualTableAdapter is a general approach to export any internal
collections as virtual tables, it accepts the Iterable interface as a data
container. We can also implement narrower adapters e.g. one that accepts
Map as a data container, and if we solidify the vt model that the
map key is always equal to the virtual table partition key (which is at least
true for the metric collections), pulling will be slightly faster then. Such a
trade-off depends on the usage pattern for virtual tables with metrics, pulling
metrics every ~10-20 sec should be acceptable with the Iterable interface
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800171#comment-17800171
]
Maxim Muzafarov edited comment on CASSANDRA-14572 at 12/24/23 12:00 PM:
Hi [~djoshi],
You're right, it is better to discuss the solution design first, and only then
dig into the source code.
1. I've managed to remove the GC pressure in the last few commits, so it should
now be fine to pull a metric value from the virtual table by metric name, but
we still have to iterate over a collection to find a metric.
The CollectionVirtualTableAdapter is a general approach to export any internal
collections as virtual tables, it accepts the Iterable interface as a data
container. We can also implement narrower adapters e.g. one that accepts
Map as a data container, and if we solidify the vt model that the
map key is always equal to the virtual table partition key (which is at least
true for the metric collections), pulling will be slightly faster then. Such a
trade-off depends on the usage pattern for virtual tables with metrics, pulling
metrics every ~10-20 sec should be acceptable with the Iterable interface
(histograms are still expensive to pull often).
2. This is another compromise we have to make, each of these options has its
pros and cons. I see three options here:
- Commit the RawWalker implementations along with the model classes. Pros:
classes are plain, keep the ant build simple, easy to debug. Cons: maintain
cost if the RawWalker interface changes often, increase the amount of changes
in the patch.
- use an annotation processor to generate RawWalker implementation. Pros: no
boilerplate implementation in the code, uses plain java, no extra dependency.
Cons: additional code to maintain, increase the build complexity.
- use a templating engine (e.g. the [javapoet,
|https://github.com/square/javapoet]you meant something like that, right?) to
generate implementations. Pros: no boilerplate code, a framework to create
classes. Cons: increase the code complexity as we have to be aware of a new
library, an extra dependency.
I assume that the RawWalker interface is relatively stable and rarely changes,
so we don't need to change the implementation too often and/or generate it on
the fly. In case we want to add a new column to a model, changes are also easy.
So, if we want to remove the annotation processor, I would rather choose the
first option.
This is still a compromise, so please change your thoughts.
Here is how the generated code looks like:
{code:java}
public class MetricRowWalker implements RowWalker
{
/** {@inheritDoc} */
@Override public void visitMeta(RowWalker.MetadataVisitor visitor)
{
visitor.accept(Column.Type.PARTITION_KEY, "name",
java.lang.String.class);
visitor.accept(Column.Type.REGULAR, "scope", java.lang.String.class);
visitor.accept(Column.Type.REGULAR, "type", java.lang.String.class);
visitor.accept(Column.Type.REGULAR, "value", java.lang.String.class);
}
/** {@inheritDoc} */
@Override public void visitRow(MetricRow row, RowWalker.RowMetadataVisitor
visitor)
{
visitor.accept(Column.Type.PARTITION_KEY, "name",
java.lang.String.class, () -> row.name());
visitor.accept(Column.Type.REGULAR, "scope", java.lang.String.class, ()
-> row.scope());
visitor.accept(Column.Type.REGULAR, "type", java.lang.String.class, ()
-> row.type());
visitor.accept(Column.Type.REGULAR, "value", java.lang.String.class, ()
-> row.value());
}
/** {@inheritDoc} */
@Override
public int count(Column.Type type)
{
switch (type)
{
case PARTITION_KEY: return 1;
case REGULAR: return 3;
case CLUSTERING: return 0;
default: throw new IllegalStateException("Unknown column type: " +
type);
}
}
}
{code}
was (Author: mmuzaf):
Hi [~djoshi],
You're right, it is better to discuss the solution design first, and only then
dig into the source code.
1. I've managed to remove the GC pressure in the last few commits, so it should
now be fine to pull a metric value from the virtual table by metric name, but
we still have to iterate over a collection to find a metric, which again is not
so efficient as JMX MBeans as it has direct reference to a metric instance, and
no CQL overhead.
The CollectionVirtualTableAdapter is a general approach to export any internal
collections as virtual tables, it accepts the Iterable interface as a data
container. We can also implement narrower adapters e.g. one that accepts
Map as a data container, and if we solidify the vt model that the
map key is always equal to the virtual table partition key (which is at least
true for the metric collections), pulling will be slightly faster then. Such a
trade-off depends on the usage
[jira] [Commented] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800171#comment-17800171
]
Maxim Muzafarov commented on CASSANDRA-14572:
-
Hi [~djoshi],
You're right, it is better to discuss the solution design first, and only then
dig into the source code.
1. I've managed to remove the GC pressure in the last few commits, so it should
now be fine to pull a metric value from the virtual table by metric name, but
we still have to iterate over a collection to find a metric, which again is not
so efficient as JMX MBeans as it has direct reference to a metric instance, and
no CQL overhead.
The CollectionVirtualTableAdapter is a general approach to export any internal
collections as virtual tables, it accepts the Iterable interface as a data
container. We can also implement narrower adapters e.g. one that accepts
Map as a data container, and if we solidify the vt model that the
map key is always equal to the virtual table partition key (which is at least
true for the metric collections), pulling will be slightly faster then. Such a
trade-off depends on the usage pattern for virtual tables with metrics, pulling
metrics every ~10-20 sec should be acceptable with the Iterable interface
(histograms are still expensive to pull often).
2. This is another compromise we have to make, each of these options has its
pros and cons. I see three options here:
- Commit the RawWalker implementations along with the model classes. Pros:
classes are plain, keep the ant build simple, easy to debug. Cons: maintain
cost if the RawWalker interface changes often, increase the amount of changes
in the patch.
- use an annotation processor to generate RawWalker implementation. Pros: no
boilerplate implementation in the code, uses plain java, no extra dependency.
Cons: additional code to maintain, increase the build complexity.
- use a templating engine (e.g. the [javapoet,
|https://github.com/square/javapoet]you meant something like that, right?) to
generate implementations. Pros: no boilerplate code, a framework to create
classes. Cons: increase the code complexity as we have to be aware of a new
library, an extra dependency.
I assume that the RawWalker interface is relatively stable and rarely changes,
so we don't need to change the implementation too often and/or generate it on
the fly. In case we want to add a new column to a model, changes are also easy.
So, if we want to remove the annotation processor, I would rather choose the
first option.
This is still a compromise, so please change your thoughts.
Here is how the generated code looks like:
{code:java}
public class MetricRowWalker implements RowWalker
{
/** {@inheritDoc} */
@Override public void visitMeta(RowWalker.MetadataVisitor visitor)
{
visitor.accept(Column.Type.PARTITION_KEY, "name",
java.lang.String.class);
visitor.accept(Column.Type.REGULAR, "scope", java.lang.String.class);
visitor.accept(Column.Type.REGULAR, "type", java.lang.String.class);
visitor.accept(Column.Type.REGULAR, "value", java.lang.String.class);
}
/** {@inheritDoc} */
@Override public void visitRow(MetricRow row, RowWalker.RowMetadataVisitor
visitor)
{
visitor.accept(Column.Type.PARTITION_KEY, "name",
java.lang.String.class, () -> row.name());
visitor.accept(Column.Type.REGULAR, "scope", java.lang.String.class, ()
-> row.scope());
visitor.accept(Column.Type.REGULAR, "type", java.lang.String.class, ()
-> row.type());
visitor.accept(Column.Type.REGULAR, "value", java.lang.String.class, ()
-> row.value());
}
/** {@inheritDoc} */
@Override
public int count(Column.Type type)
{
switch (type)
{
case PARTITION_KEY: return 1;
case REGULAR: return 3;
case CLUSTERING: return 0;
default: throw new IllegalStateException("Unknown column type: " +
type);
}
}
}
{code}
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: keyspayces_group responses times.png, keyspayces_group
> summary.png, select keyspaces_group by string prefix.png, select
> keyspaces_group compare with wo.png, select keyspaces_group without
> value.png, systemv_views.metrics_dropped_message.png, thread_pools
> benchmark.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables
[jira] [Commented] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799887#comment-17799887
]
Maxim Muzafarov commented on CASSANDRA-14572:
-
I think we have a good history of decision-making for the further patch review
process. I've figured out how to improve the traversal of the huge metric
collections, the most efficient way is to compare and filter metric groups by
prefix. This gives us an x4 boost on the same dataset.
Check out another benchmark to compare with the first results I got earlier:
!select keyspaces_group by string prefix.png|width=80%!
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: keyspayces_group responses times.png, keyspayces_group
> summary.png, select keyspaces_group by string prefix.png, select
> keyspaces_group compare with wo.png, select keyspaces_group without
> value.png, systemv_views.metrics_dropped_message.png, thread_pools
> benchmark.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-14572:
Attachment: select keyspaces_group by string prefix.png
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: keyspayces_group responses times.png, keyspayces_group
> summary.png, select keyspaces_group by string prefix.png, select
> keyspaces_group compare with wo.png, select keyspaces_group without
> value.png, systemv_views.metrics_dropped_message.png, thread_pools
> benchmark.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799846#comment-17799846
]
Maxim Muzafarov commented on CASSANDRA-14572:
-
I actually have an update for the last benchmark with the _keyspaces_group_
virtual table! The problem was that during the iteration I was resolving a
metric value for EVERY row, which is a really expensive operation if the metric
type is histogram.
So, when I moved the metric value resolution to the post-filtering everything
became perfect, and now we can get a metric value by partition key really fast
and without GC pressure. I've updated the patch according to the new test
results.
See the screenshot below, select a metric by name with value resolution for
each row and without:
!select keyspaces_group compare with wo.png|width=80%!
!select keyspaces_group without value.png|width=80%!
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: keyspayces_group responses times.png, keyspayces_group
> summary.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-14572:
Attachment: select keyspaces_group without value.png
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: keyspayces_group responses times.png, keyspayces_group
> summary.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-14572:
Attachment: select keyspaces_group compare with wo.png
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: keyspayces_group responses times.png, keyspayces_group
> summary.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799592#comment-17799592
]
Maxim Muzafarov commented on CASSANDRA-14572:
-
I have also prepared some benchmarks for the patch, comparing a new iterative
virtual table implementation with the one that we have now.
h3. The _thread_pools_ virtual table implementation changed
As you can see in the patch, I've removed the old implementation of the
_thread_pools_ virtual table and switched its creation to
CollectionVirtualTableAdapter. This change is fully backwards compatible as the
table has the same columns and column types, and it gives us a good opportunity
to benchmark the solution. I ran the following query between the latest stable
4.1.3 release and the patch:
{code:java}
SELECT * FROM system_views.thread_pools;
{code}
The difference between queries to the old and new table is at the level of
measurement error, which I think is good. The difference at the edge of the max
values of _-50%_ can be explained as follows, the iterative approach gives less
GC pressure, which is also good. See the screenshot below:
!thread_pools benchmark.png|width=80%!
h3. A new _keyspaces_group_ virtual table
This new virtual table displays all the metrics which are related to all known
keyspaces in the cluster. This table can be quite large, so I've prepared some
benchmarks for it as well. I've created 1000 keyspaces for the test case. The
_count_ over the _keyspaces_group_ table:
{code:java}
cqlsh> select count(*) from system_metrics.keyspace_group ;
count
---
77462
(1 rows)
{code}
The query that I used selects a metric by partition:
{code:java}
select * from system_metrics.keyspace_group where name = ?
{code}
I think the benchmark results are quite manageable in this case because we
still have to iterate over the entire set of 77k rows each time an execution
query is made. The internal data collections which we are trying to expose
store their data out of order, which the virtual tables need. In general,
checking a single metric through the large table should be quite fast <1s,
exporting metrics from virtual tables continuously will yield us GC pressure.
!keyspayces_group responses times.png|width=80%!
!keyspayces_group summary.png|width=80%!
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: keyspayces_group responses times.png, keyspayces_group
> summary.png, systemv_views.metrics_dropped_message.png, thread_pools
> benchmark.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-14572:
Attachment: keyspayces_group summary.png
keyspayces_group responses times.png
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: keyspayces_group responses times.png, keyspayces_group
> summary.png, systemv_views.metrics_dropped_message.png, thread_pools
> benchmark.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-14572:
Attachment: thread_pools benchmark.png
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: systemv_views.metrics_dropped_message.png, thread_pools
> benchmark.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799585#comment-17799585
]
Maxim Muzafarov commented on CASSANDRA-14572:
-
Ok, so now the changes are completely ready.
I've fixed all the CI issues related to the current patch and, with the help of
Mick and Ekaterina, have done a full CI test. All tests look good, the OOM that
was raised is not related to the patch as it also fails on the trunk, and I
added tests to check that metrics are completely removed from the
CassandraMetricsRegistry when the remove method is called.
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2602/workflows/978acbe2-6951-4954-a4b3-5fd8674c7dd4
https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/561/workflows/e115a3dd-753b-4e02-94cd-e20feee1a207/jobs/46321
> Expose all table metrics in virtual table
> -
>
> Key: CASSANDRA-14572
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Observability/Metrics
>Reporter: Chris Lohfink
>Assignee: Maxim Muzafarov
>Priority: Low
> Labels: virtual-tables
> Fix For: 5.x
>
> Attachments: systemv_views.metrics_dropped_message.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great
> and intuitive like in nodetool. There is also much for being able to expose
> the metrics we have for tooling via CQL instead of JMX. This is more for the
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a
> column for each metric value. Could also use a Map or UDT instead of the
> column based that can be a bit more specific to each metric type. To that end
> there can be a {{metric_type}} column and then a UDT for each metric type
> filled in, or a single value with more of a Map style. I am
> purposing the column type though as with {{ALLOW FILTERING}} it does allow
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see:
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate
> through metrics query on read of virtual table)
--
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-16861) Test failure: test_compression_cql_options
[
https://issues.apache.org/jira/browse/CASSANDRA-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798701#comment-17798701
]
Maxim Muzafarov edited comment on CASSANDRA-16861 at 12/19/23 6:41 PM:
---
Found the cause, the param was removed here -
https://issues.apache.org/jira/browse/CASSANDRA-18872
EDIT: I updated the local branch and the test passed, so I guess the issue is
no longer relevant for the 5.x branch, as the configuration parameter has been
removed there.
was (Author: mmuzaf):
Found the cause, the param was removed here -
https://issues.apache.org/jira/browse/CASSANDRA-18872
> Test failure: test_compression_cql_options
> --
>
> Key: CASSANDRA-16861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16861
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0, 5.x
>
>
> While working on another ticket, I saw test_compression_cql_options failing
> (which is not the case in Jenkins) but the Circle CI multiplexer showed it as
> being flaky:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1082/workflows/8dacef5d-46f4-4b59-a8f7-08824bf1180f/jobs/6407/tests#failed-test-0]
> {code:java}
> sstables = self.get_sstables(table='compression_opts_table',
> indexes=list())
> sstable_paths = self.get_table_paths('compression_opts_table')
> found = False
> for sstable_path in sstable_paths:
> sstable = os.path.join(sstable_path,
> sstables['compression_opts_table'][1])
> if os.path.exists(sstable):
> assert 'DEFLATE' == self._get_compression_type(sstable)
> found = True
> > assert found
> E assert False
> compression_test.py:118: AssertionError
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16861) Test failure: test_compression_cql_options
[
https://issues.apache.org/jira/browse/CASSANDRA-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-16861:
Fix Version/s: 4.0.x
4.1.x
(was: 5.x)
> Test failure: test_compression_cql_options
> --
>
> Key: CASSANDRA-16861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16861
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0, 4.0.x, 4.1.x
>
>
> While working on another ticket, I saw test_compression_cql_options failing
> (which is not the case in Jenkins) but the Circle CI multiplexer showed it as
> being flaky:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1082/workflows/8dacef5d-46f4-4b59-a8f7-08824bf1180f/jobs/6407/tests#failed-test-0]
> {code:java}
> sstables = self.get_sstables(table='compression_opts_table',
> indexes=list())
> sstable_paths = self.get_table_paths('compression_opts_table')
> found = False
> for sstable_path in sstable_paths:
> sstable = os.path.join(sstable_path,
> sstables['compression_opts_table'][1])
> if os.path.exists(sstable):
> assert 'DEFLATE' == self._get_compression_type(sstable)
> found = True
> > assert found
> E assert False
> compression_test.py:118: AssertionError
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16861) Fix flaky test test_compression_cql_options
[
https://issues.apache.org/jira/browse/CASSANDRA-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798701#comment-17798701
]
Maxim Muzafarov commented on CASSANDRA-16861:
-
Found the cause, the param was removed here -
https://issues.apache.org/jira/browse/CASSANDRA-18872
> Fix flaky test test_compression_cql_options
> ---
>
> Key: CASSANDRA-16861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16861
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0, 5.x
>
>
> While working on another ticket, I saw test_compression_cql_options failing
> (which is not the case in Jenkins) but the Circle CI multiplexer showed it as
> being flaky:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1082/workflows/8dacef5d-46f4-4b59-a8f7-08824bf1180f/jobs/6407/tests#failed-test-0]
> {code:java}
> sstables = self.get_sstables(table='compression_opts_table',
> indexes=list())
> sstable_paths = self.get_table_paths('compression_opts_table')
> found = False
> for sstable_path in sstable_paths:
> sstable = os.path.join(sstable_path,
> sstables['compression_opts_table'][1])
> if os.path.exists(sstable):
> assert 'DEFLATE' == self._get_compression_type(sstable)
> found = True
> > assert found
> E assert False
> compression_test.py:118: AssertionError
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16861) Fix flaky test test_compression_cql_options
[
https://issues.apache.org/jira/browse/CASSANDRA-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798700#comment-17798700
]
Maxim Muzafarov commented on CASSANDRA-16861:
-
I think the problem is still relevant. I can reproduce it on the trunk branch.
https://github.com/apache/cassandra/commit/08c46d09634ed4639246036b84caf817d14fa188
https://github.com/apache/cassandra-dtest/commit/24d6b291eeb8842fab22b5b3936539b66a036d86
{code:java}
= test session starts
=
platform darwin -- Python 3.9.6, pytest-7.3.1, pluggy-1.0.0
rootdir: /Users/m/pycharm/cassandra-dtest
configfile: pytest.ini
plugins: flaky-3.7.0, repeat-0.9.1, timeout-1.4.2
timeout: 900.0s
timeout method: signal
timeout func_only: False
collected 1 item
compression_test.py F
[100%]
= FAILURES
=
TestCompression.test_compression_cql_options
self =
@since("3.0")
def test_compression_cql_options(self):
"""
@jira_ticket CASSANDRA-8384
using new cql create table syntax to configure compression
"""
cluster = self.cluster
cluster.populate(1).start()
[node] = cluster.nodelist()
session = self.patient_cql_connection(node)
create_ks(session, 'ks', 1)
session.execute("""
create table compression_opts_table
(id uuid PRIMARY KEY )
WITH compression = {
'class': 'DeflateCompressor',
'chunk_length_in_kb': 256
}
AND crc_check_chance = 0.25;
""")
session.cluster.refresh_schema_metadata()
meta =
session.cluster.metadata.keyspaces['ks'].tables['compression_opts_table']
assert 'org.apache.cassandra.io.compress.DeflateCompressor' ==
meta.options['compression']['class']
assert '256' == meta.options['compression']['chunk_length_in_kb']
assert_crc_check_chance_equal(session, "compression_opts_table", 0.25)
warn = node.grep_log("The option crc_check_chance was deprecated as a
compression option.")
assert len(warn) == 0
> session.execute("""
alter table compression_opts_table
WITH compression = {
'class': 'DeflateCompressor',
'chunk_length_in_kb': 256,
'crc_check_chance': 0.6
}
""")
compression_test.py:85:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
cassandra/cluster.py:2618: in cassandra.cluster.Session.execute
???
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> ???
E cassandra.protocol.ConfigurationException:
cassandra/cluster.py:4894: ConfigurationException
{code}
> Fix flaky test test_compression_cql_options
> ---
>
> Key: CASSANDRA-16861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16861
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0, 5.x
>
>
> While working on another ticket, I saw test_compression_cql_options failing
> (which is not the case in Jenkins) but the Circle CI multiplexer showed it as
> being flaky:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1082/workflows/8dacef5d-46f4-4b59-a8f7-08824bf1180f/jobs/6407/tests#failed-test-0]
> {code:java}
> sstables = self.get_sstables(table='compression_opts_table',
> indexes=list())
> sstable_paths = self.get_table_paths('compression_opts_table')
> found = False
> for sstable_path in sstable_paths:
> sstable = os.path.join(sstable_path,
> sstables['compression_opts_table'][1])
> if os.path.exists(sstable):
> assert 'DEFLATE' == self._get_compression_type(sstable)
> found = True
> > assert found
> E assert False
> compression_test.py:118: AssertionError
> {code}
>
>
--
This
[jira] [Commented] (CASSANDRA-19146) Upgrade owasp to 9.0.x
[
https://issues.apache.org/jira/browse/CASSANDRA-19146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798547#comment-17798547
]
Maxim Muzafarov commented on CASSANDRA-19146:
-
Now it looks as perfect as it should
+1
> Upgrade owasp to 9.0.x
> --
>
> Key: CASSANDRA-19146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19146
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0-rc, 5.x
>
> Attachments: signature.asc
>
>
> From https://github.com/jeremylong/DependencyCheck :
> {quote}
> Upgrading to 9.0.0 or later is mandatory; previous versions of
> dependency-check utilize the NVD data feeds which will be deprecated on Dec
> 15th, 2023.
> {quote}
--
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
