[jira] [Commented] (CASSANDRA-16095) When a table attempts to clean up metrics, it was cleaning up all global table metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236565#comment-17236565
]
Yifan Cai commented on CASSANDRA-16095:
---
Thank you for the fix. +1
> When a table attempts to clean up metrics, it was cleaning up all global
> table metrics
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Altan Özlü
>Assignee: David Capwell
>Priority: Urgent
> Fix For: 4.0-beta
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
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-16095) When a table attempts to clean up metrics, it was cleaning up all global table metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-16095:
--
Reviewers: Jon Meredith, Yifan Cai (was: Jon Meredith)
> When a table attempts to clean up metrics, it was cleaning up all global
> table metrics
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Altan Özlü
>Assignee: David Capwell
>Priority: Urgent
> Fix For: 4.0-beta
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
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-16095) When a table attempts to clean up metrics, it was cleaning up all global table metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236543#comment-17236543
]
Yifan Cai commented on CASSANDRA-16095:
---
The issue is caused static value {{TableMetrics#all}}.
The patch looks good overall. Left several small comments in the PR.
> When a table attempts to clean up metrics, it was cleaning up all global
> table metrics
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Altan Özlü
>Assignee: David Capwell
>Priority: Urgent
> Fix For: 4.0-beta
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
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-16095) When a table attempts to clean up metrics, it was cleaning up all global table metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236537#comment-17236537
]
Jon Meredith commented on CASSANDRA-16095:
--
+1 from me
> When a table attempts to clean up metrics, it was cleaning up all global
> table metrics
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Altan Özlü
>Assignee: David Capwell
>Priority: Urgent
> Fix For: 4.0-beta
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
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-16095) When a table attempts to clean up metrics, it was cleaning up all global table metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236526#comment-17236526
]
David Capwell commented on CASSANDRA-16095:
---
Jon +1ed in GH
> When a table attempts to clean up metrics, it was cleaning up all global
> table metrics
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Altan Özlü
>Assignee: David Capwell
>Priority: Urgent
> Fix For: 4.0-beta
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
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-16095) When a table attempts to clean up metrics, it was cleaning up all global table metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16095:
--
Reviewers: Jon Meredith (was: David Capwell, Jon Meredith)
> When a table attempts to clean up metrics, it was cleaning up all global
> table metrics
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Altan Özlü
>Assignee: David Capwell
>Priority: Urgent
> Fix For: 4.0-beta
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
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-16095) When a table attempts to clean up metrics, it was cleaning up all global table metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16095:
--
Reviewers: Jon Meredith, David Capwell (was: David Capwell, Jon Meredith)
Jon Meredith, David Capwell
Status: Review In Progress (was: Patch Available)
> When a table attempts to clean up metrics, it was cleaning up all global
> table metrics
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Altan Özlü
>Assignee: David Capwell
>Priority: Urgent
> Fix For: 4.0-beta
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
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-16095) When a table attempts to clean up metrics, it was cleaning up all global table metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16095:
--
Summary: When a table attempts to clean up metrics, it was cleaning up all
global table metrics (was: Nodetool tablestats WriteLatency error)
> When a table attempts to clean up metrics, it was cleaning up all global
> table metrics
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Altan Özlü
>Assignee: David Capwell
>Priority: Urgent
> Fix For: 4.0-beta
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
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-16095) Nodetool tablestats WriteLatency error
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16095:
--
Test and Documentation Plan: added tests
Status: Patch Available (was: In Progress)
> Nodetool tablestats WriteLatency error
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Altan Özlü
>Assignee: David Capwell
>Priority: Urgent
> Fix For: 4.0-beta
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
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-16095) Nodetool tablestats WriteLatency error
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236460#comment-17236460
]
David Capwell commented on CASSANDRA-16095:
---
Tested on 3.0 and not able to replicate, so looks like CASSANDRA-7273 didn't do
this but something over time saw the lower case global static field and tried
to use it differently.
> Nodetool tablestats WriteLatency error
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Altan Özlü
>Assignee: David Capwell
>Priority: Urgent
> Fix For: 4.0-beta
>
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
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-15582) 4.0 quality testing: metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236458#comment-17236458
]
David Capwell commented on CASSANDRA-15582:
---
Linking CASSANDRA-16095 as it impacts metrics when schema changes happens.
> 4.0 quality testing: metrics
>
>
> Key: CASSANDRA-15582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15582
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: Screen Shot 2020-04-07 at 5.47.17 PM.png
>
>
> The goal of this ticket is to have a proper testing of the different metrics
> exposed via JMX, and to ensure that metrics that are not in used in 4.0 have
> been properly deprecated.
> The following table show the current status of the metric tests and can be
> used to track the progress of that ticket:
> || Metrics || Status || test types || JIRA tickets ||
> | Batch | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15718 |
> | BufferPool | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15773
> |
> | Cache | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15788 |
> | Client | {color:#DE350B}*TESTS MISSING*{color}| unit tests |
> CASSANDRA-16216 |
> | ClientRequest | {color:#00875A}*COVERED*{color} | in-jvm tests |
> CASSANDRA-16183 |
> | ClientRequestSize | {color:#00875A}*COVERED*{color} | unit tests |
> CASSANDRA-16184 |
> | Cache | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15788 |
> | CommitLog | {color:#DE350B}*TESTS MISSING*{color} | unit tests |
> CASSANDRA-16185 |
> | Compaction | {color:#DE350B}*TESTS MISSING*{color} | unit tests |
> CASSANDRA-16192 |
> | CQL | {color:#00875A}*COVERED*{color}| unit tests | |
> | HintService | {color:#DE350B}*NO TESTS*{color} | dtests | CASSANDRA-16189 |
> | Messaging/Internode| {color:#DE350B}*NO TESTS*{color} | in-jvm dtests |
> CASSANDRA-16193 |
> | ReadRepair| {color:#DE350B}*TESTS MISSING*{color} | dtests,in-jvm dtests |
> CASSANDRA-16187 |
> | Repair | {color:#DE350B}*NO TESTS*{color} | in-jvm dtests | CASSANDRA-16191
> |
> | Storage | {color:#00875A}*COVERED*{color}| unit tests | |
> | Streaming | {color:#DE350B}*NO TESTS*{color} | dtests | CASSANDRA-16190 |
> | Keyspace | {color:#DE350B}*TESTS MISSING*{color} | unit tests/in-jvm dtests
> | CASSANDRA-16188 |
> | Table | {color:#DE350B}*TESTS MISSING*{color} | unit tests/in-jvm dtests |
> CASSANDRA-16188 |
> | ThreadPoolMetrics |{color:#00875A}*COVERED*{color} | unit tests |
> CASSANDRA-16186 |
--
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-16095) Nodetool tablestats WriteLatency error
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236448#comment-17236448
]
David Capwell edited comment on CASSANDRA-16095 at 11/20/20, 9:24 PM:
--
Seems global static state was added to CASSANDRA-7273 with names that are lower
case, so all the cleanup logic for a single table attempts to delete all global
metrics...
was (Author: dcapwell):
Seems global static state was added to CASSANDRA-14888 with names that are
lower case, so all the cleanup logic for a single table attempts to delete all
global metrics...
> Nodetool tablestats WriteLatency error
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Altan Özlü
>Assignee: David Capwell
>Priority: Urgent
> Fix For: 4.0-beta
>
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
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-16095) Nodetool tablestats WriteLatency error
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236448#comment-17236448
]
David Capwell commented on CASSANDRA-16095:
---
Seems global static state was added to CASSANDRA-14888 with names that are
lower case, so all the cleanup logic for a single table attempts to delete all
global metrics...
> Nodetool tablestats WriteLatency error
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Altan Özlü
>Assignee: David Capwell
>Priority: Urgent
> Fix For: 4.0-beta
>
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
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-16225) Followup CASSANDRA-14554
[ https://issues.apache.org/jira/browse/CASSANDRA-16225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236446#comment-17236446 ] Jon Meredith commented on CASSANDRA-16225: -- In-tree tests passed on my cherry-pick for trunk. > Followup CASSANDRA-14554 > > > Key: CASSANDRA-16225 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16225 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-beta, 4.0-beta4, 3.0.24, 3.11.10 > > > As per [~stefania]'s advice, additional synchronization should be added to > LogTransaction.java. Without synchronization, we could have corrupted txn log > files with JBOD. -- 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-16095) Nodetool tablestats WriteLatency error
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16095:
--
Bug Category: Parent values: Correctness(12982)Level 1 values:
Unrecoverable Corruption / Loss(13161)
Complexity: Low Hanging Fruit
Component/s: Observability/JMX
Discovered By: User Report
Severity: Critical
Since Version: 4.0-alpha1
> Nodetool tablestats WriteLatency error
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Altan Özlü
>Assignee: David Capwell
>Priority: Urgent
> Fix For: 4.0-beta
>
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
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-16095) Nodetool tablestats WriteLatency error
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16095:
--
Fix Version/s: 4.0-beta
> Nodetool tablestats WriteLatency error
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
>Reporter: Altan Özlü
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0-beta
>
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
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-16095) Nodetool tablestats WriteLatency error
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16095:
--
Resolution: (was: Not A Problem)
Status: Open (was: Resolved)
Confirmed this is actually an issue, and is unrelated to JDK version.
> Nodetool tablestats WriteLatency error
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
>Reporter: Altan Özlü
>Priority: Normal
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
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-16095) Nodetool tablestats WriteLatency error
[
https://issues.apache.org/jira/browse/CASSANDRA-16095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell reassigned CASSANDRA-16095:
-
Assignee: David Capwell
> Nodetool tablestats WriteLatency error
> --
>
> Key: CASSANDRA-16095
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16095
> Project: Cassandra
> Issue Type: Bug
>Reporter: Altan Özlü
>Assignee: David Capwell
>Priority: Normal
>
> when i use
> {code:java}
> bin/nodetool tablestats {code}
> i get this error
> {code:java}
> error:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> -- StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.metrics:type=Table,keyspace=,scope=feed,name=WriteLatency
> {code}
> if i restart the node and check it works but if i write something then i get
> the error again
> * Cassandra 4.0-beta1
> * Ubuntu 20
--
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-16217) Minimal 4.0 COMPACT STORAGE backport
[ https://issues.apache.org/jira/browse/CASSANDRA-16217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236232#comment-17236232 ] Alex Petrov edited comment on CASSANDRA-16217 at 11/20/20, 8:13 PM: [~e.dimitrova] since we have added upgrade dtests [here|https://github.com/apache/cassandra/commit/8ffec0f02cf73c3d3a8c01aa2d856647a5620a21#diff-80d21b6bed7c174f700bd5d003122180c67b6615a2bc9c64aa9077ad9dc7cd8aR31] as in-jvm dtests, I do not think it's necessary to update python tests. Patch to remove ones you have pointed out: https://github.com/apache/cassandra-dtest/pull/104 was (Author: ifesdjeen): [~e.dimitrova] since we have added upgrade dtests [here|https://github.com/apache/cassandra/commit/8ffec0f02cf73c3d3a8c01aa2d856647a5620a21#diff-80d21b6bed7c174f700bd5d003122180c67b6615a2bc9c64aa9077ad9dc7cd8aR31] as in-jvm dtests, I do not think it's necessary to update python tests. Patch to remove ones you have pointed out: https://github.com/ifesdjeen/cassandra-dtest/pull/new/CASSANDRA-16217-followup > Minimal 4.0 COMPACT STORAGE backport > > > Key: CASSANDRA-16217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16217 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0-beta4 > > Time Spent: 20m > Remaining Estimate: 0h > > There are several behavioural changes related to compact storage, and these > differences are larger than most of us have anticipated: we first thought > there’ll be that “appearing column”, but there’s implicit nulls in > clusterings thing, and row vs column deletion. > Some of the recent issues on the subject are: CASSANDRA-16048, which allows > to ignore these differences. The other one was trying to improve user > experience of anyone still using compact storage: CASSANDRA-15811. > Easily reproducible differernces are: > (1) hidden columns show up, which breaks SELECT * queries > (2) DELETE v and UPDATE v WITH TTL would result into row removals in > non-dense compact tables (CASSANDRA-16069) > (3) INSERT allows skipping clusterings, which are filled with nulls by > default. > Some of these are tricky to support, as 15811 has shown. Anyone on OSS side > who might want to upgrade to 4.0 while still using compact storage might be > affected by being forced into one of these behaviours. > Possible solutions are to document these behaviours, or to bring back a > minimal set of COMPACT STORAGE to keep supporting these. > It looks like it is possible to leave some of the functionality related to > DENSE flag and allow it to be present in 4.0, but only for these three (and > potential related, however not direrclty visible) cases. > [~e.dimitrova] since you were working on removal on compact storage, wanted > to reassure that this is not a revert of your patch. On contrary: your patch > was instrumental in identifying the right places. > cc [~slebresne] [~aleksey] [~benedict] [~marcuse] > |[patch|https://github.com/apache/cassandra/pull/785]|[ci|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=13994-followup]| -- 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-16295) upgradesstables/scrub support for 2.x sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-16295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16295:
Fix Version/s: 3.0.x
> upgradesstables/scrub support for 2.x sstables
> --
>
> Key: CASSANDRA-16295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16295
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x
>
>
> This support is important for 2.0/3.0 cluster or 3.0/4.0 cluster that
> can/might contain 2.x sstables.
> 4.0 supports versions down to {{ma}}, and 3.0 supports versions down to
> {{jb}} (3.0 and 2.0.1 correspondingly). So by the time you're on 4.0, you
> should have no 2.0 sstables either way, and this needs to be fixed for 3.0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15897) Dropping compact storage with 2.1-sstables on disk make them unreadable
[ https://issues.apache.org/jira/browse/CASSANDRA-15897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236398#comment-17236398 ] Ekaterina Dimitrova commented on CASSANDRA-15897: - Thanks [~ifesdjeen]. I just opened CASSANDRA-16295 for the upgradesstables/scrub support. And if no one pick up the current patch for the other problem in hand in this ticket, I can rebase and finish whatever is needed after Thanksgiving. > Dropping compact storage with 2.1-sstables on disk make them unreadable > --- > > Key: CASSANDRA-15897 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15897 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Marcus Eriksson >Assignee: Sylvain Lebresne >Priority: Normal > Fix For: 3.0.x, 4.0-beta > > > Test reproducing: > https://github.com/krummas/cassandra/commits/marcuse/dropcompactstorage -- 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-16295) upgradesstables/scrub support for 2.x sstables
[
https://issues.apache.org/jira/browse/CASSANDRA-16295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16295:
Bug Category: Parent values: Availability(12983)
Complexity: Normal
Component/s: Legacy/Local Write-Read Paths
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> upgradesstables/scrub support for 2.x sstables
> --
>
> Key: CASSANDRA-16295
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16295
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> This support is important for 2.0/3.0 cluster or 3.0/4.0 cluster that
> can/might contain 2.x sstables.
> 4.0 supports versions down to {{ma}}, and 3.0 supports versions down to
> {{jb}} (3.0 and 2.0.1 correspondingly). So by the time you're on 4.0, you
> should have no 2.0 sstables either way, and this needs to be fixed for 3.0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16295) upgradesstables/scrub support for 2.x sstables
Ekaterina Dimitrova created CASSANDRA-16295:
---
Summary: upgradesstables/scrub support for 2.x sstables
Key: CASSANDRA-16295
URL: https://issues.apache.org/jira/browse/CASSANDRA-16295
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
This support is important for 2.0/3.0 cluster or 3.0/4.0 cluster that can/might
contain 2.x sstables.
4.0 supports versions down to {{ma}}, and 3.0 supports versions down to {{jb}}
(3.0 and 2.0.1 correspondingly). So by the time you're on 4.0, you should have
no 2.0 sstables either way, and this needs to be fixed for 3.0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16261) Prevent unbounded number of flushing tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-16261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236379#comment-17236379 ] Ekaterina Dimitrova edited comment on CASSANDRA-16261 at 11/20/20, 7:04 PM: My bad, I was primarily referring to this one - [https://cassandra.apache.org/doc/latest/development/patches.html?highlight=contributions] But I agree with you. I will apply the patch to the other two branches later today. Thank you! was (Author: e.dimitrova): My bad, I was primarily referring to this one - [https://cassandra.apache.org/doc/latest/development/patches.html?highlight=contributions] But I agree with you. I will add it to the other two branches later today. Thank you! > Prevent unbounded number of flushing tasks > -- > > Key: CASSANDRA-16261 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16261 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x, 4.0-beta4 > > > The cleaner thread is not prevented from queueing an unbounded number of > flushing tasks for memtables that are almost empty. -- 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-16261) Prevent unbounded number of flushing tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-16261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236379#comment-17236379 ] Ekaterina Dimitrova edited comment on CASSANDRA-16261 at 11/20/20, 7:01 PM: My bad, I was primarily referring to this one - [https://cassandra.apache.org/doc/latest/development/patches.html?highlight=contributions] But I agree with you. I will add it to the other two branches later today. Thank you! was (Author: e.dimitrova): My bad, I meant really this one - [https://cassandra.apache.org/doc/latest/development/patches.html?highlight=contributions] But I agree with you. I will add it to the other two branches later today. Thank you! > Prevent unbounded number of flushing tasks > -- > > Key: CASSANDRA-16261 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16261 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x, 4.0-beta4 > > > The cleaner thread is not prevented from queueing an unbounded number of > flushing tasks for memtables that are almost empty. -- 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-16261) Prevent unbounded number of flushing tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-16261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236379#comment-17236379 ] Ekaterina Dimitrova commented on CASSANDRA-16261: - My bad, I meant really this one - [https://cassandra.apache.org/doc/latest/development/patches.html?highlight=contributions] But I agree with you. I will add it to the other two branches later today. Thank you! > Prevent unbounded number of flushing tasks > -- > > Key: CASSANDRA-16261 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16261 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x, 4.0-beta4 > > > The cleaner thread is not prevented from queueing an unbounded number of > flushing tasks for memtables that are almost empty. -- 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-16294) Potential NPE in JVMStabilityInspector
[ https://issues.apache.org/jira/browse/CASSANDRA-16294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16294: -- Status: Ready to Commit (was: Review In Progress) LGTM +1 > Potential NPE in JVMStabilityInspector > -- > > Key: CASSANDRA-16294 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16294 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-beta > > > On either a FileNotFoundException or SocketException, JVMStabilityInspector > checks the error message for the string "Too many open files". However, both > of these exceptions have a constructor which sets a null message, which can > lead to NPE if handled. -- 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-16294) Potential NPE in JVMStabilityInspector
[ https://issues.apache.org/jira/browse/CASSANDRA-16294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-16294: -- Reviewers: David Capwell, David Capwell (was: David Capwell) David Capwell, David Capwell Status: Review In Progress (was: Patch Available) > Potential NPE in JVMStabilityInspector > -- > > Key: CASSANDRA-16294 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16294 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-beta > > > On either a FileNotFoundException or SocketException, JVMStabilityInspector > checks the error message for the string "Too many open files". However, both > of these exceptions have a constructor which sets a null message, which can > lead to NPE if handled. -- 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-16217) Minimal 4.0 COMPACT STORAGE backport
[ https://issues.apache.org/jira/browse/CASSANDRA-16217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236373#comment-17236373 ] David Capwell commented on CASSANDRA-16217: --- thanks for clarifying. > Minimal 4.0 COMPACT STORAGE backport > > > Key: CASSANDRA-16217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16217 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0-beta4 > > Time Spent: 20m > Remaining Estimate: 0h > > There are several behavioural changes related to compact storage, and these > differences are larger than most of us have anticipated: we first thought > there’ll be that “appearing column”, but there’s implicit nulls in > clusterings thing, and row vs column deletion. > Some of the recent issues on the subject are: CASSANDRA-16048, which allows > to ignore these differences. The other one was trying to improve user > experience of anyone still using compact storage: CASSANDRA-15811. > Easily reproducible differernces are: > (1) hidden columns show up, which breaks SELECT * queries > (2) DELETE v and UPDATE v WITH TTL would result into row removals in > non-dense compact tables (CASSANDRA-16069) > (3) INSERT allows skipping clusterings, which are filled with nulls by > default. > Some of these are tricky to support, as 15811 has shown. Anyone on OSS side > who might want to upgrade to 4.0 while still using compact storage might be > affected by being forced into one of these behaviours. > Possible solutions are to document these behaviours, or to bring back a > minimal set of COMPACT STORAGE to keep supporting these. > It looks like it is possible to leave some of the functionality related to > DENSE flag and allow it to be present in 4.0, but only for these three (and > potential related, however not direrclty visible) cases. > [~e.dimitrova] since you were working on removal on compact storage, wanted > to reassure that this is not a revert of your patch. On contrary: your patch > was instrumental in identifying the right places. > cc [~slebresne] [~aleksey] [~benedict] [~marcuse] > |[patch|https://github.com/apache/cassandra/pull/785]|[ci|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=13994-followup]| -- 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-16217) Minimal 4.0 COMPACT STORAGE backport
[ https://issues.apache.org/jira/browse/CASSANDRA-16217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236369#comment-17236369 ] Alex Petrov commented on CASSANDRA-16217: - Just to make sure: above patch only removes tests that aren’t applicable (in other words, ones that are testing that 4.0 won’t start). We will not delete any tests that test actual functionality. > Minimal 4.0 COMPACT STORAGE backport > > > Key: CASSANDRA-16217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16217 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0-beta4 > > Time Spent: 20m > Remaining Estimate: 0h > > There are several behavioural changes related to compact storage, and these > differences are larger than most of us have anticipated: we first thought > there’ll be that “appearing column”, but there’s implicit nulls in > clusterings thing, and row vs column deletion. > Some of the recent issues on the subject are: CASSANDRA-16048, which allows > to ignore these differences. The other one was trying to improve user > experience of anyone still using compact storage: CASSANDRA-15811. > Easily reproducible differernces are: > (1) hidden columns show up, which breaks SELECT * queries > (2) DELETE v and UPDATE v WITH TTL would result into row removals in > non-dense compact tables (CASSANDRA-16069) > (3) INSERT allows skipping clusterings, which are filled with nulls by > default. > Some of these are tricky to support, as 15811 has shown. Anyone on OSS side > who might want to upgrade to 4.0 while still using compact storage might be > affected by being forced into one of these behaviours. > Possible solutions are to document these behaviours, or to bring back a > minimal set of COMPACT STORAGE to keep supporting these. > It looks like it is possible to leave some of the functionality related to > DENSE flag and allow it to be present in 4.0, but only for these three (and > potential related, however not direrclty visible) cases. > [~e.dimitrova] since you were working on removal on compact storage, wanted > to reassure that this is not a revert of your patch. On contrary: your patch > was instrumental in identifying the right places. > cc [~slebresne] [~aleksey] [~benedict] [~marcuse] > |[patch|https://github.com/apache/cassandra/pull/785]|[ci|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=13994-followup]| -- 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-16217) Minimal 4.0 COMPACT STORAGE backport
[ https://issues.apache.org/jira/browse/CASSANDRA-16217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236366#comment-17236366 ] David Capwell commented on CASSANDRA-16217: --- There have been conversations about migrating from python to jvm dtest and the main point is we shouldn't delete python dtests. python dtests cover vnode case as well but jvm does not, so if we delete python dtests in favor of jvm dtest we actually loose coverage. I added a marker saying a test was ported to jvm-dtest, this will skip novnode case but still run in vnode case. > Minimal 4.0 COMPACT STORAGE backport > > > Key: CASSANDRA-16217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16217 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0-beta4 > > Time Spent: 20m > Remaining Estimate: 0h > > There are several behavioural changes related to compact storage, and these > differences are larger than most of us have anticipated: we first thought > there’ll be that “appearing column”, but there’s implicit nulls in > clusterings thing, and row vs column deletion. > Some of the recent issues on the subject are: CASSANDRA-16048, which allows > to ignore these differences. The other one was trying to improve user > experience of anyone still using compact storage: CASSANDRA-15811. > Easily reproducible differernces are: > (1) hidden columns show up, which breaks SELECT * queries > (2) DELETE v and UPDATE v WITH TTL would result into row removals in > non-dense compact tables (CASSANDRA-16069) > (3) INSERT allows skipping clusterings, which are filled with nulls by > default. > Some of these are tricky to support, as 15811 has shown. Anyone on OSS side > who might want to upgrade to 4.0 while still using compact storage might be > affected by being forced into one of these behaviours. > Possible solutions are to document these behaviours, or to bring back a > minimal set of COMPACT STORAGE to keep supporting these. > It looks like it is possible to leave some of the functionality related to > DENSE flag and allow it to be present in 4.0, but only for these three (and > potential related, however not direrclty visible) cases. > [~e.dimitrova] since you were working on removal on compact storage, wanted > to reassure that this is not a revert of your patch. On contrary: your patch > was instrumental in identifying the right places. > cc [~slebresne] [~aleksey] [~benedict] [~marcuse] > |[patch|https://github.com/apache/cassandra/pull/785]|[ci|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=13994-followup]| -- 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-16261) Prevent unbounded number of flushing tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-16261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236358#comment-17236358 ] Andres de la Peña commented on CASSANDRA-16261: --- [~e.dimitrova] If I'm understanding the [Downloads|https://cassandra.apache.org/download/] page, the rule about only really critical fixes only applies to 2.1, and indeed I don't think we should apply this fix to that branch. As for 2.2 and 3.0, they are supported until 4.0 is released, not until a few more months before. In the case of 3.0 there are 6 more months of support, which being a bit pessimistic about the release of 4.0 start is not a short time, IMO. The bug that we are solving here maybe isn't critical but it isn't a minor thing either, so I think we should apply the fix to all the supported versions. Also, I think that the patch is relatively easy to apply to those versions, but I might be wrong. > Prevent unbounded number of flushing tasks > -- > > Key: CASSANDRA-16261 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16261 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x, 4.0-beta4 > > > The cleaner thread is not prevented from queueing an unbounded number of > flushing tasks for memtables that are almost empty. -- 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-16225) Followup CASSANDRA-14554
[ https://issues.apache.org/jira/browse/CASSANDRA-16225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236359#comment-17236359 ] Jon Meredith commented on CASSANDRA-16225: -- +1 on the code. No deadlock issues with callers holding different locks that I could see. I've cherry-picked it and am going to run it through CI locally against trunk. > Followup CASSANDRA-14554 > > > Key: CASSANDRA-16225 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16225 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-beta, 4.0-beta4, 3.0.24, 3.11.10 > > > As per [~stefania]'s advice, additional synchronization should be added to > LogTransaction.java. Without synchronization, we could have corrupted txn log > files with JBOD. -- 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-16071) max_compaction_flush_memory_in_mb is interpreted as bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-16071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17232257#comment-17232257
]
Michael Semb Wever edited comment on CASSANDRA-16071 at 11/20/20, 5:58 PM:
---
I should have put this in NEWS.txt :-(
bq. A safe bet would be to interpret anything over 10 (100GB in MB, but
only 100K if bytes) as bytes…
This is smart. Though I'm uneasy with continuing to interpret the value in
bytes.
Here are patches for
[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_16701_2]
and
[trunk|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_16071_2]
that, if the value is over 100GB, log an error and revert value back to
default of 1GB. This won't be ideal in all situations, but I believe it means
users will correct the configuration and will be therefore safer in the longer
run. wdyt [~scott_carey], [~jasonstack]?
Rehashing the pain…
Clusters that had previously configured {{max_compaction_flush_memory_in_mb}}
as bytes, must take one of the upgrade actions,
Upgrading to 3.11.8 or 3.11.9, with the index unavailable:
- drop index
- rolling upgrade all nodes (disabling compactions upon restart)
- recreate index with correct {{max_compaction_flush_memory_in_mb}} mb value
Upgrading to 3.11.8 or 3.11.9, maintaining use of index:
- disable compactions on all nodes
- rolling upgrade all nodes (disabling compactions upon restart)
- create new index with correct {{max_compaction_flush_memory_in_mb}} mb value
- drop old index
- enable compactions on all nodes
With the patches proposed, upgrading to 3.11.10+:
- rolling upgrade all nodes
- drop and recreate index with correct {{max_compaction_flush_memory_in_mb}} mb
value
was (Author: michaelsembwever):
I should have put this in NEWS.txt :-(
bq. A safe bet would be to interpret anything over 10 (100GB in MB, but
only 100K if bytes) as bytes…
This is smart. Though I'm uneasy with continuing to interpret the value in
bytes.
Here are patches for
[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/cassandra-3.11_16701_2]
and
[trunk|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/trunk_16071_2]
that, if the value is over 100GB, log an error and revert value back to
default of 1GB. This won't be ideal in all situations, but I believe it means
users will correct the configuration and will be therefore safer in the longer
run. wdyt [~scott_carey], [~jasonstack]?
Rehashing the pain…
Clusters that had previously configured {{max_compaction_flush_memory_in_mb}}
as bytes, must take one of the upgrade actions,
Upgrading to 3.11.8 or 3.11.9, with the index unavailable:
- drop index
- rolling upgrade all nodes (disabling compactions upon restart)
- recreate index with correct {{max_compaction_flush_memory_in_mb}} mb value
Upgrading to 3.11.8 or 3.11.9, maintaining use of index:
- disable compactions on all nodes
- rolling upgrade all nodes (disabling compactions upon restart)
- drop and recreate index with correct {{max_compaction_flush_memory_in_mb}} mb
value
- enable compactions on all nodes
With the patches proposed, upgrading to 3.11.10+:
- rolling upgrade all nodes
- drop and recreate index with correct {{max_compaction_flush_memory_in_mb}} mb
value
> max_compaction_flush_memory_in_mb is interpreted as bytes
> -
>
> Key: CASSANDRA-16071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16071
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0, 3.11.8, 4.0-beta2, 4.0-beta4, 3.11.10
>
>
> In CASSANDRA-12662, [~scottcarey]
> [reported|https://issues.apache.org/jira/browse/CASSANDRA-12662?focusedCommentId=17070055=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17070055]
> that the {{max_compaction_flush_memory_in_mb}} setting gets incorrectly
> interpreted in bytes rather than megabytes as its name implies.
> {quote}
> 1. the setting 'max_compaction_flush_memory_in_mb' is a misnomer, it is
> actually memory in BYTES. If you take it at face value, and set it to say,
> '512' thinking that means 512MB, you will produce a million temp files
> rather quickly in a large compaction, which will exhaust even large values of
> max_map_count rapidly, and get the OOM: Map Error issue above and possibly
> have a very difficult situation to get a cluster back into a place where
> nodes aren't crashing while initilaizing or soon after. This issue is minor
> if you know about it in advance and set the value IN BYTES.
> {quote}
--
This message was sent by
[jira] [Updated] (CASSANDRA-16071) max_compaction_flush_memory_in_mb is interpreted as bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-16071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16071:
---
Complexity: Normal (was: Low Hanging Fruit)
> max_compaction_flush_memory_in_mb is interpreted as bytes
> -
>
> Key: CASSANDRA-16071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16071
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0, 3.11.8, 4.0-beta2, 4.0-beta4, 3.11.10
>
>
> In CASSANDRA-12662, [~scottcarey]
> [reported|https://issues.apache.org/jira/browse/CASSANDRA-12662?focusedCommentId=17070055=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17070055]
> that the {{max_compaction_flush_memory_in_mb}} setting gets incorrectly
> interpreted in bytes rather than megabytes as its name implies.
> {quote}
> 1. the setting 'max_compaction_flush_memory_in_mb' is a misnomer, it is
> actually memory in BYTES. If you take it at face value, and set it to say,
> '512' thinking that means 512MB, you will produce a million temp files
> rather quickly in a large compaction, which will exhaust even large values of
> max_map_count rapidly, and get the OOM: Map Error issue above and possibly
> have a very difficult situation to get a cluster back into a place where
> nodes aren't crashing while initilaizing or soon after. This issue is minor
> if you know about it in advance and set the value IN BYTES.
> {quote}
--
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-16225) Followup CASSANDRA-14554
[ https://issues.apache.org/jira/browse/CASSANDRA-16225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236337#comment-17236337 ] Ekaterina Dimitrova edited comment on CASSANDRA-16225 at 11/20/20, 5:53 PM: [~maedhroz] pointed that I missed the synchronization for LogTransaction#untrackNew() I corrected it for 3.0 [here|https://github.com/ekaterinadimitrova2/cassandra/commit/e5241dfa3c097d6078f95823272a1e1c73c2]. This could be merged to the rest of the branches. Not sure whether we need full CI run again [~maedhroz] and [~psy...@t-online.de], can you review, please? And thank you for reaching out, appreciate it! :) was (Author: e.dimitrova): [~maedhroz] pointed that I missed the synchronization for I corrected it for 3.0 [here|https://github.com/ekaterinadimitrova2/cassandra/commit/e5241dfa3c097d6078f95823272a1e1c73c2]. This could be merged to the rest of the branches. Not sure whether we need full CI run again [~maedhroz] and [~psy...@t-online.de], can you review, please? And thank you for reaching out, appreciate it! :) > Followup CASSANDRA-14554 > > > Key: CASSANDRA-16225 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16225 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-beta, 4.0-beta4, 3.0.24, 3.11.10 > > > As per [~stefania]'s advice, additional synchronization should be added to > LogTransaction.java. Without synchronization, we could have corrupted txn log > files with JBOD. -- 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-16225) Followup CASSANDRA-14554
[ https://issues.apache.org/jira/browse/CASSANDRA-16225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236337#comment-17236337 ] Ekaterina Dimitrova commented on CASSANDRA-16225: - [~maedhroz] pointed that I missed the synchronization for I corrected it for 3.0 [here|https://github.com/ekaterinadimitrova2/cassandra/commit/e5241dfa3c097d6078f95823272a1e1c73c2]. This could be merged to the rest of the branches. Not sure whether we need full CI run again [~maedhroz] and [~psy...@t-online.de], can you review, please? And thank you for reaching out, appreciate it! :) > Followup CASSANDRA-14554 > > > Key: CASSANDRA-16225 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16225 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-beta, 4.0-beta4, 3.0.24, 3.11.10 > > > As per [~stefania]'s advice, additional synchronization should be added to > LogTransaction.java. Without synchronization, we could have corrupted txn log > files with JBOD. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/02: Fix NEWS.txt entry
This is an automated email from the ASF dual-hosted git repository. ifesdjeen pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 79ea1e373614c21fd1aa294fb52d693767b91819 Author: Alex Petrov AuthorDate: Thu Nov 19 15:35:57 2020 +0100 Fix NEWS.txt entry Patch by Alex Petrov; reviewed by Ekaterina Dimitrova for CASSANDRA-16217 --- NEWS.txt | 4 1 file changed, 4 deletions(-) diff --git a/NEWS.txt b/NEWS.txt index 498fbbb..43ac816 100644 --- a/NEWS.txt +++ b/NEWS.txt @@ -149,10 +149,6 @@ Upgrading - Timestamp ties between values resolve differently: if either value has a TTL, this value always wins. This is to provide consistent reconciliation before and after the value expires into a tombstone. -- Cassandra 4.0 removed support for COMPACT STORAGE tables. All Compact Tables - have to be migrated using `ALTER ... DROP COMPACT STORAGE` statement in 3.0/3.11. - Cassandra starting 4.0 will not start if flags indicate that the table is non-CQL. - Syntax for creating compact tables is also deprecated. - Support for legacy auth tables in the system_auth keyspace (users, permissions, credentials) and the migration code has been removed. Migration of these legacy auth tables must have been completed before the upgrade to - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (732ac9a -> caeecf6)
This is an automated email from the ASF dual-hosted git repository. ifesdjeen pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 732ac9a Fix flaky NodeToolRingTest. new 79ea1e3 Fix NEWS.txt entry new caeecf6 Follow-up: remove test deprecated by CASSANDRA-16217 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: NEWS.txt | 4 - .../upgrade/CompactStorage3to4UpgradeTest.java | 160 + 2 files changed, 2 insertions(+), 162 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 02/02: Follow-up: remove test deprecated by CASSANDRA-16217
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit caeecf6456b87886a79f47a2954788e6c856697c
Author: Alex Petrov
AuthorDate: Fri Nov 20 16:14:30 2020 +0100
Follow-up: remove test deprecated by CASSANDRA-16217
Patch by Alex Petrov; reviewed by Marcus Eriksson and Caleb Rackliffe for
CASSANDRA-16217
---
.../upgrade/CompactStorage3to4UpgradeTest.java | 160 +
1 file changed, 2 insertions(+), 158 deletions(-)
diff --git
a/test/distributed/org/apache/cassandra/distributed/upgrade/CompactStorage3to4UpgradeTest.java
b/test/distributed/org/apache/cassandra/distributed/upgrade/CompactStorage3to4UpgradeTest.java
index bed1393..e94c2c4 100644
---
a/test/distributed/org/apache/cassandra/distributed/upgrade/CompactStorage3to4UpgradeTest.java
+++
b/test/distributed/org/apache/cassandra/distributed/upgrade/CompactStorage3to4UpgradeTest.java
@@ -18,123 +18,15 @@
package org.apache.cassandra.distributed.upgrade;
-import java.util.HashMap;
-import java.util.Map;
-import java.util.Set;
-
-import org.junit.Assert;
import org.junit.Test;
-import org.apache.cassandra.distributed.UpgradeableCluster;
-import org.apache.cassandra.distributed.api.ConsistencyLevel;
-import org.apache.cassandra.distributed.api.ICoordinator;
import org.apache.cassandra.distributed.shared.Versions;
-import org.apache.cassandra.exceptions.StartupException;
import static org.apache.cassandra.distributed.shared.AssertUtils.assertRows;
public class CompactStorage3to4UpgradeTest extends UpgradeTestBase
{
-
public static final String TABLE_NAME = "cs_tbl";
-public static final String CREATE_TABLE_C1_R1 = String.format(
- "CREATE TABLE %s.%s (key int, c1 int, v int, PRIMARY KEY (key, c1))
WITH COMPACT STORAGE",
- KEYSPACE, TABLE_NAME);
-public static final String CREATE_TABLE_C1_ONLY = String.format(
- "CREATE TABLE %s.%s (key int, c1 int, PRIMARY KEY (key, c1)) WITH
COMPACT STORAGE",
- KEYSPACE, TABLE_NAME);
-public static final String CREATE_TABLE_R_ONLY = String.format(
-"CREATE TABLE %s.%s (key int, c1 int, c2 int, PRIMARY KEY (key)) WITH
COMPACT STORAGE",
-KEYSPACE, TABLE_NAME);
-
-public static final String INSERT_C1_R1 = String.format(
- "INSERT INTO %s.%s (key, c1, v) VALUES (?, ?, ?)",
- KEYSPACE, TABLE_NAME);
-
-@Test
-public void ignoreDenseCompoundTablesWithValueColumn() throws Throwable
-{
-System.setProperty("cassandra.auto_drop_compact_storage", "true");
-final int partitions = 10;
-final int rowsPerPartition = 10;
-
-DropCompactTestHelper helper = new DropCompactTestHelper();
-new TestCase()
-.nodes(2)
-.upgrade(Versions.Major.v30, Versions.Major.v4)
-.setup(cluster -> {
-cluster.schemaChange(CREATE_TABLE_C1_R1);
-
-ICoordinator coordinator = cluster.coordinator(1);
-for (int i = 1; i <= partitions; i++)
-for (int j = 1; j <= rowsPerPartition; j++)
-coordinator.execute(INSERT_C1_R1, ConsistencyLevel.ALL, i,
j, i + j);
-
-
-runQueries(coordinator, helper, new String[]{
-String.format("SELECT * FROM %s.%s", KEYSPACE, TABLE_NAME),
-
-String.format("SELECT * FROM %s.%s WHERE key = %d and c1 = %d",
- KEYSPACE, TABLE_NAME, partitions - 3,
rowsPerPartition - 2),
-
-String.format("SELECT * FROM %s.%s WHERE key = %d and c1 = %d",
- KEYSPACE, TABLE_NAME, partitions - 1,
rowsPerPartition - 5),
-
-String.format("SELECT * FROM %s.%s WHERE key = %d and c1 > %d",
- KEYSPACE, TABLE_NAME, partitions - 8,
rowsPerPartition - 3),
-});
-})
-.runAfterNodeUpgrade((cluster, node) -> {
-validateResults(helper, cluster, 1);
-validateResults(helper, cluster, 2);
-
-String flagQuery = String.format("SELECT flags FROM
system_schema.tables WHERE keyspace_name='%s' and table_name='%s'", KEYSPACE,
TABLE_NAME);
-Object[][] results = cluster.get(node).executeInternal(flagQuery);
-if (results.length != 1)
-Assert.fail("failed to find table flags with query: " +
flagQuery);
-
-Set flags = (Set) results[0][0];
-Assert.assertTrue("missing compound flag",
flags.contains("compound"));
-Assert.assertFalse("found dense flag", flags.contains("dense"));
-})
-.run();
-}
-
-@Test
-public void failOnCompactClusteredTablesWithValueOutColumn() throws
Throwable
-{
-try
-{
-new TestCase()
-.nodes(2)
-.upgrade(Versions.Major.v30, Versions.Major.v4)
-.setup(cluster ->
[jira] [Updated] (CASSANDRA-16294) Potential NPE in JVMStabilityInspector
[ https://issues.apache.org/jira/browse/CASSANDRA-16294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16294: Test and Documentation Plan: Extended JVMStabilityInspectorTest Status: Patch Available (was: Open) ||branch||CI|| |[16294-3.0|https://github.com/beobal/cassandra/tree/16294-3.0]|[circle|https://circleci.com/gh/beobal/cassandra?branch=16294-3.0]| |[16294-3.11|https://github.com/beobal/cassandra/tree/16294-3.11]|[circle|https://circleci.com/gh/beobal/cassandra?branch=16294-3.11]| |[16294-trunk|https://github.com/beobal/cassandra/tree/16294-trunk]|[circle|https://circleci.com/gh/beobal/cassandra?branch=16294-trunk]| > Potential NPE in JVMStabilityInspector > -- > > Key: CASSANDRA-16294 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16294 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-beta > > > On either a FileNotFoundException or SocketException, JVMStabilityInspector > checks the error message for the string "Too many open files". However, both > of these exceptions have a constructor which sets a null message, which can > lead to NPE if handled. -- 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-16294) Potential NPE in JVMStabilityInspector
[ https://issues.apache.org/jira/browse/CASSANDRA-16294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16294: Bug Category: Parent values: Degradation(12984)Level 1 values: Other Exception(12998) Complexity: Low Hanging Fruit Discovered By: User Report Fix Version/s: 4.0-beta 3.11.x 3.0.x Severity: Low Status: Open (was: Triage Needed) > Potential NPE in JVMStabilityInspector > -- > > Key: CASSANDRA-16294 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16294 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Sam Tunnicliffe >Assignee: Sam Tunnicliffe >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-beta > > > On either a FileNotFoundException or SocketException, JVMStabilityInspector > checks the error message for the string "Too many open files". However, both > of these exceptions have a constructor which sets a null message, which can > lead to NPE if handled. -- 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-16294) Potential NPE in JVMStabilityInspector
Sam Tunnicliffe created CASSANDRA-16294: --- Summary: Potential NPE in JVMStabilityInspector Key: CASSANDRA-16294 URL: https://issues.apache.org/jira/browse/CASSANDRA-16294 Project: Cassandra Issue Type: Bug Components: Legacy/Core Reporter: Sam Tunnicliffe Assignee: Sam Tunnicliffe On either a FileNotFoundException or SocketException, JVMStabilityInspector checks the error message for the string "Too many open files". However, both of these exceptions have a constructor which sets a null message, which can lead to NPE if handled. -- 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-16191) Add tests for Repair metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-16191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yasar Arafath Baigh updated CASSANDRA-16191:
Reviewers: Adam Holmberg
Status: Review In Progress (was: Patch Available)
> Add tests for Repair metrics
>
>
> Key: CASSANDRA-16191
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16191
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Benjamin Lerer
>Assignee: Yasar Arafath Baigh
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: 0001-preview_failures_metric_test.patch
>
>
> We do not seems to have some tests for the {{RepairMetrics.previewFailures}}
> counter.
--
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-16191) Add tests for Repair metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-16191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236235#comment-17236235
]
Yasar Arafath Baigh edited comment on CASSANDRA-16191 at 11/20/20, 3:52 PM:
In preview_repair_test.py, test-case: test_preview is enhanced to perform
assertion {{RepairMetrics.previewFailures}} counter.
was (Author: yasar_baigh):
In preview_repair_test.py, test-case : test_preview is enhanced to perform
assertion {{RepairMetrics.previewFailures}} counter.
> Add tests for Repair metrics
>
>
> Key: CASSANDRA-16191
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16191
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Benjamin Lerer
>Assignee: Yasar Arafath Baigh
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: 0001-preview_failures_metric_test.patch
>
>
> We do not seems to have some tests for the {{RepairMetrics.previewFailures}}
> counter.
--
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-16185) Add tests to cover CommitLog metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-16185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yasar Arafath Baigh updated CASSANDRA-16185:
Status: Review In Progress (was: Patch Available)
> Add tests to cover CommitLog metrics
>
>
> Key: CASSANDRA-16185
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16185
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Yasar Arafath Baigh
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: 0001-Unit-Test-cases-for-CommitLogMetrics.patch
>
>
> The only metrics that seems to be covered by unit test for the CommitLog
> metrics is {{oversizedMutations}}. We should add testing the other ones.
--
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-16191) Add tests for Repair metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-16191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236235#comment-17236235
]
Yasar Arafath Baigh commented on CASSANDRA-16191:
-
In preview_repair_test.py, test-case : test_preview is enhanced to perform
assertion {{RepairMetrics.previewFailures}} counter.
> Add tests for Repair metrics
>
>
> Key: CASSANDRA-16191
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16191
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Benjamin Lerer
>Assignee: Yasar Arafath Baigh
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: 0001-preview_failures_metric_test.patch
>
>
> We do not seems to have some tests for the {{RepairMetrics.previewFailures}}
> counter.
--
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-16191) Add tests for Repair metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-16191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yasar Arafath Baigh updated CASSANDRA-16191:
Test and Documentation Plan:
In existing *preview_repair_test.py* , which 3 nodes are started.
After adding few records in node-3, its stopped, similarly few records
are added in node-1 & its stopped.
Later before performing sync operation, nodetool preview and validate operations
are performed. So this preview operation will tick the
RepairMetrics::previewFailures metric,
so its expected that RepairMetrics::previewFailures metric count is increased.
After performing sync operations in cluster, when same preview operation is
performed,
then RepairMetrics::previewFailures metric value should remain same.
Status: Patch Available (was: In Progress)
> Add tests for Repair metrics
>
>
> Key: CASSANDRA-16191
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16191
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Benjamin Lerer
>Assignee: Yasar Arafath Baigh
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: 0001-preview_failures_metric_test.patch
>
>
> We do not seems to have some tests for the {{RepairMetrics.previewFailures}}
> counter.
--
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-16191) Add tests for Repair metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-16191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yasar Arafath Baigh updated CASSANDRA-16191:
Attachment: 0001-preview_failures_metric_test.patch
> Add tests for Repair metrics
>
>
> Key: CASSANDRA-16191
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16191
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Benjamin Lerer
>Assignee: Yasar Arafath Baigh
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: 0001-preview_failures_metric_test.patch
>
>
> We do not seems to have some tests for the {{RepairMetrics.previewFailures}}
> counter.
--
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-16217) Minimal 4.0 COMPACT STORAGE backport
[ https://issues.apache.org/jira/browse/CASSANDRA-16217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236232#comment-17236232 ] Alex Petrov commented on CASSANDRA-16217: - [~e.dimitrova] since we have added upgrade dtests [here|https://github.com/apache/cassandra/commit/8ffec0f02cf73c3d3a8c01aa2d856647a5620a21#diff-80d21b6bed7c174f700bd5d003122180c67b6615a2bc9c64aa9077ad9dc7cd8aR31] as in-jvm dtests, I do not think it's necessary to update python tests. Patch to remove ones you have pointed out: https://github.com/ifesdjeen/cassandra-dtest/pull/new/CASSANDRA-16217-followup > Minimal 4.0 COMPACT STORAGE backport > > > Key: CASSANDRA-16217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16217 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0-beta4 > > Time Spent: 20m > Remaining Estimate: 0h > > There are several behavioural changes related to compact storage, and these > differences are larger than most of us have anticipated: we first thought > there’ll be that “appearing column”, but there’s implicit nulls in > clusterings thing, and row vs column deletion. > Some of the recent issues on the subject are: CASSANDRA-16048, which allows > to ignore these differences. The other one was trying to improve user > experience of anyone still using compact storage: CASSANDRA-15811. > Easily reproducible differernces are: > (1) hidden columns show up, which breaks SELECT * queries > (2) DELETE v and UPDATE v WITH TTL would result into row removals in > non-dense compact tables (CASSANDRA-16069) > (3) INSERT allows skipping clusterings, which are filled with nulls by > default. > Some of these are tricky to support, as 15811 has shown. Anyone on OSS side > who might want to upgrade to 4.0 while still using compact storage might be > affected by being forced into one of these behaviours. > Possible solutions are to document these behaviours, or to bring back a > minimal set of COMPACT STORAGE to keep supporting these. > It looks like it is possible to leave some of the functionality related to > DENSE flag and allow it to be present in 4.0, but only for these three (and > potential related, however not direrclty visible) cases. > [~e.dimitrova] since you were working on removal on compact storage, wanted > to reassure that this is not a revert of your patch. On contrary: your patch > was instrumental in identifying the right places. > cc [~slebresne] [~aleksey] [~benedict] [~marcuse] > |[patch|https://github.com/apache/cassandra/pull/785]|[ci|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=13994-followup]| -- 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-15897) Dropping compact storage with 2.1-sstables on disk make them unreadable
[ https://issues.apache.org/jira/browse/CASSANDRA-15897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17235512#comment-17235512 ] Alex Petrov edited comment on CASSANDRA-15897 at 11/20/20, 3:30 PM: [~e.dimitrova] will we need a fix in 4.0, since 2.0 sstables can't be read by 4.0? UPD: talked with [~e.dimitrova], and I was responding to a different question. I was speaking only about 2.0 upgrades, but am generally +1 to do the proposed "gossip" solution, assuming we're talking about mixed-mode 2.0/3.0 cluster or 3.0/4.0 cluster that can might contain 2.0 sstables. was (Author: ifesdjeen): [~e.dimitrova] will we need a fix in 4.0, since 2.0 sstables can't be read by 4.0? > Dropping compact storage with 2.1-sstables on disk make them unreadable > --- > > Key: CASSANDRA-15897 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15897 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Marcus Eriksson >Assignee: Sylvain Lebresne >Priority: Normal > Fix For: 3.0.x, 4.0-beta > > > Test reproducing: > https://github.com/krummas/cassandra/commits/marcuse/dropcompactstorage -- 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-16217) Minimal 4.0 COMPACT STORAGE backport
[
https://issues.apache.org/jira/browse/CASSANDRA-16217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236223#comment-17236223
]
Alex Petrov commented on CASSANDRA-16217:
-
[~maedhroz] of course, you're right. Brought back {{testNullClusteringValues}}.
Thank you for bringing this up. Could you take another look?
> Minimal 4.0 COMPACT STORAGE backport
>
>
> Key: CASSANDRA-16217
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16217
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
> Fix For: 4.0-beta4
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are several behavioural changes related to compact storage, and these
> differences are larger than most of us have anticipated: we first thought
> there’ll be that “appearing column”, but there’s implicit nulls in
> clusterings thing, and row vs column deletion.
> Some of the recent issues on the subject are: CASSANDRA-16048, which allows
> to ignore these differences. The other one was trying to improve user
> experience of anyone still using compact storage: CASSANDRA-15811.
> Easily reproducible differernces are:
> (1) hidden columns show up, which breaks SELECT * queries
> (2) DELETE v and UPDATE v WITH TTL would result into row removals in
> non-dense compact tables (CASSANDRA-16069)
> (3) INSERT allows skipping clusterings, which are filled with nulls by
> default.
> Some of these are tricky to support, as 15811 has shown. Anyone on OSS side
> who might want to upgrade to 4.0 while still using compact storage might be
> affected by being forced into one of these behaviours.
> Possible solutions are to document these behaviours, or to bring back a
> minimal set of COMPACT STORAGE to keep supporting these.
> It looks like it is possible to leave some of the functionality related to
> DENSE flag and allow it to be present in 4.0, but only for these three (and
> potential related, however not direrclty visible) cases.
> [~e.dimitrova] since you were working on removal on compact storage, wanted
> to reassure that this is not a revert of your patch. On contrary: your patch
> was instrumental in identifying the right places.
> cc [~slebresne] [~aleksey] [~benedict] [~marcuse]
> |[patch|https://github.com/apache/cassandra/pull/785]|[ci|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=13994-followup]|
--
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-16217) Minimal 4.0 COMPACT STORAGE backport
[ https://issues.apache.org/jira/browse/CASSANDRA-16217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236209#comment-17236209 ] Ekaterina Dimitrova commented on CASSANDRA-16217: - I just took a quick look at the dests as promised: [https://github.com/ekaterinadimitrova2/cassandra-dtest/blob/master/upgrade_tests/upgrade_compact_storage.py#L56] ---> this one should be reworked to actually test 4.0 with the compact storage [https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_compact_storage.py#L116] ---> this one maybe could be removed Also, this one - https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_compact_storage.py#L182 > Minimal 4.0 COMPACT STORAGE backport > > > Key: CASSANDRA-16217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16217 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0-beta4 > > Time Spent: 10m > Remaining Estimate: 0h > > There are several behavioural changes related to compact storage, and these > differences are larger than most of us have anticipated: we first thought > there’ll be that “appearing column”, but there’s implicit nulls in > clusterings thing, and row vs column deletion. > Some of the recent issues on the subject are: CASSANDRA-16048, which allows > to ignore these differences. The other one was trying to improve user > experience of anyone still using compact storage: CASSANDRA-15811. > Easily reproducible differernces are: > (1) hidden columns show up, which breaks SELECT * queries > (2) DELETE v and UPDATE v WITH TTL would result into row removals in > non-dense compact tables (CASSANDRA-16069) > (3) INSERT allows skipping clusterings, which are filled with nulls by > default. > Some of these are tricky to support, as 15811 has shown. Anyone on OSS side > who might want to upgrade to 4.0 while still using compact storage might be > affected by being forced into one of these behaviours. > Possible solutions are to document these behaviours, or to bring back a > minimal set of COMPACT STORAGE to keep supporting these. > It looks like it is possible to leave some of the functionality related to > DENSE flag and allow it to be present in 4.0, but only for these three (and > potential related, however not direrclty visible) cases. > [~e.dimitrova] since you were working on removal on compact storage, wanted > to reassure that this is not a revert of your patch. On contrary: your patch > was instrumental in identifying the right places. > cc [~slebresne] [~aleksey] [~benedict] [~marcuse] > |[patch|https://github.com/apache/cassandra/pull/785]|[ci|https://app.circleci.com/pipelines/github/ifesdjeen/cassandra?branch=13994-followup]| -- 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-16271) Writes timeout instead of failing on cluster with CL-1 replicas available during replace
[
https://issues.apache.org/jira/browse/CASSANDRA-16271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236206#comment-17236206
]
Sam Tunnicliffe commented on CASSANDRA-16271:
-
I've pushed patches for 3.0, 3.11 and trunk. The CI generally looks good, but
there are a few tests either failing or timing out. I've checked these all pass
locally, but I'll check on them a bit more and try to get a clean run. In the
meantime..
||branch||CI||
|[16271-3.0|https://github.com/beobal/cassandra/tree/16271-3.0]|[circle|https://circleci.com/gh/beobal/cassandra?branch=16271-3.0]|
|[16271-3.11|https://github.com/beobal/cassandra/tree/16271-3.11]|[circle|https://circleci.com/gh/beobal/cassandra?branch=16271-3.11]|
|[16271-trunk|https://github.com/beobal/cassandra/tree/16271-trunk]|[circle|https://circleci.com/gh/beobal/cassandra?branch=16271-trunk]|
> Writes timeout instead of failing on cluster with CL-1 replicas available
> during replace
>
>
> Key: CASSANDRA-16271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16271
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Krishna Vadali
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Attachments: sleep_before_replace.diff
>
>
> Writes timeout instead of failing on cluster with CL-1 replicas available
> during replace node operation.
> With Consistency Level ALL, we are observing Timeout exceptions during writes
> when (RF - 1) nodes are available in the cluster with one replace-node
> operation running. The coordinator is expecting RF + 1 responses, while there
> are only RF nodes (RF-1 nodes in UN and 1 node in UJ) are available in the
> cluster, hence timing out.
> The same problem happens on a keyspace with RF=1, CL=ONE and one replica
> being replaced. Also RF=3, CL=QUORUM, one replica down and another being
> replaced.
> I believe the expected behavior is that the write should fail with
> UnavailableException since there are not enough NORMAL replicas to fulfill
> the request.
> h4. *Steps to reproduce:*
> Run a 3 node test cluster (call the nodes node1 (127.0.0.1), node2
> (127.0.0.2), node3 (127.0.0.3)):
> {code:java}
> ccm create test -v 3.11.3 -n 3 -s
> {code}
> Create test keyspaces with RF = 3 and RF = 1 respectively:
> {code:java}
> create keyspace rf3 with replication = \{'class': 'SimpleStrategy',
> 'replication_factor': 3};
> create keyspace rf1 with replication = \{'class': 'SimpleStrategy',
> 'replication_factor': 1};
> {code}
> Create a table test in both the keyspaces:
> {code:java}
> create table rf3.test ( pk int primary KEY, value int);
> create table rf1.test ( pk int primary KEY, value int);
> {code}
> Stop node node2:
> {code:java}
> ccm node2 stop
> {code}
> Create node node4:
> {code:java}
> ccm add node4 -i 127.0.0.4
> {code}
> Enable auto_bootstrap
> {code:java}
> ccm node4 updateconf 'auto_bootstrap: true'
> {code}
> Ensure node4 does not have itself in its seeds list.
> Run a replace node to replace node2 (address 127.0.0.2 corresponds to node
> node2)
> {code:java}
> ccm node4 start --jvm_arg="-Dcassandra.replace_address=127.0.0.2"
> {code}
> When the replace node is running, perform write/reads with CONSISTENCY ALL,
> we observed TimeoutException.
> {code:java}
> SET CONSISTENCY ALL:SET CONSISTENCY ALL:
> cqlsh> insert into rf3.test (pk, value) values (16, 7);
> WriteTimeout: Error from server: code=1100 [Coordinator node timed out
> waiting for replica nodes' responses] message="Operation timed out - received
> only 3 responses." info=\{'received_responses': 3, 'required_responses': 4,
> 'consistency': 'ALL'}{code}
> {code:java}
> cqlsh> CONSISTENCY ONE;
> cqlsh> insert into rf1.test (pk, value) VALUES(5, 1);
> WriteTimeout: Error from server: code=1100 [Coordinator node timed out
> waiting for replica nodes' responses] message="Operation timed out - received
> only 1 responses." info=\{'received_responses': 1, 'required_responses': 2,
> 'consistency': 'ONE'}
> {code}
> Cluster State:
> {code:java}
> Datacenter: datacenter1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 127.0.0.1 70.45 KiB 1100.0%
> 4f652b22-045b-493b-8722-fb5f7e1723ce rack1
> UN 127.0.0.3 70.43 KiB 1100.0%
> a0dcd677-bdb3-4947-b9a7-14f3686a709f rack1
> UJ 127.0.0.4 137.47 KiB 1?
> e3d794f1-081e-4aba-94f2-31950c713846 rack1
> {code}
> Note:
> We introduced sleep during replace operation in order to simulate do our
> experiments. We attached code diff that does it.
--
This message was
[jira] [Updated] (CASSANDRA-16271) Writes timeout instead of failing on cluster with CL-1 replicas available during replace
[
https://issues.apache.org/jira/browse/CASSANDRA-16271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-16271:
Test and Documentation Plan: Added new unit tests. Run existing dtests.
Status: Patch Available (was: Open)
> Writes timeout instead of failing on cluster with CL-1 replicas available
> during replace
>
>
> Key: CASSANDRA-16271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16271
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Krishna Vadali
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Attachments: sleep_before_replace.diff
>
>
> Writes timeout instead of failing on cluster with CL-1 replicas available
> during replace node operation.
> With Consistency Level ALL, we are observing Timeout exceptions during writes
> when (RF - 1) nodes are available in the cluster with one replace-node
> operation running. The coordinator is expecting RF + 1 responses, while there
> are only RF nodes (RF-1 nodes in UN and 1 node in UJ) are available in the
> cluster, hence timing out.
> The same problem happens on a keyspace with RF=1, CL=ONE and one replica
> being replaced. Also RF=3, CL=QUORUM, one replica down and another being
> replaced.
> I believe the expected behavior is that the write should fail with
> UnavailableException since there are not enough NORMAL replicas to fulfill
> the request.
> h4. *Steps to reproduce:*
> Run a 3 node test cluster (call the nodes node1 (127.0.0.1), node2
> (127.0.0.2), node3 (127.0.0.3)):
> {code:java}
> ccm create test -v 3.11.3 -n 3 -s
> {code}
> Create test keyspaces with RF = 3 and RF = 1 respectively:
> {code:java}
> create keyspace rf3 with replication = \{'class': 'SimpleStrategy',
> 'replication_factor': 3};
> create keyspace rf1 with replication = \{'class': 'SimpleStrategy',
> 'replication_factor': 1};
> {code}
> Create a table test in both the keyspaces:
> {code:java}
> create table rf3.test ( pk int primary KEY, value int);
> create table rf1.test ( pk int primary KEY, value int);
> {code}
> Stop node node2:
> {code:java}
> ccm node2 stop
> {code}
> Create node node4:
> {code:java}
> ccm add node4 -i 127.0.0.4
> {code}
> Enable auto_bootstrap
> {code:java}
> ccm node4 updateconf 'auto_bootstrap: true'
> {code}
> Ensure node4 does not have itself in its seeds list.
> Run a replace node to replace node2 (address 127.0.0.2 corresponds to node
> node2)
> {code:java}
> ccm node4 start --jvm_arg="-Dcassandra.replace_address=127.0.0.2"
> {code}
> When the replace node is running, perform write/reads with CONSISTENCY ALL,
> we observed TimeoutException.
> {code:java}
> SET CONSISTENCY ALL:SET CONSISTENCY ALL:
> cqlsh> insert into rf3.test (pk, value) values (16, 7);
> WriteTimeout: Error from server: code=1100 [Coordinator node timed out
> waiting for replica nodes' responses] message="Operation timed out - received
> only 3 responses." info=\{'received_responses': 3, 'required_responses': 4,
> 'consistency': 'ALL'}{code}
> {code:java}
> cqlsh> CONSISTENCY ONE;
> cqlsh> insert into rf1.test (pk, value) VALUES(5, 1);
> WriteTimeout: Error from server: code=1100 [Coordinator node timed out
> waiting for replica nodes' responses] message="Operation timed out - received
> only 1 responses." info=\{'received_responses': 1, 'required_responses': 2,
> 'consistency': 'ONE'}
> {code}
> Cluster State:
> {code:java}
> Datacenter: datacenter1
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 127.0.0.1 70.45 KiB 1100.0%
> 4f652b22-045b-493b-8722-fb5f7e1723ce rack1
> UN 127.0.0.3 70.43 KiB 1100.0%
> a0dcd677-bdb3-4947-b9a7-14f3686a709f rack1
> UJ 127.0.0.4 137.47 KiB 1?
> e3d794f1-081e-4aba-94f2-31950c713846 rack1
> {code}
> Note:
> We introduced sleep during replace operation in order to simulate do our
> experiments. We attached code diff that does it.
--
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-16293) Flaky NodeToolRingTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16293: - Fix Version/s: (was: 4.0) 4.0-beta4 Since Version: 4.0-beta2 Source Control Link: https://github.com/apache/cassandra/commit/732ac9ae0c5e8c0868d207dbece5067d0bd4029d Resolution: Fixed Status: Resolved (was: Ready to Commit) Also no guarantee that hostname resolution works at all. Thanks, committed. > Flaky NodeToolRingTest > -- > > Key: CASSANDRA-16293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16293 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta4 > > Time Spent: 20m > Remaining Estimate: 0h > > NodeToolRingTest is > [failing|https://ci-cassandra.apache.org/job/Cassandra-trunk/162/testReport/junit/org.apache.cassandra.distributed.test/NodeToolRingTest/testRingResolve/history/] > every now and then. Depending on where it gets executed the host name > resolves to localhost or to localhost.localdomain -- 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-16293) Flaky NodeToolRingTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16293: - Status: Ready to Commit (was: Review In Progress) > Flaky NodeToolRingTest > -- > > Key: CASSANDRA-16293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16293 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0 > > Time Spent: 20m > Remaining Estimate: 0h > > NodeToolRingTest is > [failing|https://ci-cassandra.apache.org/job/Cassandra-trunk/162/testReport/junit/org.apache.cassandra.distributed.test/NodeToolRingTest/testRingResolve/history/] > every now and then. Depending on where it gets executed the host name > resolves to localhost or to localhost.localdomain -- 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-16293) Flaky NodeToolRingTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16293: - Reviewers: Brandon Williams, Brandon Williams (was: Brandon Williams) Brandon Williams, Brandon Williams Status: Review In Progress (was: Patch Available) > Flaky NodeToolRingTest > -- > > Key: CASSANDRA-16293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16293 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0 > > Time Spent: 20m > Remaining Estimate: 0h > > NodeToolRingTest is > [failing|https://ci-cassandra.apache.org/job/Cassandra-trunk/162/testReport/junit/org.apache.cassandra.distributed.test/NodeToolRingTest/testRingResolve/history/] > every now and then. Depending on where it gets executed the host name > resolves to localhost or to localhost.localdomain -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Fix flaky NodeToolRingTest.
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 732ac9a Fix flaky NodeToolRingTest.
732ac9a is described below
commit 732ac9ae0c5e8c0868d207dbece5067d0bd4029d
Author: Brandon Williams
AuthorDate: Fri Nov 20 07:48:32 2020 -0600
Fix flaky NodeToolRingTest.
Patch by Berenguer Blasi, reviwewed by brandonwilliams for
CASSANDRA-16293
---
.../org/apache/cassandra/distributed/test/NodeToolRingTest.java| 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/test/distributed/org/apache/cassandra/distributed/test/NodeToolRingTest.java
b/test/distributed/org/apache/cassandra/distributed/test/NodeToolRingTest.java
index 008dd6b..74f4275 100644
---
a/test/distributed/org/apache/cassandra/distributed/test/NodeToolRingTest.java
+++
b/test/distributed/org/apache/cassandra/distributed/test/NodeToolRingTest.java
@@ -147,7 +147,8 @@ public class NodeToolRingTest extends TestBaseImpl
Assertions.assertThat(tool.getStdout())
.contains("Datacenter: datacenter0")
.contains("AddressRackStatus State Load
OwnsToken")
- .contains("localhost rack0 Up Normal")
+ .contains("localhost")
+ .contains("rack0 Up Normal")
.contains("100.00% 9223372036854775807");
assertEquals(0, tool.getExitCode());
assertTrue(tool.getCleanedStderr().isEmpty());
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16293) Flaky NodeToolRingTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16293: Test and Documentation Plan: See PR Status: Patch Available (was: In Progress) > Flaky NodeToolRingTest > -- > > Key: CASSANDRA-16293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16293 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > NodeToolRingTest is > [failing|https://ci-cassandra.apache.org/job/Cassandra-trunk/162/testReport/junit/org.apache.cassandra.distributed.test/NodeToolRingTest/testRingResolve/history/] > every now and then. Depending on where it gets executed the host name > resolves to localhost or to localhost.localdomain -- 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-16293) Flaky NodeToolRingTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16293: Fix Version/s: 4.0 > Flaky NodeToolRingTest > -- > > Key: CASSANDRA-16293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16293 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0 > > Time Spent: 20m > Remaining Estimate: 0h > > NodeToolRingTest is > [failing|https://ci-cassandra.apache.org/job/Cassandra-trunk/162/testReport/junit/org.apache.cassandra.distributed.test/NodeToolRingTest/testRingResolve/history/] > every now and then. Depending on where it gets executed the host name > resolves to localhost or to localhost.localdomain -- 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-16293) Flaky NodeToolRingTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16293: Bug Category: Parent values: Correctness(12982) Complexity: Low Hanging Fruit Component/s: Test/unit Discovered By: Unit Test Severity: Low Assignee: Berenguer Blasi Status: Open (was: Triage Needed) > Flaky NodeToolRingTest > -- > > Key: CASSANDRA-16293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16293 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > > NodeToolRingTest is > [failing|https://ci-cassandra.apache.org/job/Cassandra-trunk/162/testReport/junit/org.apache.cassandra.distributed.test/NodeToolRingTest/testRingResolve/history/] > every now and then. Depending on where it gets executed the host name > resolves to localhost or to localhost.localdomain -- 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-16293) Flaky NodeToolRingTest
Berenguer Blasi created CASSANDRA-16293: --- Summary: Flaky NodeToolRingTest Key: CASSANDRA-16293 URL: https://issues.apache.org/jira/browse/CASSANDRA-16293 Project: Cassandra Issue Type: Bug Reporter: Berenguer Blasi NodeToolRingTest is [failing|https://ci-cassandra.apache.org/job/Cassandra-trunk/162/testReport/junit/org.apache.cassandra.distributed.test/NodeToolRingTest/testRingResolve/history/] every now and then. Depending on where it gets executed the host name resolves to localhost or to localhost.localdomain -- 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 ] Michael Semb Wever updated CASSANDRA-16161: --- Fix Version/s: (was: 3.11.x) 3.11.10 Source Control Link: https://github.com/apache/cassandra/commit/fc9a5a7c63c5d264c30e940ef88236d2da0f5959 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as [fc9a5a7c63c5d264c30e940ef88236d2da0f5959|https://github.com/apache/cassandra/commit/fc9a5a7c63c5d264c30e940ef88236d2da0f5959]. > 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: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.10 > > Attachments: 16161.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Validation Compactions are not rate limited which can cause Java GC pressure > and result in spikes in latency. > PR https://github.com/apache/cassandra/pull/814 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated: Rate limit validation compactions using compaction_throughput_mb_per_sec
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.11 by this push:
new fc9a5a7 Rate limit validation compactions using
compaction_throughput_mb_per_sec
fc9a5a7 is described below
commit fc9a5a7c63c5d264c30e940ef88236d2da0f5959
Author: Stefan Miklosovic
AuthorDate: Wed Nov 4 16:35:36 2020 +0100
Rate limit validation compactions using compaction_throughput_mb_per_sec
patch by Stefan Miklosovic; reviewed by Mick Semb Wever, Chris Lohfink for
CASSANDRA-16161
---
CHANGES.txt| 1 +
.../cassandra/db/compaction/CompactionManager.java | 12 ++
.../cassandra/repair/CompactionValidationTest.java | 158 +
3 files changed, 171 insertions(+)
diff --git a/CHANGES.txt b/CHANGES.txt
index e16f3e5..7e54961 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.11.10
+ * Rate limit validation compactions using compaction_throughput_mb_per_sec
(CASSANDRA-16161)
* SASI's `max_compaction_flush_memory_in_mb` settings over 100GB revert to
default of 1GB (CASSANDRA-16071)
Merged from 3.0:
* Improved check of num_tokens against the length of initial_token
(CASSANDRA-14477)
diff --git a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
index 56d2d29..4ad5ceb 100644
--- a/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
+++ b/src/java/org/apache/cassandra/db/compaction/CompactionManager.java
@@ -1429,11 +1429,18 @@ public class CompactionManager implements
CompactionManagerMBean
// Create Merkle trees suitable to hold estimated partitions for
the given ranges.
// We blindly assume that a partition is evenly distributed on all
sstables for now.
MerkleTrees tree = createMerkleTrees(sstables,
validator.desc.ranges, cfs);
+RateLimiter limiter = getRateLimiter();
long start = System.nanoTime();
try (AbstractCompactionStrategy.ScannerList scanners =
cfs.getCompactionStrategyManager().getScanners(sstables, validator.desc.ranges);
ValidationCompactionController controller = new
ValidationCompactionController(cfs, gcBefore);
CompactionIterator ci = new
ValidationCompactionIterator(scanners.scanners, controller, nowInSec, metrics))
{
+double compressionRatio = scanners.getCompressionRatio();
+if (compressionRatio == MetadataCollector.NO_COMPRESSION_RATIO)
+compressionRatio = 1.0;
+
+long lastBytesScanned = 0;
+
// validate the CF as we iterate over it
validator.prepare(cfs, tree);
while (ci.hasNext())
@@ -1444,6 +1451,11 @@ public class CompactionManager implements
CompactionManagerMBean
{
validator.add(partition);
}
+
+long bytesScanned = scanners.getTotalBytesScanned();
+compactionRateLimiterAcquire(limiter, bytesScanned,
lastBytesScanned, compressionRatio);
+lastBytesScanned = bytesScanned;
+
}
validator.complete();
}
diff --git
a/test/long/org/apache/cassandra/repair/CompactionValidationTest.java
b/test/long/org/apache/cassandra/repair/CompactionValidationTest.java
new file mode 100644
index 000..d5b7559
--- /dev/null
+++ b/test/long/org/apache/cassandra/repair/CompactionValidationTest.java
@@ -0,0 +1,158 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.cassandra.repair;
+
+import java.net.InetAddress;
+import java.util.Collections;
+import java.util.List;
+import java.util.UUID;
+import java.util.stream.Stream;
+
+import org.junit.After;
+import org.junit.Before;
+import org.junit.BeforeClass;
+import org.junit.Test;
+
+import org.apache.cassandra.SchemaLoader;
+import org.apache.cassandra.config.DatabaseDescriptor;
+import
[cassandra] branch trunk updated (0bb1c51 -> fa24ec0)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 0bb1c51 Update jctools from 1.2.1 to 3.1.0 new fc9a5a7 Rate limit validation compactions using compaction_throughput_mb_per_sec new fa24ec0 Merge branch 'cassandra-3.11' into trunk The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit fa24ec0f18238c41e0efed50aceece6248ec6e36 Merge: 0bb1c51 fc9a5a7 Author: Mick Semb Wever AuthorDate: Fri Nov 20 09:53:08 2020 +0100 Merge branch 'cassandra-3.11' into trunk - 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 ] Michael Semb Wever updated CASSANDRA-16161: --- Status: Ready to Commit (was: Review In Progress) > 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: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.x > > Attachments: 16161.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Validation Compactions are not rate limited which can cause Java GC pressure > and result in spikes in latency. > PR https://github.com/apache/cassandra/pull/814 -- 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 ] Michael Semb Wever updated CASSANDRA-16161: --- Test and Documentation Plan: Added long unit test. (was: Need to document new validation compaction throttle option.) > 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: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.x > > Attachments: 16161.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Validation Compactions are not rate limited which can cause Java GC pressure > and result in spikes in latency. > PR https://github.com/apache/cassandra/pull/814 -- 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-16255) Update jctools dependency
[
https://issues.apache.org/jira/browse/CASSANDRA-16255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17236000#comment-17236000
]
Berenguer Blasi commented on CASSANDRA-16255:
-
Thx!
> Update jctools dependency
> -
>
> Key: CASSANDRA-16255
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16255
> Project: Cassandra
> Issue Type: Task
> Components: Local/Other
>Reporter: Marcus Eriksson
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0, 4.0-beta4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CASSANDRA-15880 started using {{MpmcArrayQueue}} from jctools - before that
> we only used it in cassandra-stress, we should probably update the dependency
> as jctools-1.2.1 is more than 4 years old
--
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-16255) Update jctools dependency
[
https://issues.apache.org/jira/browse/CASSANDRA-16255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16255:
---
Fix Version/s: 4.0
> Update jctools dependency
> -
>
> Key: CASSANDRA-16255
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16255
> Project: Cassandra
> Issue Type: Task
> Components: Local/Other
>Reporter: Marcus Eriksson
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0, 4.0-beta4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CASSANDRA-15880 started using {{MpmcArrayQueue}} from jctools - before that
> we only used it in cassandra-stress, we should probably update the dependency
> as jctools-1.2.1 is more than 4 years old
--
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-16255) Update jctools dependency
[
https://issues.apache.org/jira/browse/CASSANDRA-16255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16255:
---
Source Control Link:
https://github.com/apache/cassandra/commit/0bb1c511624ebb725acbb21c9059393001c31c17
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[0bb1c511624ebb725acbb21c9059393001c31c17|https://github.com/apache/cassandra/commit/0bb1c511624ebb725acbb21c9059393001c31c17].
> Update jctools dependency
> -
>
> Key: CASSANDRA-16255
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16255
> Project: Cassandra
> Issue Type: Task
> Components: Local/Other
>Reporter: Marcus Eriksson
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CASSANDRA-15880 started using {{MpmcArrayQueue}} from jctools - before that
> we only used it in cassandra-stress, we should probably update the dependency
> as jctools-1.2.1 is more than 4 years old
--
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-16234) Update NetBeans project file for dependency changes since 11th Feb 2020
[ https://issues.apache.org/jira/browse/CASSANDRA-16234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16234: --- Fix Version/s: 4.0-beta4 4.0 Since Version: 4.0-alpha3 Source Control Link: https://github.com/apache/cassandra/commit/1b139bc66ca39baa81571538633f503648ff6f5c Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as [1b139bc66ca39baa81571538633f503648ff6f5c|https://github.com/apache/cassandra/commit/1b139bc66ca39baa81571538633f503648ff6f5c]. > Update NetBeans project file for dependency changes since 11th Feb 2020 > --- > > Key: CASSANDRA-16234 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16234 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.0, 4.0-beta4 > > > A number of dependencies have been add/removed/updated to the project. > The netbeans project file needs an update to be in-sync. > Causing tickets: > - CASSANDRA-15677 > - CASSANDRA-16064 > - CASSANDRA-12995 > - CASSANDRA-15867 > - CASSANDRA-12197 > - CASSANDRA-15556 > - CASSANDRA-15868 > - CASSANDRA-16150 > - CASSANDRA-15631 > - CASSANDRA-15851 > - CASSANDRA-16148 > - CASSANDRA-14655 > - CASSANDRA-15867 > - CASSANDRA-15388 > - CASSANDRA-15564 > - CASSANDRA-16127 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/02: Update NetBeans project file for dependency changes since 11th Feb 2020
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 1b139bc66ca39baa81571538633f503648ff6f5c
Author: Mick Semb Wever
AuthorDate: Thu Oct 29 13:01:24 2020 +0100
Update NetBeans project file for dependency changes since 11th Feb 2020
patch by Mick Semb Wever; patch by Berenguer Blasi for CASSANDRA-16234
---
ide/nbproject/project.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ide/nbproject/project.xml b/ide/nbproject/project.xml
index 6b8a31e..505a547 100644
--- a/ide/nbproject/project.xml
+++ b/ide/nbproject/project.xml
@@ -7,7 +7,7 @@
..
-${project.dir}/lib/HdrHistogram-2.1.9.jar:${project.dir}/lib/ST4-4.0.8.jar:${project.dir}/lib/airline-0.8.jar:${project.dir}/lib/antlr-runtime-3.5.2.jar:${project.dir}/lib/asm-7.1.jar:${project.dir}/lib/caffeine-2.3.5.jar:${project.dir}/lib/cassandra-driver-core-3.6.0-shaded.jar:${project.dir}/lib/chronicle-bytes-1.16.3.jar:${project.dir}/lib/chronicle-core-1.16.4.jar:${project.dir}/lib/chronicle-queue-4.16.3.jar:${project.dir}/li
[...]
+${project.dir}/lib/HdrHistogram-2.1.9.jar:${project.dir}/lib/ST4-4.0.8.jar:${project.dir}/lib/airline-0.8.jar:${project.dir}/lib/antlr-runtime-3.5.2.jar:${project.dir}/lib/asm-7.1.jar:${project.dir}/lib/caffeine-2.3.5.jar:${project.dir}/lib/cassandra-driver-core-3.9.0-shaded.jar:${project.dir}/lib/chronicle-bytes-1.16.3.jar:${project.dir}/lib/chronicle-core-1.16.4.jar:${project.dir}/lib/chronicle-queue-4.16.3.jar:${project.dir}/li
[...]
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 02/02: Update jctools from 1.2.1 to 3.1.0
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 0bb1c511624ebb725acbb21c9059393001c31c17
Author: Bereng
AuthorDate: Mon Nov 16 09:43:46 2020 +0100
Update jctools from 1.2.1 to 3.1.0
patch by Berenguer Blasi; reviewed by Mick Semb Wever for CASSANDRA-16255
---
CHANGES.txt| 1 +
build.xml | 2 +-
ide/nbproject/project.xml | 2 +-
lib/jctools-core-1.2.1.jar | Bin 106714 -> 0 bytes
lib/jctools-core-3.1.0.jar | Bin 0 -> 323697 bytes
.../{jctools-core-1.2.1.txt => jctools-core-3.1.0.txt} | 9 +
6 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index beb878a..44c9787 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-beta4
+ * Update jctools dependency to 3.1.0 (CASSANDRA-16255)
* 'SSLEngine closed already' exception on failed outbound connection
(CASSANDRA-16277)
* Drain and/or shutdown might throw because of slow messaging service
shutdown (CASSANDRA-16276)
* Upgrade JNA to 5.6.0, dropping support for <=glibc-2.6 systems
(CASSANDRA-16212)
diff --git a/build.xml b/build.xml
index 55c043f..7b17409 100644
--- a/build.xml
+++ b/build.xml
@@ -665,7 +665,7 @@
-
+
diff --git a/ide/nbproject/project.xml b/ide/nbproject/project.xml
index 505a547..23427ee 100644
--- a/ide/nbproject/project.xml
+++ b/ide/nbproject/project.xml
@@ -7,7 +7,7 @@
..
-${project.dir}/lib/HdrHistogram-2.1.9.jar:${project.dir}/lib/ST4-4.0.8.jar:${project.dir}/lib/airline-0.8.jar:${project.dir}/lib/antlr-runtime-3.5.2.jar:${project.dir}/lib/asm-7.1.jar:${project.dir}/lib/caffeine-2.3.5.jar:${project.dir}/lib/cassandra-driver-core-3.9.0-shaded.jar:${project.dir}/lib/chronicle-bytes-1.16.3.jar:${project.dir}/lib/chronicle-core-1.16.4.jar:${project.dir}/lib/chronicle-queue-4.16.3.jar:${project.dir}/li
[...]
+${project.dir}/lib/HdrHistogram-2.1.9.jar:${project.dir}/lib/ST4-4.0.8.jar:${project.dir}/lib/airline-0.8.jar:${project.dir}/lib/antlr-runtime-3.5.2.jar:${project.dir}/lib/asm-7.1.jar:${project.dir}/lib/caffeine-2.3.5.jar:${project.dir}/lib/cassandra-driver-core-3.9.0-shaded.jar:${project.dir}/lib/chronicle-bytes-1.16.3.jar:${project.dir}/lib/chronicle-core-1.16.4.jar:${project.dir}/lib/chronicle-queue-4.16.3.jar:${project.dir}/li
[...]
diff --git a/lib/jctools-core-1.2.1.jar b/lib/jctools-core-1.2.1.jar
deleted file mode 100644
index fa1137b..000
Binary files a/lib/jctools-core-1.2.1.jar and /dev/null differ
diff --git a/lib/jctools-core-3.1.0.jar b/lib/jctools-core-3.1.0.jar
new file mode 100644
index 000..eb64344
Binary files /dev/null and b/lib/jctools-core-3.1.0.jar differ
diff --git a/lib/licenses/jctools-core-1.2.1.txt
b/lib/licenses/jctools-core-3.1.0.txt
similarity index 99%
rename from lib/licenses/jctools-core-1.2.1.txt
rename to lib/licenses/jctools-core-3.1.0.txt
index d645695..984f944 100644
--- a/lib/licenses/jctools-core-1.2.1.txt
+++ b/lib/licenses/jctools-core-3.1.0.txt
@@ -1,5 +1,4 @@
-
- Apache License
+Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
@@ -179,7 +178,7 @@
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
- boilerplate notice, with the fields enclosed by brackets "[]"
+ boilerplate notice, with the fields enclosed by brackets "{}"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
@@ -187,7 +186,7 @@
same "printed page" as the copyright notice for easier
identification within third-party archives.
- Copyright [] [name of copyright owner]
+ Copyright {} {name of copyright owner}
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
@@ -200,3 +199,5 @@
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
+
+
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (2a135ca -> 0bb1c51)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a change to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git.
from 2a135ca Include test jars in dtest uber jar
new 1b139bc Update NetBeans project file for dependency changes since
11th Feb 2020
new 0bb1c51 Update jctools from 1.2.1 to 3.1.0
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
CHANGES.txt| 1 +
build.xml | 2 +-
ide/nbproject/project.xml | 2 +-
lib/jctools-core-1.2.1.jar | Bin 106714 -> 0 bytes
lib/jctools-core-3.1.0.jar | Bin 0 -> 323697 bytes
lib/licenses/jctools-core-1.2.1.txt| 202 -
.../{geom-0.1.0.txt => jctools-core-3.1.0.txt} | 2 +
7 files changed, 5 insertions(+), 204 deletions(-)
delete mode 100644 lib/jctools-core-1.2.1.jar
create mode 100644 lib/jctools-core-3.1.0.jar
delete mode 100644 lib/licenses/jctools-core-1.2.1.txt
copy lib/licenses/{geom-0.1.0.txt => jctools-core-3.1.0.txt} (99%)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
