[jira] [Commented] (CASSANDRA-19577) Queries are not visible to the "system_views.queries" virtual table at the coordinator level
[
https://issues.apache.org/jira/browse/CASSANDRA-19577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842735#comment-17842735
]
Chris Lohfink commented on CASSANDRA-19577:
---
+1
> Queries are not visible to the "system_views.queries" virtual table at the
> coordinator level
>
>
> Key: CASSANDRA-19577
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19577
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.1
>
> Attachments: ci_summary-1.html, ci_summary-2.html, ci_summary.html
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> There appears to be a hole in the implementation of CASSANDRA-15241 where
> {{DebuggableTasks}} at the coordinator are not preserved through the creation
> of {{FutureTasks}} in {{TaskFactory}}. This means that {{QueriesTable}} can't
> see them when is asks {{SharedExecutorPool}} for running tasks. It should be
> possible to fix this in {{TaskFactory}} by making sure to propagate any
> {{RunnableDebuggableTask}} we encounter. We already do this in
> {{toExecute()}}, but it also needs to happen in the relevant {{toSubmit()}}
> method(s).
--
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-19578) Concurrent equivalent schema updates lead to unresolved disagreement
[ https://issues.apache.org/jira/browse/CASSANDRA-19578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842491#comment-17842491 ] Chris Lohfink commented on CASSANDRA-19578: --- +1 > Concurrent equivalent schema updates lead to unresolved disagreement > > > Key: CASSANDRA-19578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19578 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Chris Lohfink >Priority: Normal > Fix For: 4.1.x, 5.0.x > > > As part of CASSANDRA-17819 a check for empty schema changes was added to the > updateSchema. This only looks at the _logical_ schema difference of the > schemas, but the changes made to the system_schema keyspace are the ones that > actually are involved in the digest. > If two nodes issue the same CREATE statement the difference from the > keyspace.diff would be empty but the timestamps on the mutations would be > different, leading to a pseudo schema disagreement which will never resolve > until resetlocalschema or nodes being bounced. > Only impacts 4.1 > test and fix : > https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411 -- 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-19578) Concurrent equivalent schema updates lead to unresolved disagreement
[ https://issues.apache.org/jira/browse/CASSANDRA-19578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-19578: -- Description: As part of CASSANDRA-17819 a check for empty schema changes was added to the updateSchema. This only looks at the _logical_ schema difference of the schemas, but the changes made to the system_schema keyspace are the ones that actually are involved in the digest. If two nodes issue the same CREATE statement the difference from the keyspace.diff would be empty but the timestamps on the mutations would be different, leading to a pseudo schema disagreement which will never resolve until resetlocalschema or nodes being bounced. Only impacts 4.1 test and fix : https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411 was: As part of CASSANDRA-17819 a check for empty schema changes was added to the updateSchema. This only looks at the _logical_ schema difference of the schemas, but the changes made to the system_schema keyspace are the ones that actually are involved in the digest. If two nodes issue the same CREATE statement the difference from the keyspace.diff would be empty but the timestamps on the mutations would be different, leading to a pseudo schema disagreement which will never resolve until resetlocalschema or nodes being bounced. test and fix : https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411 > Concurrent equivalent schema updates lead to unresolved disagreement > > > Key: CASSANDRA-19578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19578 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Chris Lohfink >Priority: Normal > > As part of CASSANDRA-17819 a check for empty schema changes was added to the > updateSchema. This only looks at the _logical_ schema difference of the > schemas, but the changes made to the system_schema keyspace are the ones that > actually are involved in the digest. > If two nodes issue the same CREATE statement the difference from the > keyspace.diff would be empty but the timestamps on the mutations would be > different, leading to a pseudo schema disagreement which will never resolve > until resetlocalschema or nodes being bounced. > Only impacts 4.1 > test and fix : > https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411 -- 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-19578) Concurrent equivalent schema updates lead to unresolved disagreement
[ https://issues.apache.org/jira/browse/CASSANDRA-19578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-19578: -- Description: As part of CASSANDRA-17819 a check for empty schema changes was added to the updateSchema. This only looks at the _logical_ schema difference of the schemas, but the changes made to the system_schema keyspace are the ones that actually are involved in the digest. If two nodes issue the same CREATE statement the difference from the keyspace.diff would be empty but the timestamps on the mutations would be different, leading to a pseudo schema disagreement which will never resolve until resetlocalschema or nodes being bounced. test and fix : https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411 was: As part of CASSANDRA-17819 a check for empty schema changes was added to the updateSchema. This only looks at the _logical_ schema difference of the schemas, but the changes made to the system_schema keyspace are the ones that actually are involved in the digest. If two nodes issue the same CREATE statement the difference from the keyspace.diff would be empty but the timestamps on the mutations would be different, leading to a pseudo schema disagreement which will never resolve until resetlocalschema or nodes being bounced. > Concurrent equivalent schema updates lead to unresolved disagreement > > > Key: CASSANDRA-19578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19578 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Chris Lohfink >Priority: Normal > > As part of CASSANDRA-17819 a check for empty schema changes was added to the > updateSchema. This only looks at the _logical_ schema difference of the > schemas, but the changes made to the system_schema keyspace are the ones that > actually are involved in the digest. > If two nodes issue the same CREATE statement the difference from the > keyspace.diff would be empty but the timestamps on the mutations would be > different, leading to a pseudo schema disagreement which will never resolve > until resetlocalschema or nodes being bounced. > test and fix : > https://github.com/clohfink/cassandra/commit/ba915f839089006ac6d08494ef19dc010bcd6411 -- 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-19578) Concurrent equivalent schema updates lead to unresolved disagreement
[ https://issues.apache.org/jira/browse/CASSANDRA-19578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-19578: -- Since Version: 4.1-beta1 > Concurrent equivalent schema updates lead to unresolved disagreement > > > Key: CASSANDRA-19578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19578 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Chris Lohfink >Priority: Normal > > As part of CASSANDRA-17819 a check for empty schema changes was added to the > updateSchema. This only looks at the _logical_ schema difference of the > schemas, but the changes made to the system_schema keyspace are the ones that > actually are involved in the digest. > If two nodes issue the same CREATE statement the difference from the > keyspace.diff would be empty but the timestamps on the mutations would be > different, leading to a pseudo schema disagreement which will never resolve > until resetlocalschema or nodes being bounced. -- 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-19578) Concurrent equivalent schema updates lead to unresolved disagreement
[ https://issues.apache.org/jira/browse/CASSANDRA-19578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-19578: -- Impacts: (was: None) > Concurrent equivalent schema updates lead to unresolved disagreement > > > Key: CASSANDRA-19578 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19578 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Chris Lohfink >Priority: Normal > > As part of CASSANDRA-17819 a check for empty schema changes was added to the > updateSchema. This only looks at the _logical_ schema difference of the > schemas, but the changes made to the system_schema keyspace are the ones that > actually are involved in the digest. > If two nodes issue the same CREATE statement the difference from the > keyspace.diff would be empty but the timestamps on the mutations would be > different, leading to a pseudo schema disagreement which will never resolve > until resetlocalschema or nodes being bounced. -- 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-19578) Concurrent equivalent schema updates lead to unresolved disagreement
Chris Lohfink created CASSANDRA-19578: - Summary: Concurrent equivalent schema updates lead to unresolved disagreement Key: CASSANDRA-19578 URL: https://issues.apache.org/jira/browse/CASSANDRA-19578 Project: Cassandra Issue Type: Bug Components: Cluster/Schema Reporter: Chris Lohfink As part of CASSANDRA-17819 a check for empty schema changes was added to the updateSchema. This only looks at the _logical_ schema difference of the schemas, but the changes made to the system_schema keyspace are the ones that actually are involved in the digest. If two nodes issue the same CREATE statement the difference from the keyspace.diff would be empty but the timestamps on the mutations would be different, leading to a pseudo schema disagreement which will never resolve until resetlocalschema or nodes being bounced. -- 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=17827259#comment-17827259
]
Chris Lohfink commented on CASSANDRA-14572:
---
+1 great follow through! I like the non-processor approach
> 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=17809595#comment-17809595
]
Chris Lohfink commented on CASSANDRA-14572:
---
Wouldn't this still be significantly less GC thrashing than the currently jmx
polling? Just from people querying queryMBeans(null, null) alone. Currently the
last couple places I've seen are making these horrible >100-500mb object and
sending it over in a single message before it even starts pulling metrics (when
there's a lot of tables/keyspaces).
This is also something that can still be more improved upon as well much more
than JMX which we don't have much control over.
Maybe in your benchmarking include allocation rates? Compare it to polling
everything over jmx (although different companies are doing it in different
ways so hard to be perfect about). Should also test it out if there's 1000
tables or 1000 keyspaces with 1 table and make sure don't OOM somewhere.
> 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] [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=17797240#comment-17797240
]
Chris Lohfink commented on CASSANDRA-14572:
---
so just nit picking thing, should we put these under a system_metrics virtual
keyspace instead of having all these in system_views? Originally idea was to
have some tables that are more like nodetool - providing a curated view of the
data vs the raw dumps of internals. These metrics would be super helpful for
setting up alerting, metric systems, and for knowledgeable operators but for
people new to the system seeing the extra 30 tables may be hard to parse and
understand.
Would also remove need to have the metrics_ prefix
> 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: 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] [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=17791175#comment-17791175
]
Chris Lohfink commented on CASSANDRA-14572:
---
Please do!
> 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: Chris Lohfink
>Priority: Low
> Labels: virtual-tables
>
> 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-17865) Make sure preview repairs don't optimise streams unless configured to
[
https://issues.apache.org/jira/browse/CASSANDRA-17865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602454#comment-17602454
]
Chris Lohfink commented on CASSANDRA-17865:
---
+1
> Make sure preview repairs don't optimise streams unless configured to
> -
>
> Key: CASSANDRA-17865
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17865
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
>
> Currently in {{RepairOption}} when optimizing streams, we don't confirm that
> if it's a preview repair we have
> {{DatabaseDescriptor.autoOptimisePreviewRepairStreams}} set.
--
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-8612) Read metrics should be updated on all types of reads
[ https://issues.apache.org/jira/browse/CASSANDRA-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599150#comment-17599150 ] Chris Lohfink commented on CASSANDRA-8612: -- This PR doesnt impact latencies so I dont believe it would be too jarring. Its really sstables per read and `nodetool profileload` that this effects. I do think a single "this is the actual read latencies" metric of some sort would lead to less confusion but should be a new one for upgrade simplicity. Adding a LatencyMetrics with both the range and partition latencies as children would then merge them without extra impact to the read path. > Read metrics should be updated on all types of reads > > > Key: CASSANDRA-8612 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8612 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Chris Lohfink >Assignee: Dean Z >Priority: Low > Labels: lhf, metrics > Attachments: 0001-Update-read-metrics-on-all-types-of-reads.patch, > 0002-Add-more-read-metrics-into-PartitionRangeReadCommand.patch > > > Metrics like "sstables per read" are not updated on a range slice. Although > separating things out for each type of read could make sense like we do for > latencies, only exposing the metrics for one type can be a little confusing > when people do a query and see nothing increases. I think its sufficient to > use the same metrics for all reads. -- 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-15241) Virtual table to expose current running queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17564389#comment-17564389
]
Chris Lohfink commented on CASSANDRA-15241:
---
+1 from me thanks Caleb
> Virtual table to expose current running queries
> ---
>
> Key: CASSANDRA-15241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15241
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Chris Lohfink
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Expose current running queries and their duration.
> {code}cqlsh> select * from system_views.queries;
> thread_id| duration_micros | task
> --+-+-
> Native-Transport-Requests-17 |6325 | QUERY
> select * from system_views.queries; [pageSize = 100]
> Native-Transport-Requests-4 | 14681 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> Native-Transport-Requests-6 | 14678 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> ReadStage-10 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-13 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-14 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-19 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-20 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-22 |7279 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-23 |4716 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-5 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-7 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-8 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000{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-17498) Add Guardrail to disallow creation of secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-17498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517649#comment-17517649 ] Chris Lohfink commented on CASSANDRA-17498: --- I like the experience of disabling it like that as well, and it is very little overhead as you say. Im +1 to having as an additional option for clarity > Add Guardrail to disallow creation of secondary indexes > --- > > Key: CASSANDRA-17498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17498 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Rather than just a min/max on secondary indexes, we should also have the > ability to completely enable or disable creation of secondary indexes via > guardrails. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-7723) sstable2json (and possibly other command-line tools) hang if no write permission to the commitlogs
[ https://issues.apache.org/jira/browse/CASSANDRA-7723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17414290#comment-17414290 ] Chris Lohfink commented on CASSANDRA-7723: -- should be resolved in CASSANDRA-7464 > sstable2json (and possibly other command-line tools) hang if no write > permission to the commitlogs > -- > > Key: CASSANDRA-7723 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7723 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Tools >Reporter: J.B. Langston >Priority: Low > > sstable2json (and potentially other command-line tools that call > DatabaseDescriptor.loadSchemas) will hang if the user running them doesn't > have write permission on the commit logs. loadSchemas calls > Schema.updateVersion, which causes a mutation to the system tables, then it > just spins forever trying to acquire a commit log segment. See this thread > dump: https://gist.github.com/markcurtis1970/837e770d1cad5200943c. The tools > should recognize this and present an understandable error message. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16806) Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
[
https://issues.apache.org/jira/browse/CASSANDRA-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412182#comment-17412182
]
Chris Lohfink commented on CASSANDRA-16806:
---
I am +1 to change. From looks of it it was pretty unnecessary to restrict them
in first place.
> Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation
> allows it
> ---
>
> Key: CASSANDRA-16806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16806
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> {{TRUNCATE}} statements are currently not supported by Virtual Tables. For
> some Virtual Tables it makes sense to allow it.
> It can be done by adding a {{truncate}} method to the {{VirtualTable}}
> interface and calling that method from {{TruncateStatement}}. The default
> implementation of the method should be to fire an {{InvalidRequestException}}
> saying that truncate is not supported on that specific table.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16806) Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
[
https://issues.apache.org/jira/browse/CASSANDRA-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-16806:
--
Reviewers: Benjamin Lerer, Chris Lohfink (was: Benjamin Lerer)
> Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation
> allows it
> ---
>
> Key: CASSANDRA-16806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16806
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> {{TRUNCATE}} statements are currently not supported by Virtual Tables. For
> some Virtual Tables it makes sense to allow it.
> It can be done by adding a {{truncate}} method to the {{VirtualTable}}
> interface and calling that method from {{TruncateStatement}}. The default
> implementation of the method should be to fire an {{InvalidRequestException}}
> saying that truncate is not supported on that specific table.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16815) Background schedule to clean up orphaned hints files
[ https://issues.apache.org/jira/browse/CASSANDRA-16815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17396781#comment-17396781 ] Chris Lohfink commented on CASSANDRA-16815: --- +1 thanks for hotprop! > Background schedule to clean up orphaned hints files > > > Key: CASSANDRA-16815 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16815 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > Host replacement is possible to produce orphaned hints files that the > original associated host ID no longer exist in the cluster (i.e., being > replaced). Those orphaned hints files will not be dispatched and only > consumes up the disk space. > We can have a background schedule that infrequently checks and deletes the > files if they are orphaned and have exceeded the TTL. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16610) Implement XXHashPartitioner
[
https://issues.apache.org/jira/browse/CASSANDRA-16610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17326764#comment-17326764
]
Chris Lohfink commented on CASSANDRA-16610:
---
to be fair, our murmur implementation isnt even a correct implementation but we
cant fix it. A new partitioner might be chance to get a more standard thing for
client drivers wanting token awareness to not have to do custom
implementations. That said we also need code changes to all the drivers to
support this...
> Implement XXHashPartitioner
> ---
>
> Key: CASSANDRA-16610
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16610
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Core
>Reporter: Stefan Miklosovic
>Priority: Normal
> Attachments: jmh-result.json
>
>
> I implemented partitioner based on XXHash algorithm.
> There are two branches, the first xxhash, extracts common parts with Murmur
> as there is a lot of overlap between these two.
> The second branch just copies everything from Murmur and changes just bits
> which are necessary.
> I am not sure what path we want to go with so I just provided both to easier
> elaborate on.
> I have written a microbenchmark measuring both partitioners and XXHash
> implementation is very fast, around 10x faster (on greater payloads).
> Benchmark is included in xxhash-2 branch.
> https://github.com/instaclustr/cassandra/tree/xxhash-2
> https://github.com/instaclustr/cassandra/tree/xxhash
> {code:java}
> [java] Benchmark (bufferSize) Mode Cnt
> Score Error Units
> [java] PartitionersBench.benchMurmur3Partitioner31 avgt 20
> 157.942 ± 0.110 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner67 avgt 20
> 204.670 ± 0.152 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 131 avgt 20
> 361.068 ± 0.228 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 517 avgt 20
> 1325.670 ± 1.255 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 1031 avgt 20
> 2594.651 ± 2.725 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 2041 avgt 20
> 5082.166 ± 1.721 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 4097 avgt 20
> 10112.020 ± 3.637 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 31 avgt 20
> 40.650 ± 0.025 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 67 avgt 20
> 53.305 ± 0.035 ns/op
> [java] PartitionersBench.benchXXHashPartitioner131 avgt 20
> 67.098 ± 0.057 ns/op
> [java] PartitionersBench.benchXXHashPartitioner517 avgt 20
> 150.415 ± 0.107 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 1031 avgt 20
> 265.614 ± 0.140 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 2041 avgt 20
> 365.796 ± 0.225 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 4097 avgt 20
> 925.841 ± 0.664 ns/op
> {code}
> {code:java}
> [java] PartitionersBench.benchMurmur3Partitioner 3 avgt5
> 44.516 ± 0.345 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 5 avgt5
> 54.930 ± 0.450 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 7 avgt5
> 63.428 ± 0.266 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner 9 avgt5
> 69.456 ± 0.467 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner11 avgt5
> 81.411 ± 0.535 ns/op
> [java] PartitionersBench.benchMurmur3Partitioner16 avgt5
> 68.621 ± 0.417 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 3 avgt5
> 26.820 ± 0.271 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 5 avgt5
> 28.182 ± 0.139 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 7 avgt5
> 31.557 ± 0.161 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 9 avgt5
> 31.017 ± 0.212 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 11 avgt5
> 33.233 ± 0.136 ns/op
> [java] PartitionersBench.benchXXHashPartitioner 16 avgt5
> 31.386 ± 0.128 ns/op
> {code}
> https://github.com/OpenHFT/Zero-Allocation-Hashing
> https://cyan4973.github.io/xxHash/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16513) Add nodetool command to display or export the contents of a virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-16513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17302600#comment-17302600
]
Chris Lohfink commented on CASSANDRA-16513:
---
I like idea of a new cli tool as well over nodetool connecting cql. A new
option on cqlsh to dump a table in yaml/json/xml might be a solution as well.
> Add nodetool command to display or export the contents of a virtual table
> -
>
> Key: CASSANDRA-16513
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16513
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics, Tool/nodetool
>Reporter: Paulo Motta
>Priority: Normal
> Labels: gsoc2021, mentor
>
> Several virtual tables were recently added, but they're currently only
> accessible via cqlsh or programmatically. While this is valuable for many use
> cases, operators are accustomed with the convenience of querying system
> metrics with a simple nodetool command.
> In addition to that, a relatively common request is to provide nodetool
> output in different formats (JSON, YAML and even XML) (CASSANDRA-5977,
> CASSANDRA-12035, CASSANDRA-12486, CASSANDRA-12698, CASSANDRA-12503). However
> this requires lots of manual labor as each nodetool subcommand needs to be
> adapted to support new output formats.
> I propose adding a new nodetool command that will consistently print to the
> standard output the contents of a virtual table. By default the command will
> print the output in a human-readable tabular format similar to cqlsh, but a
> "--format" parameter can be specified to modify the output to some other
> format like JSON or YAML.
> It should be possible to add a limit to the amount of rows displayed and
> filter to display only rows from a specific keyspace or table. The command
> should be flexible and provide simple hooks for registration and
> customization of new virtual tables.
> I propose calling this command nodetool show (naming
> bikeshedding welcome), for example:
> {noformat}
> nodetool show --list
> caches
> clients
> internode_inbound
> internode_outbound
> settings
> sstable_tasks
> system_properties
> thread_pools
> nodetool show clients --format yaml
> ...
> nodetool show internode_outboud --format json
> ...
> nodetool show sstabletasks --keyspace my_ks --table -my_table
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16499) single-threaded write workloads can spend ~70% time waiting on SEPExecutor
[ https://issues.apache.org/jira/browse/CASSANDRA-16499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17299664#comment-17299664 ] Chris Lohfink commented on CASSANDRA-16499: --- from a risk perspective, allowing the switch from SEP to DebuggableThreadPoolExecutor is virtually zero and would be a pretty straight forward configuration option. If it gives a +80% throughput improvement in some case its probably worth it. > single-threaded write workloads can spend ~70% time waiting on SEPExecutor > -- > > Key: CASSANDRA-16499 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16499 > Project: Cassandra > Issue Type: Improvement >Reporter: Tom Whitmore >Priority: Normal > Labels: performance > Attachments: AMI Linux test -- 09.txt, Cassandra Write trace 5; > warmed up -- 02.txt, MaybeStartSpinning Unpark fix on 4beta4; Cassandra > Stress results -- 01.txt, MaybeStartSpinning Unpark fix; Cassandra Stress > results -- 02.txt, MaybeStartSpinning Unpark fix; Linux benchmarks -- > 07.xlsx, SEPWorker trace 2 delay examples -- 01.txt, SEPWorker trace 2 > delays.txt, SEPWorker trace 3 delays; with proposed fix.txt, Single-thread > Latencies report -- 01.xlsx, Stress Write 2 sgl-thread vs 10 threads -- > 01.txt, Stress Write sgl-thread 1 -- 01.txt, Stress Write trace 1.txt, > proposed fix patches.zip, tracing & experimental change patches.zip > > > Hi all! While conducting benchmarking of Cassandra against other databases > for a particular healthcare solution, I found some surprising anomalies in > single-threaded write performance. > Analysis & tracing suggest there might be some inefficiencies in inter-thread > execution in Cassandra; > * Tracing showed an average delay of 1.52 ms between > StorageProxy.performLocally() being called, and the LocalMutationRunnable > actually executing. > * Total operation time averaged 2.06 ms (measured at Message.Dispatcher > processRequest()). This suggested ~72% of the +total operation time+ being > lost waiting for thread scheduling in SEPExecutor. > * With I tested with multiple threads, performance with 10 threads was 27x > higher. This supports a hypothesis that scheduling delays may be hindering > single-threaded progress. > * Transaction throughput for Cassandra with a single-threaded workload, > measured far lower than that of PostgreSQL on the same hardware. Postgres > achieved ~200k committed transactions/ minute including fsync; Cassandra > achieves ~37k per minute. Given they are both essentially writing to a commit > log, it may be informative to understand why the differences are arising. > Cassandra's architecture seems in theory like it might be aligned for our > usecase, given the Commit Log and Log Structured Merge design. Some of our > customers have configurations posing high single-threaded loads. Therefore I > spent some time trying to understand why efficiency for such loads seemed > less than expected. > My investigation so far: > * benchmarked Cassandra 3.11.10 > * stack-dumped it under load & identified a pattern of threads waiting in > AbstractWriteResponseHandler while nothing else is busy > * checked out Cassandra 3.11.10 source, built it, debugged & stepped > through key areas to try and understand behavior. > * instrumented key areas with custom tracing code & timestamps to 0.01 > millisecond. > ** _see patch attached._ > * benchmarked Cassandra 4 beta 4 & verified delays also present > * shown & traced delays with my healthcare scenario benchmark > * shown & traced delays with the +Cassandra stress-test+ tool. > The configuration was: > * single-node Cassandra running locally, on a recent Dell laptop with NVmE > SSD. > * for the healthcare scenario: > ** Java client app running 1 or 10 threads; > ** trialled LOCAL_ONE and ANY consistency levels; > ** trialled unbatched, BatchType.UNLOGGED and BatchType.LOGGED. > * for 'cassandra-stress': > ** cassandra-stress.bat write n=1 -rate threads=1 > Without deeply understanding the code, I have considered a couple of possible > areas/ ideas as to improvement. I worked on the 3.11.10 codebase. I'd be > interested to understand whether or not these might be sound or not; note > that neither achieves as much improvement as might theoretically be hoped for. > My investigations based on the key observation of large delays between > StorageProxy.performLocally() being invoked and the LocalMutationRunnable > actually executing, for single-threaded workloads. > What I looked at: > * Without fully understanding SEPExecutor.takeWorkPermit() – it answers true > to execute immediately, false if scheduled – for this workload scheduling > seemed slow. > ** takeWorkPermit() answers false if no work permits are
[jira] [Commented] (CASSANDRA-16499) single-threaded write workloads can spend ~70% time waiting on SEPExecutor
[ https://issues.apache.org/jira/browse/CASSANDRA-16499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17297680#comment-17297680 ] Chris Lohfink commented on CASSANDRA-16499: --- I think it would be interesting to be able to switch this to non-SEP executor and compare performance with some different workloads as well. Especially on lower throughput/concurrency clusters > single-threaded write workloads can spend ~70% time waiting on SEPExecutor > -- > > Key: CASSANDRA-16499 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16499 > Project: Cassandra > Issue Type: Bug >Reporter: Tom Whitmore >Priority: Normal > Attachments: Cassandra Write trace 5; warmed up -- 02.txt, > Single-thread Latencies report -- 01.xlsx, Stress Write sgl-thread 1 -- > 01.txt, Stress Write trace 1.txt, tracing & experimental change patches.zip > > > Hi all! While conducting benchmarking of Cassandra against other databases > for a particular healthcare solution, I found some surprising anomalies in > single-threaded write performance. > Analysis & tracing suggest there might be some inefficiencies in inter-thread > execution in Cassandra; > * Tracing showed an average delay of 1.52 ms between > StorageProxy.performLocally() being called, and the LocalMutationRunnable > actually executing. > * Total operation time averaged 2.06 ms (measured at Message.Dispatcher > processRequest()). This suggested ~72% of the +total operation time+ being > lost waiting for thread scheduling in SEPExecutor. > * With I tested with multiple threads, performance with 10 threads was 27x > higher. This supports a hypothesis that scheduling delays may be hindering > single-threaded progress. > * Transaction throughput for Cassandra with a single-threaded workload, > measured far lower than that of PostgreSQL on the same hardware. Postgres > achieved ~200k committed transactions/ minute including fsync; Cassandra > achieves ~37k per minute. Given they are both essentially writing to a commit > log, it may be informative to understand why the differences are arising. > Cassandra's architecture seems in theory like it might be aligned for our > usecase, given the Commit Log and Log Structured Merge design. Some of our > customers have configurations posing high single-threaded loads. Therefore I > spent some time trying to understand why efficiency for such loads seemed > less than expected. > My investigation so far: > * benchmarked Cassandra 3.11.10 > * stack-dumped it under load & identified a pattern of threads waiting in > AbstractWriteResponseHandler while nothing else is busy > * checked out Cassandra 3.11.10 source, built it, debugged & stepped > through key areas to try and understand behavior. > * instrumented key areas with custom tracing code & timestamps to 0.01 > millisecond. > ** _see patch attached._ > * benchmarked Cassandra 4 beta 4 & verified delays also present > * shown & traced delays with my healthcare scenario benchmark > * shown & traced delays with the +Cassandra stress-test+ tool. > The configuration was: > * single-node Cassandra running locally, on a recent Dell laptop with NVmE > SSD. > * for the healthcare scenario: > ** Java client app running 1 or 10 threads; > ** trialled LOCAL_ONE and ANY consistency levels; > ** trialled unbatched, BatchType.UNLOGGED and BatchType.LOGGED. > * for 'cassandra-stress': > ** cassandra-stress.bat write n=1 -rate threads=1 > Without deeply understanding the code, I have considered a couple of possible > areas/ ideas as to improvement. I worked on the 3.11.10 codebase. I'd be > interested to understand whether or not these might be sound or not; note > that neither achieves as much improvement as might theoretically be hoped for. > My investigations based on the key observation of large delays between > StorageProxy.performLocally() being invoked and the LocalMutationRunnable > actually executing, for single-threaded workloads. > What I looked at: > * Without fully understanding SEPExecutor.takeWorkPermit() – it answers true > to execute immediately, false if scheduled – for this workload scheduling > seemed slow. > ** takeWorkPermit() answers false if no work permits are available. > ** I noticed takeWorkPermit() also answers false if no task permits are > available, +even if no task permit need be taken.+ > ** by changing this condition I was able to gain +45% performance. > * Without deeply understanding SEP Executor/ Worker or sleep algorithms, I > noted that in a single-thread workload SEPWorkers would likely spin & be put > to sleep for a fairly extended period after completing each task. > ** I did wonder if the relatively-long park times (average of 500,000 nanos > = 0.5ms) could contribute
[jira] [Commented] (CASSANDRA-16451) Add ability to ttl snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17286575#comment-17286575
]
Chris Lohfink commented on CASSANDRA-16451:
---
Great idea! should be sure to add a throttle in the deletion to prevent
trashing drives
> Add ability to ttl snapshots
>
>
> Key: CASSANDRA-16451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16451
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Paulo Motta
>Priority: Normal
> Labels: gsoc2021, mentor
>
> It should be possible to add a TTL to snapshots, after which it automatically
> cleans itself up.
> This will be useful together with the {{auto_snapshot}} option, where you
> want to keep an emergency snapshot in case of accidental drop or truncation
> but automatically remove it after a specified period when it's no longer
> useful. So in addition to allowing a user to specify a snapshot ttl on
> {{nodetool snapshot}} we should have a {{auto_snapshot_ttl}} option that
> allows a user to set a ttl for automatic snaphots on drop/truncate.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16425) Improve handling of repair sessions during startup/shutdown
[ https://issues.apache.org/jira/browse/CASSANDRA-16425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17281190#comment-17281190 ] Chris Lohfink commented on CASSANDRA-16425: --- failed test looks like flakey unrelated thing if can double check that. +1 > Improve handling of repair sessions during startup/shutdown > --- > > Key: CASSANDRA-16425 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16425 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta5 > > > We should send out a fail message on clean shutdown and if we find an ongoing > repair session during startup we should fail it and tell participants. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16425) Improve handling of repair sessions during startup/shutdown
[ https://issues.apache.org/jira/browse/CASSANDRA-16425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-16425: -- Reviewers: Blake Eggleston, Chris Lohfink (was: Blake Eggleston) > Improve handling of repair sessions during startup/shutdown > --- > > Key: CASSANDRA-16425 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16425 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta5 > > > We should send out a fail message on clean shutdown and if we find an ongoing > repair session during startup we should fail it and tell participants. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15241) Virtual table to expose current running queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-15241:
--
Fix Version/s: (was: 4.0)
> Virtual table to expose current running queries
> ---
>
> Key: CASSANDRA-15241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15241
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
>
> Expose current running queries and their duration.
> {code}cqlsh> select * from system_views.queries;
> thread_id| duration_micros | task
> --+-+-
> Native-Transport-Requests-17 |6325 | QUERY
> select * from system_views.queries; [pageSize = 100]
> Native-Transport-Requests-4 | 14681 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> Native-Transport-Requests-6 | 14678 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> ReadStage-10 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-13 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-14 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-19 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-20 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-22 |7279 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-23 |4716 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-5 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-7 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-8 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16167) Rename master branch to trunk in cassandra-sidecar
[ https://issues.apache.org/jira/browse/CASSANDRA-16167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17217612#comment-17217612 ] Chris Lohfink commented on CASSANDRA-16167: --- Thanks! > Rename master branch to trunk in cassandra-sidecar > -- > > Key: CASSANDRA-16167 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16167 > Project: Cassandra > Issue Type: Sub-task >Reporter: Michael Semb Wever >Priority: Normal > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15241) Virtual table to expose current running queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214206#comment-17214206
]
Chris Lohfink commented on CASSANDRA-15241:
---
I gave a talk on why I feel its necessary last year at apache con, that said
its super late in release and its a pretty big patch (mostly just code making
Mutations and Messages human readable) so I understand it not going in. Review
feedback has been addressed I believe so waiting on that.
> Virtual table to expose current running queries
> ---
>
> Key: CASSANDRA-15241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15241
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
> Fix For: 4.0
>
>
> Expose current running queries and their duration.
> {code}cqlsh> select * from system_views.queries;
> thread_id| duration_micros | task
> --+-+-
> Native-Transport-Requests-17 |6325 | QUERY
> select * from system_views.queries; [pageSize = 100]
> Native-Transport-Requests-4 | 14681 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> Native-Transport-Requests-6 | 14678 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> ReadStage-10 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-13 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-14 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-19 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-20 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-22 |7279 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-23 |4716 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-5 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-7 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-8 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16155) ByteBufferAccessor cast exceptions are thrown when trying to query a virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-16155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208096#comment-17208096
]
Chris Lohfink commented on CASSANDRA-16155:
---
+1
> ByteBufferAccessor cast exceptions are thrown when trying to query a virtual
> table
> --
>
> Key: CASSANDRA-16155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16155
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
>
> Start a fresh trunk node, and try to run
> SELECT * FROM system_views.local_read_latency ;
> You’ll get:
> {code:java}
> ERROR [Native-Transport-Requests-1] 2020-09-30 09:44:45,099
> ErrorMessage.java:457 - Unexpected exception during request
> java.lang.ClassCastException:
> org.apache.cassandra.db.marshal.ByteBufferAccessor cannot be cast to
> java.lang.String
> at
> org.apache.cassandra.serializers.AbstractTextSerializer.serialize(AbstractTextSerializer.java:29)
> at
> org.apache.cassandra.db.marshal.AbstractType.decompose(AbstractType.java:131)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16161) Validation Compactions causing Java GC pressure
[ https://issues.apache.org/jira/browse/CASSANDRA-16161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-16161: -- Component/s: Tool/nodetool Local/Config Local/Compaction Assignee: Cameron Zemek Status: Open (was: Triage Needed) > Validation Compactions causing Java GC pressure > --- > > Key: CASSANDRA-16161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16161 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Local/Config, Tool/nodetool >Reporter: Cameron Zemek >Assignee: Cameron Zemek >Priority: Normal > Fix For: 3.11.x, 3.11.8 > > Attachments: 16161.patch > > > Validation Compactions are not rate limited which can cause Java GC pressure > and result in spikes in latency. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16161) Validation Compactions causing Java GC pressure
[ https://issues.apache.org/jira/browse/CASSANDRA-16161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206225#comment-17206225 ] Chris Lohfink edited comment on CASSANDRA-16161 at 10/2/20, 2:44 PM: - While tangental to adding a throttle, offheap merkle trees and some of the perf improvements (ie xor impl and more aggressive dereferencing) has helped a lot as well (CASSANDRA-15202). Its a lot better in 4.0 from my experiences. For 3.x though I agree that validation compaction is brutal and this could provide a workaround to keep functioning. Only question I think is if the compaction throughput throttle should be shared vs creating a new one but I am happy with this approach. The code looks straight forward and am +1 to it. not sure about versions though was (Author: clohfink): While tangental to adding a throttle, offheap merkle trees and some of the perf improvements (ie xor impl and more aggressive dereferencing) has helped a lot as well (CASSANDRA-15202). Its a lot better in 4.0 from my experiences. For 3.x though I agree that validation compaction is brutal and this could provide a workaround to keep functioning. Only question I think is if the compaction throughput throttle should be shared vs creating a new one but I am happy with this approach. The code looks straight forward, +1 > Validation Compactions causing Java GC pressure > --- > > Key: CASSANDRA-16161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16161 > Project: Cassandra > Issue Type: Improvement >Reporter: Cameron Zemek >Priority: Normal > Fix For: 3.11.x, 3.11.8 > > Attachments: 16161.patch > > > Validation Compactions are not rate limited which can cause Java GC pressure > and result in spikes in latency. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16161) Validation Compactions causing Java GC pressure
[ https://issues.apache.org/jira/browse/CASSANDRA-16161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206225#comment-17206225 ] Chris Lohfink commented on CASSANDRA-16161: --- While tangental to adding a throttle, offheap merkle trees and some of the perf improvements (ie xor impl and more aggressive dereferencing) has helped a lot as well (CASSANDRA-15202). Its a lot better in 4.0 from my experiences. For 3.x though I agree that validation compaction is brutal and this could provide a workaround to keep functioning. Only question I think is if the compaction throughput throttle should be shared vs creating a new one but I am happy with this approach. The code looks straight forward, +1 > Validation Compactions causing Java GC pressure > --- > > Key: CASSANDRA-16161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16161 > Project: Cassandra > Issue Type: Improvement >Reporter: Cameron Zemek >Priority: Normal > Fix For: 3.11.x, 3.11.8 > > Attachments: 16161.patch > > > Validation Compactions are not rate limited which can cause Java GC pressure > and result in spikes in latency. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16155) ByteBufferAccessor cast exceptions are thrown when trying to query a virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-16155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-16155:
--
Reviewers: Chris Lohfink
> ByteBufferAccessor cast exceptions are thrown when trying to query a virtual
> table
> --
>
> Key: CASSANDRA-16155
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16155
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
>
> Start a fresh trunk node, and try to run
> SELECT * FROM system_views.local_read_latency ;
> You’ll get:
> {code:java}
> ERROR [Native-Transport-Requests-1] 2020-09-30 09:44:45,099
> ErrorMessage.java:457 - Unexpected exception during request
> java.lang.ClassCastException:
> org.apache.cassandra.db.marshal.ByteBufferAccessor cannot be cast to
> java.lang.String
> at
> org.apache.cassandra.serializers.AbstractTextSerializer.serialize(AbstractTextSerializer.java:29)
> at
> org.apache.cassandra.db.marshal.AbstractType.decompose(AbstractType.java:131)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15241) Virtual table to expose current running queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-15241:
--
Status: Patch Available (was: Open)
> Virtual table to expose current running queries
> ---
>
> Key: CASSANDRA-15241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15241
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
> Fix For: 4.0
>
>
> Expose current running queries and their duration.
> {code}cqlsh> select * from system_views.queries;
> thread_id| duration_micros | task
> --+-+-
> Native-Transport-Requests-17 |6325 | QUERY
> select * from system_views.queries; [pageSize = 100]
> Native-Transport-Requests-4 | 14681 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> Native-Transport-Requests-6 | 14678 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> ReadStage-10 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-13 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-14 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-19 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-20 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-22 |7279 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-23 |4716 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-5 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-7 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-8 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15241) Virtual table to expose current running queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-15241:
--
Status: In Progress (was: Changes Suggested)
> Virtual table to expose current running queries
> ---
>
> Key: CASSANDRA-15241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15241
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
> Fix For: 4.0
>
>
> Expose current running queries and their duration.
> {code}cqlsh> select * from system_views.queries;
> thread_id| duration_micros | task
> --+-+-
> Native-Transport-Requests-17 |6325 | QUERY
> select * from system_views.queries; [pageSize = 100]
> Native-Transport-Requests-4 | 14681 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> Native-Transport-Requests-6 | 14678 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> ReadStage-10 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-13 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-14 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-19 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-20 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-22 |7279 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-23 |4716 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-5 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-7 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-8 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15164: -- Status: Ready to Commit (was: Review In Progress) > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta, 3.0.23, 3.11.9 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15164: -- Reviewers: Benjamin Lerer, Chris Lohfink, Chris Lohfink (was: Benjamin Lerer, Chris Lohfink) Benjamin Lerer, Chris Lohfink, Chris Lohfink (was: Benjamin Lerer, Chris Lohfink) Status: Review In Progress (was: Patch Available) > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta, 3.0.23, 3.11.9 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15164: -- Resolution: Fixed Status: Resolved (was: Ready to Commit) > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta, 3.0.23, 3.11.9 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201702#comment-17201702 ] Chris Lohfink commented on CASSANDRA-15164: --- Its been merged back into 3.0 and 3.11 now > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta, 3.0.23, 3.11.9 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15164: -- Fix Version/s: 3.11.9 3.0.23 > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta, 3.0.23, 3.11.9 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16074) Add metric for client concurrent byte throttle
[ https://issues.apache.org/jira/browse/CASSANDRA-16074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-16074: -- Status: Review In Progress (was: Changes Suggested) > Add metric for client concurrent byte throttle > -- > > Key: CASSANDRA-16074 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16074 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client, Observability/Metrics >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > Fix For: 4.0-beta > > > Add a metric to expose the current bytes and bytes per ip used that is used > in the existing throttle so its possible to determine what to set it to. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16116) Emit a metric for mutations that are too large in commit logs
[ https://issues.apache.org/jira/browse/CASSANDRA-16116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-16116: -- Status: Ready to Commit (was: Review In Progress) > Emit a metric for mutations that are too large in commit logs > - > > Key: CASSANDRA-16116 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16116 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Lee Tang >Assignee: Lee Tang >Priority: Low > Fix For: 4.0-beta > > Time Spent: 40m > Remaining Estimate: 0h > > Huge memory allocations can cause GC thrashing and a lot of write timeouts. > Having a metric in the commit log allows us to react faster and discern why > write timeouts are happening. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16116) Emit a metric for mutations that are too large in commit logs
[ https://issues.apache.org/jira/browse/CASSANDRA-16116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201246#comment-17201246 ] Chris Lohfink commented on CASSANDRA-16116: --- Committed thanks! > Emit a metric for mutations that are too large in commit logs > - > > Key: CASSANDRA-16116 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16116 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Lee Tang >Assignee: Lee Tang >Priority: Low > Fix For: 4.0-beta > > Time Spent: 40m > Remaining Estimate: 0h > > Huge memory allocations can cause GC thrashing and a lot of write timeouts. > Having a metric in the commit log allows us to react faster and discern why > write timeouts are happening. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16116) Emit a metric for mutations that are too large in commit logs
[ https://issues.apache.org/jira/browse/CASSANDRA-16116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-16116: -- Source Control Link: https://github.com/apache/cassandra/commit/e973344305ed2cd5821ccf51cfeb1481010ef18b Resolution: Fixed Status: Resolved (was: Ready to Commit) > Emit a metric for mutations that are too large in commit logs > - > > Key: CASSANDRA-16116 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16116 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Lee Tang >Assignee: Lee Tang >Priority: Low > Fix For: 4.0-beta > > Time Spent: 40m > Remaining Estimate: 0h > > Huge memory allocations can cause GC thrashing and a lot of write timeouts. > Having a metric in the commit log allows us to react faster and discern why > write timeouts are happening. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16116) Emit a metric for mutations that are too large in commit logs
[ https://issues.apache.org/jira/browse/CASSANDRA-16116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-16116: -- Fix Version/s: 4.0-beta > Emit a metric for mutations that are too large in commit logs > - > > Key: CASSANDRA-16116 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16116 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Lee Tang >Assignee: Lee Tang >Priority: Low > Fix For: 4.0-beta > > Time Spent: 40m > Remaining Estimate: 0h > > Huge memory allocations can cause GC thrashing and a lot of write timeouts. > Having a metric in the commit log allows us to react faster and discern why > write timeouts are happening. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201112#comment-17201112 ] Chris Lohfink commented on CASSANDRA-15164: --- Committed, thanks > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15164: -- Since Version: 3.0.0 Source Control Link: https://github.com/apache/cassandra/commit/4782fd399d97be551032576c4d77f079e862fdba Resolution: Fixed Status: Resolved (was: Ready to Commit) > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15164: -- Reviewers: Benjamin Lerer, Chris Lohfink, Chris Lohfink (was: Benjamin Lerer, Chris Lohfink) Benjamin Lerer, Chris Lohfink, Chris Lohfink (was: Benjamin Lerer, Chris Lohfink) Status: Review In Progress (was: Patch Available) > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15164: -- Status: Ready to Commit (was: Review In Progress) > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16116) Emit a metric for mutations that are too large in commit logs
[ https://issues.apache.org/jira/browse/CASSANDRA-16116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17200268#comment-17200268 ] Chris Lohfink commented on CASSANDRA-16116: --- [java8|https://app.circleci.com/pipelines/github/clohfink/cassandra/9/workflows/27d99211-312d-44b1-948f-93ed91cae70f] [java11|https://app.circleci.com/pipelines/github/clohfink/cassandra/9/workflows/b7488408-670f-409e-af0a-aa7a6c1ea8ff] > Emit a metric for mutations that are too large in commit logs > - > > Key: CASSANDRA-16116 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16116 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Lee Tang >Assignee: Lee Tang >Priority: Low > Time Spent: 10m > Remaining Estimate: 0h > > Huge memory allocations can cause GC thrashing and a lot of write timeouts. > Having a metric in the commit log allows us to react faster and discern why > write timeouts are happening. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15164) Overflowed Partition Cell Histograms Can Prevent Compactions from Executing
[ https://issues.apache.org/jira/browse/CASSANDRA-15164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15164: -- Reviewers: Benjamin Lerer, Chris Lohfink (was: Benjamin Lerer) > Overflowed Partition Cell Histograms Can Prevent Compactions from Executing > --- > > Key: CASSANDRA-15164 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15164 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Ankur Jha >Assignee: Caleb Rackliffe >Priority: Urgent > Labels: compaction, partition > Fix For: 4.0-beta > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Hi, we are running 6 node Cassandra cluster in production with 3 seed node > but from last night one of our seed nodes is continuously throwing an error > like this;- > cassandra.protocol.ServerError: message="java.lang.IllegalStateException: Unable to compute ceiling for max > when histogram overflowed"> > For a cluster to be up and running I Drained this node. > Can somebody help me out with this? > > Any help or lead would be appreciated > > Note : We are using Cassandra version 3.7 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-8720) Provide tools for finding wide row/partition keys
[ https://issues.apache.org/jira/browse/CASSANDRA-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197942#comment-17197942 ] Chris Lohfink edited comment on CASSANDRA-8720 at 9/17/20, 8:35 PM: sstablemetadata gives top partitions for an sstable now but it has to scan the data. Talk at time was to include the top partitions in the statistics component of the sstable after compaction, which could make that instant and something that can be aggregated into cfstats. Might be another option. Wouldnt be perfectly accurate but would be good for finding worst outliers. was (Author: clohfink): sstablemetadata gives top partitions for an sstable now but it has to scan the data. Talk at time was to include the top partitions in the statistics component of the sstable after compaction, which could make that instant and something that can be aggregated into cfstats. Might be another option. > Provide tools for finding wide row/partition keys > - > > Key: CASSANDRA-8720 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8720 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: J.B. Langston >Priority: Normal > Fix For: 2.1.x, 2.2.x > > Attachments: 8720.txt > > > Multiple users have requested some sort of tool to help identify wide row > keys. They get into a situation where they know a wide row/partition has been > inserted and it's causing problems for them but they have no idea what the > row key is in order to remove it. > Maintaining the widest row key currently encountered and displaying it in > cfstats would be one possible approach. > Another would be an offline tool (possibly an enhancement to sstablekeys) to > show the number of columns/bytes per key in each sstable. If a tool to > aggregate the information at a CF-level could be provided that would be a > bonus, but it shouldn't be too hard to write a script wrapper to aggregate > them if not. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-8720) Provide tools for finding wide row/partition keys
[ https://issues.apache.org/jira/browse/CASSANDRA-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197942#comment-17197942 ] Chris Lohfink commented on CASSANDRA-8720: -- sstablemetadata gives top partitions for an sstable now but it has to scan the data. Talk at time was to include the top partitions in the statistics component of the sstable after compaction, which could make that instant and something that can be aggregated into cfstats. Might be another option. > Provide tools for finding wide row/partition keys > - > > Key: CASSANDRA-8720 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8720 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: J.B. Langston >Priority: Normal > Fix For: 2.1.x, 2.2.x > > Attachments: 8720.txt > > > Multiple users have requested some sort of tool to help identify wide row > keys. They get into a situation where they know a wide row/partition has been > inserted and it's causing problems for them but they have no idea what the > row key is in order to remove it. > Maintaining the widest row key currently encountered and displaying it in > cfstats would be one possible approach. > Another would be an offline tool (possibly an enhancement to sstablekeys) to > show the number of columns/bytes per key in each sstable. If a tool to > aggregate the information at a CF-level could be provided that would be a > bonus, but it shouldn't be too hard to write a script wrapper to aggregate > them if not. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15241) Virtual table to expose current running queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197000#comment-17197000
]
Chris Lohfink commented on CASSANDRA-15241:
---
I wasn't sure I should put this in 4.0 but I would love to.
> Virtual table to expose current running queries
> ---
>
> Key: CASSANDRA-15241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15241
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
> Fix For: 4.0
>
>
> Expose current running queries and their duration.
> {code}cqlsh> select * from system_views.queries;
> thread_id| duration_micros | task
> --+-+-
> Native-Transport-Requests-17 |6325 | QUERY
> select * from system_views.queries; [pageSize = 100]
> Native-Transport-Requests-4 | 14681 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> Native-Transport-Requests-6 | 14678 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> ReadStage-10 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-13 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-14 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-19 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-20 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-22 |7279 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-23 |4716 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-5 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-7 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-8 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16116) Emit a metric for mutations that are too large in commit logs
[ https://issues.apache.org/jira/browse/CASSANDRA-16116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-16116: -- Change Category: Operability Complexity: Low Hanging Fruit Reviewers: Chris Lohfink Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Emit a metric for mutations that are too large in commit logs > - > > Key: CASSANDRA-16116 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16116 > Project: Cassandra > Issue Type: Task > Components: Observability/Metrics >Reporter: Lee Tang >Assignee: Lee Tang >Priority: Low > Time Spent: 10m > Remaining Estimate: 0h > > Huge memory allocations can cause GC thrashing and a lot of write timeouts. > Having a metric in the commit log allows us to react faster and discern why > write timeouts are happening. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16074) Add metric for client concurrent byte throttle
[ https://issues.apache.org/jira/browse/CASSANDRA-16074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17184021#comment-17184021 ] Chris Lohfink commented on CASSANDRA-16074: --- The justification is that the throttle is really hard to use without a metric to tell what it’s at. Especially since it will be heavily based on the data model. It isn’t required for the throttle to work though as well so it can wait. > Add metric for client concurrent byte throttle > -- > > Key: CASSANDRA-16074 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16074 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client, Observability/Metrics >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > > Add a metric to expose the current bytes and bytes per ip used that is used > in the existing throttle so its possible to determine what to set it to. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16074) Add metric for client concurrent byte throttle
[ https://issues.apache.org/jira/browse/CASSANDRA-16074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-16074: -- Impacts: Docs (was: None) Test and Documentation Plan: update metrics.rst and unit tests Status: Patch Available (was: Open) https://github.com/apache/cassandra/pull/719 > Add metric for client concurrent byte throttle > -- > > Key: CASSANDRA-16074 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16074 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client, Observability/Metrics >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > > Add a metric to expose the current bytes and bytes per ip used that is used > in the existing throttle so its possible to determine what to set it to. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16074) Add metric for client concurrent byte throttle
[ https://issues.apache.org/jira/browse/CASSANDRA-16074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-16074: -- Change Category: Operability Complexity: Low Hanging Fruit Status: Open (was: Triage Needed) > Add metric for client concurrent byte throttle > -- > > Key: CASSANDRA-16074 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16074 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client, Observability/Metrics >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > > Add a metric to expose the current bytes and bytes per ip used that is used > in the existing throttle so its possible to determine what to set it to. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16074) Add metric for client concurrent byte throttle
Chris Lohfink created CASSANDRA-16074: - Summary: Add metric for client concurrent byte throttle Key: CASSANDRA-16074 URL: https://issues.apache.org/jira/browse/CASSANDRA-16074 Project: Cassandra Issue Type: New Feature Components: Messaging/Client, Observability/Metrics Reporter: Chris Lohfink Assignee: Chris Lohfink Add a metric to expose the current bytes and bytes per ip used that is used in the existing throttle so its possible to determine what to set it to. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-8612) Read metrics should be updated on all types of reads
[ https://issues.apache.org/jira/browse/CASSANDRA-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17121076#comment-17121076 ] Chris Lohfink commented on CASSANDRA-8612: -- Yeah thats pretty much it. its gonna be bit of auditing the existing metrics and adding where it only captures one case. If you are including latencies this gets a bit more confusing. We have "read latencies" for single partition latencies and "coordinator scan" latencies for range queries. Really it seems like "read" should be them merged and maybe have a range/single specific one. This could be like a gauge that merges the metrics at read time (like keyspace/table parent latencies do). But if keeping latencies outta scope of this I dont think it's necessary to support the 2 different types still. For tombstones per read/sstables per read I think it makes more sense to just have a single metric, and it seems to me more like a bug that C* doesnt even include them in range reads. > Read metrics should be updated on all types of reads > > > Key: CASSANDRA-8612 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8612 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Chris Lohfink >Priority: Low > Labels: lhf, metrics > Attachments: 0001-Update-read-metrics-on-all-types-of-reads.patch > > > Metrics like "sstables per read" are not updated on a range slice. Although > separating things out for each type of read could make sense like we do for > latencies, only exposing the metrics for one type can be a little confusing > when people do a query and see nothing increases. I think its sufficient to > use the same metrics for all reads. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Issue Comment Deleted] (CASSANDRA-15750) Upgrade Cassandra Java Driver to 4.6
[ https://issues.apache.org/jira/browse/CASSANDRA-15750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15750: -- Comment: was deleted (was: The 3.x branch supports all the 4.0 features to my knowledge and has had the existing burn time and testing on it. This is a pretty large change. Is there an additional reason or value beyond “its the latest”? Also given parity with python driver api used in cqlsh code.) > Upgrade Cassandra Java Driver to 4.6 > > > Key: CASSANDRA-15750 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15750 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Eduard Tudenhoefner >Assignee: Eduard Tudenhoefner >Priority: Normal > Fix For: 4.0-beta, 4.0-rc > > > Before releasing C* 4.0 I think it would be a good idea to upgrade to the > latest Cassandra Java Driver that is being used internally. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15750) Upgrade Cassandra Java Driver to 4.6
[ https://issues.apache.org/jira/browse/CASSANDRA-15750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089709#comment-17089709 ] Chris Lohfink edited comment on CASSANDRA-15750 at 4/22/20, 2:17 PM: - The 3.x branch supports all the 4.0 features to my knowledge and has had the existing burn time and testing on it. This is a pretty large change. Is there an additional reason or value beyond “its the latest”? Also given parity with python driver api used in cqlsh code. was (Author: cnlwsu): The 3.x branch supports all the 4.0 features to my knowledge and has had the existing burn time and testing on it. This is a pretty large change. Is there an additional reason or value beyond “its the latest”? Also given parody with python driver api used in cqlsh code. > Upgrade Cassandra Java Driver to 4.6 > > > Key: CASSANDRA-15750 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15750 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Eduard Tudenhoefner >Assignee: Eduard Tudenhoefner >Priority: Normal > Fix For: 4.0-beta, 4.0-rc > > > Before releasing C* 4.0 I think it would be a good idea to upgrade to the > latest Cassandra Java Driver that is being used internally. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15750) Upgrade Cassandra Java Driver to 4.6
[ https://issues.apache.org/jira/browse/CASSANDRA-15750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089709#comment-17089709 ] Chris Lohfink edited comment on CASSANDRA-15750 at 4/22/20, 2:14 PM: - The 3.x branch supports all the 4.0 features to my knowledge and has had the existing burn time and testing on it. This is a pretty large change. Is there an additional reason or value beyond “its the latest”? Also given parody with python driver api used in cqlsh code. was (Author: cnlwsu): The 3.x branch supports all the 4.0 features to my knowledge and has had the existing burn time and testing on it. This is a pretty large change. Is there an additional reason or value beyond “its the latest”? Also Given parody with python driver api used in cqlsh code. > Upgrade Cassandra Java Driver to 4.6 > > > Key: CASSANDRA-15750 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15750 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Eduard Tudenhoefner >Assignee: Eduard Tudenhoefner >Priority: Normal > Fix For: 4.0-beta, 4.0-rc > > > Before releasing C* 4.0 I think it would be a good idea to upgrade to the > latest Cassandra Java Driver that is being used internally. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15750) Upgrade Cassandra Java Driver to 4.6
[ https://issues.apache.org/jira/browse/CASSANDRA-15750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089709#comment-17089709 ] Chris Lohfink edited comment on CASSANDRA-15750 at 4/22/20, 2:13 PM: - The 3.x branch supports all the 4.0 features to my knowledge and has had the existing burn time and testing on it. This is a pretty large change. Is there an additional reason or value beyond “its the latest”? Also Given parody with python driver api used in cqlsh code. was (Author: cnlwsu): # The 3.x branch supports all the 4.0 features to my knowledge and has had the existing burn time and testing on it. This is a pretty large change. Is there an additional reason or value beyond “its the latest”? Also Given parody with python driver api used in cqlsh code. > Upgrade Cassandra Java Driver to 4.6 > > > Key: CASSANDRA-15750 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15750 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Eduard Tudenhoefner >Assignee: Eduard Tudenhoefner >Priority: Normal > Fix For: 4.0-beta, 4.0-rc > > > Before releasing C* 4.0 I think it would be a good idea to upgrade to the > latest Cassandra Java Driver that is being used internally. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15750) Upgrade Cassandra Java Driver to 4.6
[ https://issues.apache.org/jira/browse/CASSANDRA-15750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089709#comment-17089709 ] Chris Lohfink commented on CASSANDRA-15750: --- # The 3.x branch supports all the 4.0 features to my knowledge and has had the existing burn time and testing on it. This is a pretty large change. Is there an additional reason or value beyond “its the latest”? Also Given parody with python driver api used in cqlsh code. > Upgrade Cassandra Java Driver to 4.6 > > > Key: CASSANDRA-15750 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15750 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Eduard Tudenhoefner >Assignee: Eduard Tudenhoefner >Priority: Normal > Fix For: 4.0-beta, 4.0-rc > > > Before releasing C* 4.0 I think it would be a good idea to upgrade to the > latest Cassandra Java Driver that is being used internally. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14825) Expose table schema for drivers
[ https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071202#comment-17071202 ] Chris Lohfink commented on CASSANDRA-14825: --- Yeah i initially thought this should be post-4.0 but if we making table changes it would make life a lot easier on drivers so I like idea of putting it in > Expose table schema for drivers > --- > > Key: CASSANDRA-14825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14825 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Chris Lohfink >Assignee: Robert Stupp >Priority: Normal > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently the drivers recreate the CQL for the tables by putting together the > system table values. This is very difficult to keep up to date and buggy > enough that its only even supported in Java and Python drivers. Cassandra > already has some limited output available for snapshots that we could provide > in a virtual table or new query that the drivers can fetch. This can greatly > reduce the complexity of drivers while also reducing bugs like > CASSANDRA-14822 as the underlying schema and properties change. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15620) Add "unleveled sstables" table metric
[ https://issues.apache.org/jira/browse/CASSANDRA-15620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15620: -- Reviewers: Chris Lohfink, Chris Lohfink (was: Chris Lohfink, Chris Lohfink) Chris Lohfink, Chris Lohfink (was: Chris Lohfink) Status: Review In Progress (was: Patch Available) > Add "unleveled sstables" table metric > - > > Key: CASSANDRA-15620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15620 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Normal > > The number of unleveled sstables is an important indicator that deserves to > be a dedicated table metric on its own. This will also add a global gauge > that is convenient to query. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15620) Add "unleveled sstables" table metric
[ https://issues.apache.org/jira/browse/CASSANDRA-15620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15620: -- Status: Ready to Commit (was: Review In Progress) > Add "unleveled sstables" table metric > - > > Key: CASSANDRA-15620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15620 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Normal > > The number of unleveled sstables is an important indicator that deserves to > be a dedicated table metric on its own. This will also add a global gauge > that is convenient to query. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15620) Add "unleveled sstables" table metric
[ https://issues.apache.org/jira/browse/CASSANDRA-15620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15620: -- Test and Documentation Plan: na Status: Patch Available (was: Open) > Add "unleveled sstables" table metric > - > > Key: CASSANDRA-15620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15620 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Normal > > The number of unleveled sstables is an important indicator that deserves to > be a dedicated table metric on its own. This will also add a global gauge > that is convenient to query. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15620) Add "unleveled sstables" table metric
[ https://issues.apache.org/jira/browse/CASSANDRA-15620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17055509#comment-17055509 ] Chris Lohfink commented on CASSANDRA-15620: --- +1 on code, just spot checked with lcs and stcs as well and worked great thanks! > Add "unleveled sstables" table metric > - > > Key: CASSANDRA-15620 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15620 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Normal > > The number of unleveled sstables is an important indicator that deserves to > be a dedicated table metric on its own. This will also add a global gauge > that is convenient to query. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15616) Expose Cassandra related system properties in a virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-15616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051755#comment-17051755
]
Chris Lohfink commented on CASSANDRA-15616:
---
lgtm +1
> Expose Cassandra related system properties in a virtual table
> -
>
> Key: CASSANDRA-15616
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15616
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: High
> Fix For: 4.x
>
>
> Allow viewing Cassandra related system properties.
> Viewing yaml config settings, as implemented by {{SettingsTable}} in
> CASSANDRA-14573, is not enough for certain third-party tool use-cases. There
> are a number of system properties that can be defined that contribute to the
> configuration set that Cassandra runs on.
> An example of such a use-case is described in CASSANDRA-15339. JMX ports need
> to be discovered, especially in 4.0 where multiple nodes can run on one
> ipaddress. Unlike the native port that is through gossip discoverable, the
> jmx port is not. The jmx port is also not available via the SettingsTable.
> With this patch and {{SystemPropertiesTable}} it becomes possible to first
> discover all the native ports in the cluster and against each then discover
> each node's jmx port.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15616) Expose Cassandra related system properties in a virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-15616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051589#comment-17051589
]
Chris Lohfink commented on CASSANDRA-15616:
---
I walked through repo and your whitelist captured everything I could find. I
would actually like to see removing `"java.class.path"` simply because it's so
long makes the output unreadable without `EXPAND ON` and its pretty limited
value. Added some small comments in
https://github.com/apache/cassandra/commit/b226d3014b7cb13eb61b47bda2185fc1ccf0b1ef
> Expose Cassandra related system properties in a virtual table
> -
>
> Key: CASSANDRA-15616
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15616
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: High
> Fix For: 4.x
>
>
> Allow viewing Cassandra related system properties.
> Viewing yaml config settings, as implemented by {{SettingsTable}} in
> CASSANDRA-14573, is not enough for certain third-party tool use-cases. There
> are a number of system properties that can be defined that contribute to the
> configuration set that Cassandra runs on.
> An example of such a use-case is described in CASSANDRA-15339. JMX ports need
> to be discovered, especially in 4.0 where multiple nodes can run on one
> ipaddress. Unlike the native port that is through gossip discoverable, the
> jmx port is not. The jmx port is also not available via the SettingsTable.
> With this patch and {{SystemPropertiesTable}} it becomes possible to first
> discover all the native ports in the cluster and against each then discover
> each node's jmx port.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15564) Refactor repair coordinator so errors are consistent
[ https://issues.apache.org/jira/browse/CASSANDRA-15564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051527#comment-17051527 ] Chris Lohfink commented on CASSANDRA-15564: --- I like response time between the two, since service time being bad would still show up in it, it would be able to flag a wider range of problems > Refactor repair coordinator so errors are consistent > > > Key: CASSANDRA-15564 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15564 > Project: Cassandra > Issue Type: Sub-task > Components: Consistency/Repair >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Time Spent: 11h 10m > Remaining Estimate: 0h > > This is to split the change in CASSANDRA-15399 so the refactor is isolated > out. > Currently the repair coordinator special cases the exit cases at each call > site; this makes it so that errors can be inconsistent and there are cases > where proper complete isn't done (proper notifications, and forgetting to > update ActiveRepairService). > [Circle > CI|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorJmxConsistency] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15616) Expose Cassandra related system properties in a virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-15616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-15616:
--
Reviewers: Chris Lohfink (was: Chris Lohfink, Chris Lohfink)
> Expose Cassandra related system properties in a virtual table
> -
>
> Key: CASSANDRA-15616
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15616
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: High
> Fix For: 4.x
>
>
> Allow viewing Cassandra related system properties.
> Viewing yaml config settings, as implemented by {{SettingsTable}} in
> CASSANDRA-14573, is not enough for certain third-party tool use-cases. There
> are a number of system properties that can be define that also contribute to
> the configuration set that Cassandra runs on.
> An example of such a use-case is described in CASSANDRA-15339. JMX ports need
> to be discovered, especially in 4.0 where multiple nodes can run on one
> ipaddress. Unlike the native port that is through gossip discoverable, the
> jmx port is not. The jmx port is also not available via the SettingsTable.
> With this patch and {{SystemPropertiesTable}} it becomes possible to first
> discover all the native ports in the cluster and against each then discover
> each node's jmx port.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15616) Expose Cassandra related system properties in a virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-15616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-15616:
--
Reviewers: Chris Lohfink, Chris Lohfink
Status: Review In Progress (was: Patch Available)
> Expose Cassandra related system properties in a virtual table
> -
>
> Key: CASSANDRA-15616
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15616
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: High
> Fix For: 4.x
>
>
> Allow viewing Cassandra related system properties.
> Viewing yaml config settings, as implemented by {{SettingsTable}} in
> CASSANDRA-14573, is not enough for certain third-party tool use-cases. There
> are a number of system properties that can be define that also contribute to
> the configuration set that Cassandra runs on.
> An example of such a use-case is described in CASSANDRA-15339. JMX ports need
> to be discovered, especially in 4.0 where multiple nodes can run on one
> ipaddress. Unlike the native port that is through gossip discoverable, the
> jmx port is not. The jmx port is also not available via the SettingsTable.
> With this patch and {{SystemPropertiesTable}} it becomes possible to first
> discover all the native ports in the cluster and against each then discover
> each node's jmx port.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15570) Change name of table metrics virtual table percentile columns
[
https://issues.apache.org/jira/browse/CASSANDRA-15570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-15570:
--
Fix Version/s: 4.0
Source Control Link:
https://github.com/apache/cassandra/commit/47a315eaaa2288c78c508682a8961dac65122607
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Thanks for reviews
[commit|https://github.com/apache/cassandra/commit/47a315eaaa2288c78c508682a8961dac65122607]
> Change name of table metrics virtual table percentile columns
> -
>
> Key: CASSANDRA-15570
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15570
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available
> Fix For: 4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The column names {{50th}} and {{90th}} are difficult to query as a selector
> or in aggregation functions since our parser expects a letter for initial
> char. It currently requires quoting like:
> {code:sql}
> SELECT table_name, "50th_ms", "99th_ms" FROM system_views.local_read_latency
> {code}
> Which is kinda difficult and non obvious, the error we give when not quoted
> also isnt that helpful. Since it is percentile a simple thing is to just ad a
> p infront:
> {code:sql}
> SELECT table_name, p50th_ms, p99th_ms FROM system_views.local_read_latency
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15256) Clean up redundant nodetool commands added in 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-15256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15256: -- Fix Version/s: 4.0 > Clean up redundant nodetool commands added in 4.0 > - > > Key: CASSANDRA-15256 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15256 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Low > Fix For: 4.0 > > > Both hintedhandoff and getendpoints had a 2nd command added that does the > exact thing but rewritten (and in getReplicas not as well) not just aliased > (like cf->tablestats). Also a minor cleanup is same command added multiple > times to nodetool command list. We should clean this up before 4.0 release > before people become reliant on the newly introduced command name. If we want > them renamed as that we should rename and link with alias like we do with > cf->table others. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15473) New feature - Virtual Tables
[ https://issues.apache.org/jira/browse/CASSANDRA-15473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15473: -- Fix Version/s: 4.0-alpha Source Control Link: https://github.com/apache/cassandra/commit/d2c546ec9e21e1662d06ba30378fc3266629092c Resolution: Fixed Status: Resolved (was: Ready to Commit) > New feature - Virtual Tables > > > Key: CASSANDRA-15473 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15473 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > Fix For: 4.0-alpha > > > Added a page on virtual tables, a new feature. > https://github.com/apache/cassandra/pull/402 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15241) Virtual table to expose current running queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-15241:
--
Fix Version/s: 4.0
> Virtual table to expose current running queries
> ---
>
> Key: CASSANDRA-15241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15241
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
> Fix For: 4.0
>
>
> Expose current running queries and their duration.
> {code}cqlsh> select * from system_views.queries;
> thread_id| duration_micros | task
> --+-+-
> Native-Transport-Requests-17 |6325 | QUERY
> select * from system_views.queries; [pageSize = 100]
> Native-Transport-Requests-4 | 14681 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> Native-Transport-Requests-6 | 14678 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> ReadStage-10 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-13 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-14 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-19 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-20 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-22 |7279 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-23 |4716 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-5 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-7 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-8 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15473) New feature - Virtual Tables
[ https://issues.apache.org/jira/browse/CASSANDRA-15473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15473: -- Status: Ready to Commit (was: Changes Suggested) > New feature - Virtual Tables > > > Key: CASSANDRA-15473 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15473 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Added a page on virtual tables, a new feature. > https://github.com/apache/cassandra/pull/402 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15589) Add histogram to prepared statements and expose as virtual table
[ https://issues.apache.org/jira/browse/CASSANDRA-15589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039630#comment-17039630 ] Chris Lohfink commented on CASSANDRA-15589: --- this would give you a history of which ones are the worst. the queries virtual table are the _currently running_ queries only. > Add histogram to prepared statements and expose as virtual table > - > > Key: CASSANDRA-15589 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15589 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: Jon Haddad >Priority: Normal > > One of the biggest challenges as an operator is understanding what queries > are being executed and how long they take. We have the ability to take short > samples via profileload, but it’s lacking the full diagnostics that keeping > histograms on each prepared statement could give us. Having this would be a > massive benefit to most operators as they currently have no idea what > Cassandra is actually doing. > Before committing let’s be sure to record some CPU flame graphs to ensure > there isn’t noticeable performance overhead. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15241) Virtual table to expose current running queries
[
https://issues.apache.org/jira/browse/CASSANDRA-15241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink reassigned CASSANDRA-15241:
-
Assignee: Chris Lohfink (was: Chris Lohfink)
> Virtual table to expose current running queries
> ---
>
> Key: CASSANDRA-15241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15241
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
>
> Expose current running queries and their duration.
> {code}cqlsh> select * from system_views.queries;
> thread_id| duration_micros | task
> --+-+-
> Native-Transport-Requests-17 |6325 | QUERY
> select * from system_views.queries; [pageSize = 100]
> Native-Transport-Requests-4 | 14681 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> Native-Transport-Requests-6 | 14678 | EXECUTE
> f4115f91190d4acf09e452637f1f2444 with 0 values at consistency LOCAL_ONE
> ReadStage-10 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-13 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-14 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-19 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-20 | 11861 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-22 |7279 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-23 |4716 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-5 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-7 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000
> ReadStage-8 | 16535 |
>SELECT * FROM basic.wide1 LIMIT 5000{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15574) Don't shut down gossip before native transport
[ https://issues.apache.org/jira/browse/CASSANDRA-15574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15574: -- Bug Category: Parent values: Availability(12983) Complexity: Low Hanging Fruit Component/s: Cluster/Gossip Discovered By: User Report Severity: Low Status: Open (was: Triage Needed) > Don't shut down gossip before native transport > -- > > Key: CASSANDRA-15574 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15574 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: Chris Lohfink >Priority: Normal > > being shut down in wrong order causes unavailable exceptions: > https://github.com/apache/cassandra/blob/da90439f0052c3a05aaf6d4268a8c719e10fafde/src/java/org/apache/cassandra/service/StorageService.java#L394 > Should also do something like throw a WARN in stopGossping if rpc set to > ready or native is enabled. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15305) Fix multi DC nodetool status output
[
https://issues.apache.org/jira/browse/CASSANDRA-15305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17038655#comment-17038655
]
Chris Lohfink commented on CASSANDRA-15305:
---
Thanks for the review [~brandon.williams]!
| [tests|https://circleci.com/gh/clohfink/cassandra/694] |
[commit|https://github.com/apache/cassandra/commit/d9798369dd99cfe44b10aa0aefb5e20ca702e8c2]
|
> Fix multi DC nodetool status output
> ---
>
> Key: CASSANDRA-15305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15305
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> The DC headers are printed before the entire table output
> {code}
> Datacenter: eu-west-1
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> Datacenter: us-east-1
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address LoadTokens Owns (effective) Host ID
> Rack
> UN 100.67.118.115 76.85 KiB 1 16.7%
> e1bb616a-a22d-4452-a2eb-f14faa6c7900 eu-west-1c
> UN 100.67.97.192 110.42 KiB 1 16.7%
> fe552b3e-33bf-42c2-9c71-c4e49a034b70 eu-west-1a
> UN 100.67.107.135 76.85 KiB 1 16.7%
> a9079fbe-8d7b-4f07-8d5f-b9e70a63d799 eu-west-1b
> UN 100.67.97.213 94.59 KiB 1 16.7%
> 948e123a-7a92-4b35-974f-c7b380998e37 eu-west-1a
> UN 100.67.118.203 110.42 KiB 1 16.7%
> 6a7d1845-e966-4aba-9245-ed3f5c0805d6 eu-west-1c
> UN 100.67.107.110 110.42 KiB 1 16.7%
> 6e23da83-e9c8-4c43-a9d1-fb0d6e775cdc eu-west-1b
> -- Address LoadTokens Owns (effective) Host ID
> Rack
> UN 100.66.217.160 110.42 KiB 1 16.7%
> 7abef190-f4e7-46e6-9e8d-d4441e6b2e33 us-east-1c
> UN 100.66.220.37 110.42 KiB 1 16.7%
> 6712d2bf-c912-460f-abeb-278770ad7cb4 us-east-1e
> UN 100.66.220.90 110.43 KiB 1 16.7%
> dcb25670-4011-457c-8018-04b22042dde4 us-east-1e
> UN 100.66.216.184 110.42 KiB 1 16.7%
> b620b09a-3de8-41c3-a330-6cee808b4a84 us-east-1c
> UN 100.66.219.60 110.42 KiB 1 16.7%
> 34769195-c582-413f-a663-82f8544d9327 us-east-1d
> UN 100.66.219.93 110.42 KiB 1 16.7%
> 9ae3372c-1a04-457b-bcce-3562a328565e us-east-1d
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15305) Fix multi DC nodetool status output
[
https://issues.apache.org/jira/browse/CASSANDRA-15305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-15305:
--
Fix Version/s: (was: 4.0)
4.0-alpha
Since Version: 4.0-alpha
Source Control Link:
https://github.com/apache/cassandra/commit/d9798369dd99cfe44b10aa0aefb5e20ca702e8c2
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Fix multi DC nodetool status output
> ---
>
> Key: CASSANDRA-15305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15305
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> The DC headers are printed before the entire table output
> {code}
> Datacenter: eu-west-1
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> Datacenter: us-east-1
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address LoadTokens Owns (effective) Host ID
> Rack
> UN 100.67.118.115 76.85 KiB 1 16.7%
> e1bb616a-a22d-4452-a2eb-f14faa6c7900 eu-west-1c
> UN 100.67.97.192 110.42 KiB 1 16.7%
> fe552b3e-33bf-42c2-9c71-c4e49a034b70 eu-west-1a
> UN 100.67.107.135 76.85 KiB 1 16.7%
> a9079fbe-8d7b-4f07-8d5f-b9e70a63d799 eu-west-1b
> UN 100.67.97.213 94.59 KiB 1 16.7%
> 948e123a-7a92-4b35-974f-c7b380998e37 eu-west-1a
> UN 100.67.118.203 110.42 KiB 1 16.7%
> 6a7d1845-e966-4aba-9245-ed3f5c0805d6 eu-west-1c
> UN 100.67.107.110 110.42 KiB 1 16.7%
> 6e23da83-e9c8-4c43-a9d1-fb0d6e775cdc eu-west-1b
> -- Address LoadTokens Owns (effective) Host ID
> Rack
> UN 100.66.217.160 110.42 KiB 1 16.7%
> 7abef190-f4e7-46e6-9e8d-d4441e6b2e33 us-east-1c
> UN 100.66.220.37 110.42 KiB 1 16.7%
> 6712d2bf-c912-460f-abeb-278770ad7cb4 us-east-1e
> UN 100.66.220.90 110.43 KiB 1 16.7%
> dcb25670-4011-457c-8018-04b22042dde4 us-east-1e
> UN 100.66.216.184 110.42 KiB 1 16.7%
> b620b09a-3de8-41c3-a330-6cee808b4a84 us-east-1c
> UN 100.66.219.60 110.42 KiB 1 16.7%
> 34769195-c582-413f-a663-82f8544d9327 us-east-1d
> UN 100.66.219.93 110.42 KiB 1 16.7%
> 9ae3372c-1a04-457b-bcce-3562a328565e us-east-1d
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15305) Fix multi DC nodetool status output
[
https://issues.apache.org/jira/browse/CASSANDRA-15305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-15305:
--
Reviewers: Brandon Williams, Chris Lohfink (was: Brandon Williams)
Status: Review In Progress (was: Patch Available)
> Fix multi DC nodetool status output
> ---
>
> Key: CASSANDRA-15305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15305
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
> Fix For: 4.0
>
>
> The DC headers are printed before the entire table output
> {code}
> Datacenter: eu-west-1
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> Datacenter: us-east-1
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address LoadTokens Owns (effective) Host ID
> Rack
> UN 100.67.118.115 76.85 KiB 1 16.7%
> e1bb616a-a22d-4452-a2eb-f14faa6c7900 eu-west-1c
> UN 100.67.97.192 110.42 KiB 1 16.7%
> fe552b3e-33bf-42c2-9c71-c4e49a034b70 eu-west-1a
> UN 100.67.107.135 76.85 KiB 1 16.7%
> a9079fbe-8d7b-4f07-8d5f-b9e70a63d799 eu-west-1b
> UN 100.67.97.213 94.59 KiB 1 16.7%
> 948e123a-7a92-4b35-974f-c7b380998e37 eu-west-1a
> UN 100.67.118.203 110.42 KiB 1 16.7%
> 6a7d1845-e966-4aba-9245-ed3f5c0805d6 eu-west-1c
> UN 100.67.107.110 110.42 KiB 1 16.7%
> 6e23da83-e9c8-4c43-a9d1-fb0d6e775cdc eu-west-1b
> -- Address LoadTokens Owns (effective) Host ID
> Rack
> UN 100.66.217.160 110.42 KiB 1 16.7%
> 7abef190-f4e7-46e6-9e8d-d4441e6b2e33 us-east-1c
> UN 100.66.220.37 110.42 KiB 1 16.7%
> 6712d2bf-c912-460f-abeb-278770ad7cb4 us-east-1e
> UN 100.66.220.90 110.43 KiB 1 16.7%
> dcb25670-4011-457c-8018-04b22042dde4 us-east-1e
> UN 100.66.216.184 110.42 KiB 1 16.7%
> b620b09a-3de8-41c3-a330-6cee808b4a84 us-east-1c
> UN 100.66.219.60 110.42 KiB 1 16.7%
> 34769195-c582-413f-a663-82f8544d9327 us-east-1d
> UN 100.66.219.93 110.42 KiB 1 16.7%
> 9ae3372c-1a04-457b-bcce-3562a328565e us-east-1d
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15305) Fix multi DC nodetool status output
[
https://issues.apache.org/jira/browse/CASSANDRA-15305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-15305:
--
Status: Ready to Commit (was: Review In Progress)
> Fix multi DC nodetool status output
> ---
>
> Key: CASSANDRA-15305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15305
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Normal
> Fix For: 4.0
>
>
> The DC headers are printed before the entire table output
> {code}
> Datacenter: eu-west-1
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> Datacenter: us-east-1
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address LoadTokens Owns (effective) Host ID
> Rack
> UN 100.67.118.115 76.85 KiB 1 16.7%
> e1bb616a-a22d-4452-a2eb-f14faa6c7900 eu-west-1c
> UN 100.67.97.192 110.42 KiB 1 16.7%
> fe552b3e-33bf-42c2-9c71-c4e49a034b70 eu-west-1a
> UN 100.67.107.135 76.85 KiB 1 16.7%
> a9079fbe-8d7b-4f07-8d5f-b9e70a63d799 eu-west-1b
> UN 100.67.97.213 94.59 KiB 1 16.7%
> 948e123a-7a92-4b35-974f-c7b380998e37 eu-west-1a
> UN 100.67.118.203 110.42 KiB 1 16.7%
> 6a7d1845-e966-4aba-9245-ed3f5c0805d6 eu-west-1c
> UN 100.67.107.110 110.42 KiB 1 16.7%
> 6e23da83-e9c8-4c43-a9d1-fb0d6e775cdc eu-west-1b
> -- Address LoadTokens Owns (effective) Host ID
> Rack
> UN 100.66.217.160 110.42 KiB 1 16.7%
> 7abef190-f4e7-46e6-9e8d-d4441e6b2e33 us-east-1c
> UN 100.66.220.37 110.42 KiB 1 16.7%
> 6712d2bf-c912-460f-abeb-278770ad7cb4 us-east-1e
> UN 100.66.220.90 110.43 KiB 1 16.7%
> dcb25670-4011-457c-8018-04b22042dde4 us-east-1e
> UN 100.66.216.184 110.42 KiB 1 16.7%
> b620b09a-3de8-41c3-a330-6cee808b4a84 us-east-1c
> UN 100.66.219.60 110.42 KiB 1 16.7%
> 34769195-c582-413f-a663-82f8544d9327 us-east-1d
> UN 100.66.219.93 110.42 KiB 1 16.7%
> 9ae3372c-1a04-457b-bcce-3562a328565e us-east-1d
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15574) Don't shut down gossip before native transport
Chris Lohfink created CASSANDRA-15574: - Summary: Don't shut down gossip before native transport Key: CASSANDRA-15574 URL: https://issues.apache.org/jira/browse/CASSANDRA-15574 Project: Cassandra Issue Type: Bug Reporter: Chris Lohfink being shut down in wrong order causes unavailable exceptions: https://github.com/apache/cassandra/blob/da90439f0052c3a05aaf6d4268a8c719e10fafde/src/java/org/apache/cassandra/service/StorageService.java#L394 Should also do something like throw a WARN in stopGossping if rpc set to ready or native is enabled. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15543) flaky test org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-15543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-15543:
--
Summary: flaky test
org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
(was: flaky test
org.apache.cassandra.distributed.test.DistributedReadWritePathTest.readWithSchemaDisagreement)
> flaky test
> org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
> ---
>
> Key: CASSANDRA-15543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15543
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> This fails infrequently, last seen failure was on java 8
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.distributed.test.DistributedReadWritePathTest.readWithSchemaDisagreement(DistributedReadWritePathTest.java:276)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15543) flaky test org.apache.cassandra.distributed.test.DistributedReadWritePathTest.readWithSchemaDisagreement
[
https://issues.apache.org/jira/browse/CASSANDRA-15543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17038574#comment-17038574
]
Chris Lohfink commented on CASSANDRA-15543:
---
renamed to SimpleReadWriteTest so :
{code}
junit.framework.AssertionFailedError
at
org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement(SimpleReadWriteTest.java:274)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{code}
as seen in https://circleci.com/gh/clohfink/cassandra/674
> flaky test
> org.apache.cassandra.distributed.test.DistributedReadWritePathTest.readWithSchemaDisagreement
>
>
> Key: CASSANDRA-15543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15543
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> This fails infrequently, last seen failure was on java 8
> {code}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.distributed.test.DistributedReadWritePathTest.readWithSchemaDisagreement(DistributedReadWritePathTest.java:276)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15570) Change name of table metrics virtual table percentile columns
[
https://issues.apache.org/jira/browse/CASSANDRA-15570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-15570:
--
Change Category: Operability
Complexity: Low Hanging Fruit
Component/s: Feature/Virtual Tables
Assignee: Chris Lohfink
Priority: Low (was: Normal)
Status: Open (was: Triage Needed)
> Change name of table metrics virtual table percentile columns
> -
>
> Key: CASSANDRA-15570
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15570
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The column names {{50th}} and {{90th}} are difficult to query as a selector
> or in aggregation functions since our parser expects a letter for initial
> char. It currently requires quoting like:
> {code:sql}
> SELECT table_name, "50th_ms", "99th_ms" FROM system_views.local_read_latency
> {code}
> Which is kinda difficult and non obvious, the error we give when not quoted
> also isnt that helpful. Since it is percentile a simple thing is to just ad a
> p infront:
> {code:sql}
> SELECT table_name, p50th_ms, p99th_ms FROM system_views.local_read_latency
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15570) Change name of table metrics virtual table percentile columns
[
https://issues.apache.org/jira/browse/CASSANDRA-15570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-15570:
--
Test and Documentation Plan: na
Status: Patch Available (was: Open)
> Change name of table metrics virtual table percentile columns
> -
>
> Key: CASSANDRA-15570
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15570
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Chris Lohfink
>Assignee: Chris Lohfink
>Priority: Low
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The column names {{50th}} and {{90th}} are difficult to query as a selector
> or in aggregation functions since our parser expects a letter for initial
> char. It currently requires quoting like:
> {code:sql}
> SELECT table_name, "50th_ms", "99th_ms" FROM system_views.local_read_latency
> {code}
> Which is kinda difficult and non obvious, the error we give when not quoted
> also isnt that helpful. Since it is percentile a simple thing is to just ad a
> p infront:
> {code:sql}
> SELECT table_name, p50th_ms, p99th_ms FROM system_views.local_read_latency
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15570) Change name of table metrics virtual table percentile columns
Chris Lohfink created CASSANDRA-15570:
-
Summary: Change name of table metrics virtual table percentile
columns
Key: CASSANDRA-15570
URL: https://issues.apache.org/jira/browse/CASSANDRA-15570
Project: Cassandra
Issue Type: Improvement
Reporter: Chris Lohfink
The column names {{50th}} and {{90th}} are difficult to query as a selector or
in aggregation functions since our parser expects a letter for initial char. It
currently requires quoting like:
{code:sql}
SELECT table_name, "50th_ms", "99th_ms" FROM system_views.local_read_latency
{code}
Which is kinda difficult and non obvious, the error we give when not quoted
also isnt that helpful. Since it is percentile a simple thing is to just ad a p
infront:
{code:sql}
SELECT table_name, p50th_ms, p99th_ms FROM system_views.local_read_latency
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15473) New feature - Virtual Tables
[ https://issues.apache.org/jira/browse/CASSANDRA-15473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15473: -- Status: Changes Suggested (was: Review In Progress) > New feature - Virtual Tables > > > Key: CASSANDRA-15473 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15473 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Added a page on virtual tables, a new feature. > https://github.com/apache/cassandra/pull/402 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15473) New feature - Virtual Tables
[ https://issues.apache.org/jira/browse/CASSANDRA-15473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15473: -- Reviewers: Chris Lohfink, Chris Lohfink (was: Chris Lohfink) Status: Review In Progress (was: Patch Available) > New feature - Virtual Tables > > > Key: CASSANDRA-15473 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15473 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Added a page on virtual tables, a new feature. > https://github.com/apache/cassandra/pull/402 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14872) Update to version of python driver and update cqlsh to use driver metadata for virtual tables
[
https://issues.apache.org/jira/browse/CASSANDRA-14872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Lohfink updated CASSANDRA-14872:
--
Fix Version/s: 4.0
> Update to version of python driver and update cqlsh to use driver metadata
> for virtual tables
> -
>
> Key: CASSANDRA-14872
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14872
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL, Legacy/Tools
>Reporter: Andy Tolbert
>Priority: Normal
> Fix For: 4.0
>
>
> When virtual tables were implemented ([CASSANDRA-7622]), cqlsh.py was updated
> to parse virtual keyspace metadata by making queries to the
> {{system_virtual_schema}} table and included a TODO:
> {code:python}
> # TODO remove after virtual tables are added to connection metadata
> {code}
> Since python driver 3.15.0 (released in August), the driver now parses
> virtual keyspace metadata. It would be good to update the bundled python
> driver and simplify cqlsh code to utilize its capability to parse virtual
> tables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15519) Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at runtime
[ https://issues.apache.org/jira/browse/CASSANDRA-15519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15519: -- Source Control Link: https://github.com/apache/cassandra/commit/da90439f0052c3a05aaf6d4268a8c719e10fafde Resolution: Fixed Status: Resolved (was: Ready to Commit) > Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at > runtime > - > > Key: CASSANDRA-15519 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15519 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config, Messaging/Client >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-15013 added configurable global and per endpoint limits on the > number of in flight requests, measured in bytes. During times when the > cluster is overloaded, it can be useful to change this setting without having > to restart the Cassandra process. Changing the limits should affect all > existing and new connections. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15519) Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at runtime
[ https://issues.apache.org/jira/browse/CASSANDRA-15519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Lohfink updated CASSANDRA-15519: -- Reviewers: Chris Lohfink, Sumanth Pasupuleti (was: Sumanth Pasupuleti) > Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at > runtime > - > > Key: CASSANDRA-15519 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15519 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config, Messaging/Client >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-15013 added configurable global and per endpoint limits on the > number of in flight requests, measured in bytes. During times when the > cluster is overloaded, it can be useful to change this setting without having > to restart the Cassandra process. Changing the limits should affect all > existing and new connections. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15519) Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at runtime
[ https://issues.apache.org/jira/browse/CASSANDRA-15519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17030828#comment-17030828 ] Chris Lohfink commented on CASSANDRA-15519: --- +1 lgtm > Make native_transport_max_concurrent_requests_in_bytes(_per_ip) changeable at > runtime > - > > Key: CASSANDRA-15519 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15519 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config, Messaging/Client >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-15013 added configurable global and per endpoint limits on the > number of in flight requests, measured in bytes. During times when the > cluster is overloaded, it can be useful to change this setting without having > to restart the Cassandra process. Changing the limits should affect all > existing and new connections. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
