[jira] [Updated] (CASSANDRA-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16855: Reviewers: Brandon Williams, Ekaterina Dimitrova (was: Brandon Williams) > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400692#comment-17400692 ] Ekaterina Dimitrova commented on CASSANDRA-16855: - As we agreed in Slack, Jenkins dev CI run submitted [here|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1037/] > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400689#comment-17400689 ] Tatu Saloranta edited comment on CASSANDRA-16855 at 8/18/21, 12:51 AM: --- [~brandon.williams] fixed the remaining usage (and noticed that I had to do `ant realclean` before seeing compilation issue locally). -Will try to restart circle-ci job but not sure if I have access: I can see it fine fwtw.- (note: just realized that this is not a shared circle-ci set up) was (Author: cowtowncoder): [~brandon.williams] fixed the remaining usage (and noticed that I had to do `ant realclean` before seeing compilation issue locally). Will try to restart circle-ci job but not sure if I have access: I can see it fine fwtw. > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-13720) Clean up repair code
[ https://issues.apache.org/jira/browse/CASSANDRA-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400690#comment-17400690 ] Ekaterina Dimitrova commented on CASSANDRA-13720: - Committed to trunk, thank you! To https://github.com/apache/cassandra.git 5b325b8c51..fd3eb4fd9e trunk -> trunk > Clean up repair code > > > Key: CASSANDRA-13720 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13720 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Simon Zhou >Assignee: Simon Zhou >Priority: Normal > Fix For: 4.x > > > Lots of unused code. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13720) Clean up repair code
[ https://issues.apache.org/jira/browse/CASSANDRA-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-13720: Source Control Link: https://github.com/apache/cassandra/commit/fd3eb4fd9e930503c7149db5e90644857eb6e4d3 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Clean up repair code > > > Key: CASSANDRA-13720 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13720 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Simon Zhou >Assignee: Simon Zhou >Priority: Normal > Fix For: 4.x > > > Lots of unused code. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Clean up repair code patch by Simon Zhou; reviewed by Ekaterina Dimitrova and Andrés de la Peña for CASSANDRA-13720
This is an automated email from the ASF dual-hosted git repository.
edimitrova 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 fd3eb4f Clean up repair code patch by Simon Zhou; reviewed by
Ekaterina Dimitrova and Andrés de la Peña for CASSANDRA-13720
fd3eb4f is described below
commit fd3eb4fd9e930503c7149db5e90644857eb6e4d3
Author: Simon Zhou
AuthorDate: Sun Aug 1 12:10:37 2021 -0700
Clean up repair code
patch by Simon Zhou; reviewed by Ekaterina Dimitrova and Andrés de la Peña
for CASSANDRA-13720
---
CHANGES.txt| 1 +
.../org/apache/cassandra/repair/RepairRunnable.java| 18 --
2 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index fd5c3ff..e813ab2 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * Clean up repair code (CASSANDRA-13720)
* Background schedule to clean up orphaned hints files (CASSANDRA-16815)
* Modify SecondaryIndexManager#indexPartition() to retrieve only columns for
which indexes are actually being built (CASSANDRA-16776)
* Batch the token metadata update to improve the speed (CASSANDRA-15291)
diff --git a/src/java/org/apache/cassandra/repair/RepairRunnable.java
b/src/java/org/apache/cassandra/repair/RepairRunnable.java
index 798ba5e..4f76a8d 100644
--- a/src/java/org/apache/cassandra/repair/RepairRunnable.java
+++ b/src/java/org/apache/cassandra/repair/RepairRunnable.java
@@ -309,7 +309,7 @@ public class RepairRunnable implements Runnable,
ProgressEventNotifier
traceState.enableActivityNotification(tag);
for (ProgressListener listener : listeners)
traceState.addProgressListener(listener);
-Thread queryThread = createQueryThread(cmd, sessionId);
+Thread queryThread = createQueryThread(sessionId);
queryThread.setName("RepairTracePolling");
queryThread.start();
return traceState;
@@ -412,7 +412,6 @@ public class RepairRunnable implements Runnable,
ProgressEventNotifier
if (options.isPreview())
{
previewRepair(parentSession,
- creationTimeMillis,
neighborsAndRanges.filterCommonRanges(keyspace,
cfnames),
neighborsAndRanges.participants,
cfnames);
@@ -420,7 +419,6 @@ public class RepairRunnable implements Runnable,
ProgressEventNotifier
else if (options.isIncremental())
{
incrementalRepair(parentSession,
- creationTimeMillis,
traceState,
neighborsAndRanges,
neighborsAndRanges.participants,
@@ -429,7 +427,6 @@ public class RepairRunnable implements Runnable,
ProgressEventNotifier
else
{
normalRepair(parentSession,
- creationTimeMillis,
traceState,
neighborsAndRanges.filterCommonRanges(keyspace,
cfnames),
neighborsAndRanges.participants,
@@ -439,7 +436,6 @@ public class RepairRunnable implements Runnable,
ProgressEventNotifier
@SuppressWarnings("UnstableApiUsage")
private void normalRepair(UUID parentSession,
- long startTime,
TraceState traceState,
List commonRanges,
Set preparedEndpoints,
@@ -485,7 +481,6 @@ public class RepairRunnable implements Runnable,
ProgressEventNotifier
new RepairCompleteCallback(parentSession,
successfulRanges,
preparedEndpoints,
- startTime,
traceState,
hasFailure,
executor),
@@ -493,7 +488,6 @@ public class RepairRunnable implements Runnable,
ProgressEventNotifier
}
private void incrementalRepair(UUID parentSession,
- long startTime,
TraceState traceState,
NeighborsAndRanges neighborsAndRanges,
Set preparedEndpoints,
@@ -528,12 +522,11 @@ public class RepairRunnable implements Runnable,
ProgressEventNotifier
ranges.addAll(range);
}
Futures.addCallback(repairResult,
-new RepairCompleteCallback(parentSession, ranges,
preparedEndpoints, startTime, traceState, hasFailure, executor),
+
[jira] [Commented] (CASSANDRA-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400689#comment-17400689 ] Tatu Saloranta commented on CASSANDRA-16855: [~brandon.williams] fixed the remaining usage (and noticed that I had to do `ant realclean` before seeing compilation issue locally). Will try to restart circle-ci job but not sure if I have access: I can see it fine fwtw. > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16862) Fix flaky test DatabaseDescriptorRefTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400682#comment-17400682
]
Brandon Williams commented on CASSANDRA-16862:
--
I never run from the IDE. :) I guess I should have clarified that before.
> Fix flaky test DatabaseDescriptorRefTest
>
>
> Key: CASSANDRA-16862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16862
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> While working on another ticket I found out that DatabaseDescriptorRefTest is
> failing consistently locally for me and one more community member on 3.11,
> 4.0 and trunk.
> {code:java}
> java.lang.AssertionError: thread started in clientInitialization
> Expected :5
> Actual :8
>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16862) Fix flaky test DatabaseDescriptorRefTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400681#comment-17400681
]
Ekaterina Dimitrova edited comment on CASSANDRA-16862 at 8/18/21, 12:28 AM:
Yes, that works actually. I am surprised because I am 100% sure that some time
ago I was working on that class and everything was passing(in the IDE). Also,
it was failing for two of us but not for [~brandon.williams].
[~brandonwilliams], did you actually run it from IDE or the command line?
Do you know what is the reason so I can add a comment in the test for example?
For others so they don't troubleshoot and raise tickets :D And thank you for
the quick response, appreciate it :)
was (Author: e.dimitrova):
Yes, that works actually. I am surprised because I am 100% sure that some time
ago I was working on that class and everything was passing. Also, it was
failing for two of us but not for [~brandon.williams]. [~brandonwilliams], did
you actually run it from IDE or the command line?
Do you know what is the reason so I can add a comment in the test for example?
For others so they don't troubleshoot and raise tickets :D And thank you for
the quick response, appreciate it :)
> Fix flaky test DatabaseDescriptorRefTest
>
>
> Key: CASSANDRA-16862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16862
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> While working on another ticket I found out that DatabaseDescriptorRefTest is
> failing consistently locally for me and one more community member on 3.11,
> 4.0 and trunk.
> {code:java}
> java.lang.AssertionError: thread started in clientInitialization
> Expected :5
> Actual :8
>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16862) Fix flaky test DatabaseDescriptorRefTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400681#comment-17400681
]
Ekaterina Dimitrova commented on CASSANDRA-16862:
-
Yes, that works actually. I am surprised because I am 100% sure that some time
ago I was working on that class and everything was passing. Also, it was
failing for two of us but not for [~brandon.williams]. [~brandonwilliams], did
you actually run it from IDE or the command line?
Do you know what is the reason so I can add a comment in the test for example?
For others so they don't troubleshoot and raise tickets :D And thank you for
the quick response, appreciate it :)
> Fix flaky test DatabaseDescriptorRefTest
>
>
> Key: CASSANDRA-16862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16862
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> While working on another ticket I found out that DatabaseDescriptorRefTest is
> failing consistently locally for me and one more community member on 3.11,
> 4.0 and trunk.
> {code:java}
> java.lang.AssertionError: thread started in clientInitialization
> Expected :5
> Actual :8
>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400679#comment-17400679 ] Tatu Saloranta commented on CASSANDRA-16855: Oh. Somehow missed your comment [~brandon.williams] – will check, thanks! > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tatu Saloranta updated CASSANDRA-16855: --- Status: Patch Available (was: In Progress) > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16862) Fix flaky test DatabaseDescriptorRefTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400657#comment-17400657
]
Jon Meredith commented on CASSANDRA-16862:
--
It might behave differently when run inside an IDE rather than with {{ant}}. I
think I've hit that before. Does this pass for you?
{noformat}
ant testclasslist -Dtest.classlistprefix=unit -Dtest.classlistfile=<(echo
org/apache/cassandra/config/DatabaseDescriptorRefTest.java)
{noformat}
> Fix flaky test DatabaseDescriptorRefTest
>
>
> Key: CASSANDRA-16862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16862
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> While working on another ticket I found out that DatabaseDescriptorRefTest is
> failing consistently locally for me and one more community member on 3.11,
> 4.0 and trunk.
> {code:java}
> java.lang.AssertionError: thread started in clientInitialization
> Expected :5
> Actual :8
>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16862) Fix flaky test DatabaseDescriptorRefTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16862:
Fix Version/s: 4.x
4.0.x
3.11.x
> Fix flaky test DatabaseDescriptorRefTest
>
>
> Key: CASSANDRA-16862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16862
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> While working on another ticket I found out that DatabaseDescriptorRefTest is
> failing consistently locally for me and one more community member on 3.11,
> 4.0 and trunk.
> {code:java}
> java.lang.AssertionError: thread started in clientInitialization
> Expected :5
> Actual :8
>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16862) Fix flaky test DatabaseDescriptorRefTest
Ekaterina Dimitrova created CASSANDRA-16862:
---
Summary: Fix flaky test DatabaseDescriptorRefTest
Key: CASSANDRA-16862
URL: https://issues.apache.org/jira/browse/CASSANDRA-16862
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
While working on another ticket I found out that DatabaseDescriptorRefTest is
failing consistently locally for me and one more community member on 3.11, 4.0
and trunk.
{code:java}
java.lang.AssertionError: thread started in clientInitialization
Expected :5
Actual :8
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at
org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:285)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
at
com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
at
com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16862) Fix flaky test DatabaseDescriptorRefTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16862:
Bug Category: Parent values: Degradation(12984)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Severity: Low
Status: Open (was: Triage Needed)
> Fix flaky test DatabaseDescriptorRefTest
>
>
> Key: CASSANDRA-16862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16862
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> While working on another ticket I found out that DatabaseDescriptorRefTest is
> failing consistently locally for me and one more community member on 3.11,
> 4.0 and trunk.
> {code:java}
> java.lang.AssertionError: thread started in clientInitialization
> Expected :5
> Actual :8
>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16861) Fix flaky test test_compression_cql_options
[
https://issues.apache.org/jira/browse/CASSANDRA-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400637#comment-17400637
]
Ekaterina Dimitrova commented on CASSANDRA-16861:
-
I saw it in trunk, but I guess it might be a good idea to check also the other
branches when working on a fix.
> Fix flaky test test_compression_cql_options
> ---
>
> Key: CASSANDRA-16861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16861
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> While working on another ticket, I saw test_compression_cql_options failing
> (which is not the case in Jenkins) but the Circle CI multiplexer showed it as
> being flaky:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1082/workflows/8dacef5d-46f4-4b59-a8f7-08824bf1180f/jobs/6407/tests#failed-test-0]
> {code:java}
> sstables = self.get_sstables(table='compression_opts_table',
> indexes=list())
> sstable_paths = self.get_table_paths('compression_opts_table')
> found = False
> for sstable_path in sstable_paths:
> sstable = os.path.join(sstable_path,
> sstables['compression_opts_table'][1])
> if os.path.exists(sstable):
> assert 'DEFLATE' == self._get_compression_type(sstable)
> found = True
> > assert found
> E assert False
> compression_test.py:118: AssertionError
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.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-16861) Fix flaky test test_compression_cql_options
[
https://issues.apache.org/jira/browse/CASSANDRA-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16861:
Fix Version/s: 4.x
> Fix flaky test test_compression_cql_options
> ---
>
> Key: CASSANDRA-16861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16861
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> While working on another ticket, I saw test_compression_cql_options failing
> (which is not the case in Jenkins) but the Circle CI multiplexer showed it as
> being flaky:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1082/workflows/8dacef5d-46f4-4b59-a8f7-08824bf1180f/jobs/6407/tests#failed-test-0]
> {code:java}
> sstables = self.get_sstables(table='compression_opts_table',
> indexes=list())
> sstable_paths = self.get_table_paths('compression_opts_table')
> found = False
> for sstable_path in sstable_paths:
> sstable = os.path.join(sstable_path,
> sstables['compression_opts_table'][1])
> if os.path.exists(sstable):
> assert 'DEFLATE' == self._get_compression_type(sstable)
> found = True
> > assert found
> E assert False
> compression_test.py:118: AssertionError
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.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-16861) Fix flaky test test_compression_cql_options
[
https://issues.apache.org/jira/browse/CASSANDRA-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16861:
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Component/s: CI
Discovered By: User Report
Severity: Low
Status: Open (was: Triage Needed)
> Fix flaky test test_compression_cql_options
> ---
>
> Key: CASSANDRA-16861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16861
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> While working on another ticket, I saw test_compression_cql_options failing
> (which is not the case in Jenkins) but the Circle CI multiplexer showed it as
> being flaky:
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1082/workflows/8dacef5d-46f4-4b59-a8f7-08824bf1180f/jobs/6407/tests#failed-test-0]
> {code:java}
> sstables = self.get_sstables(table='compression_opts_table',
> indexes=list())
> sstable_paths = self.get_table_paths('compression_opts_table')
> found = False
> for sstable_path in sstable_paths:
> sstable = os.path.join(sstable_path,
> sstables['compression_opts_table'][1])
> if os.path.exists(sstable):
> assert 'DEFLATE' == self._get_compression_type(sstable)
> found = True
> > assert found
> E assert False
> compression_test.py:118: AssertionError
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.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-16861) Fix flaky test test_compression_cql_options
Ekaterina Dimitrova created CASSANDRA-16861:
---
Summary: Fix flaky test test_compression_cql_options
Key: CASSANDRA-16861
URL: https://issues.apache.org/jira/browse/CASSANDRA-16861
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
While working on another ticket, I saw test_compression_cql_options failing
(which is not the case in Jenkins) but the Circle CI multiplexer showed it as
being flaky:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1082/workflows/8dacef5d-46f4-4b59-a8f7-08824bf1180f/jobs/6407/tests#failed-test-0]
{code:java}
sstables = self.get_sstables(table='compression_opts_table',
indexes=list())
sstable_paths = self.get_table_paths('compression_opts_table')
found = False
for sstable_path in sstable_paths:
sstable = os.path.join(sstable_path,
sstables['compression_opts_table'][1])
if os.path.exists(sstable):
assert 'DEFLATE' == self._get_compression_type(sstable)
found = True
> assert found
E assert False
compression_test.py:118: AssertionError
{code}
--
This message was sent by Atlassian Jira
(v8.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-16404) Provide a nodetool way of invalidating auth caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400607#comment-17400607
]
Aleksei Zotov commented on CASSANDRA-16404:
---
[~samt]
Great, thanks for taking care of that! I see 4 failures, but they do not seem
to be related to these changes.
I checked your branch for dtest repo and can see the change for handling
NetworkPermissionsCache/NetworkAuthCache MBeans. Am I right that currently
there are no dtests for JMXPermissionsCache/JmxPermissionsCache MBeans? Shall I
try to come up with a test for that (basically I'd like to get familiar with
dtests)? Can I use this ticket or need to create another one?
===
Also I think there is a small issue with the last change:
{code:java}
public static final String CACHE_NAME = "JMXPermissionsCache";
@Deprecated
public static final String DEPRECATED_CACHE_NAME = "JmxPermissionsCache";
{code}
it should be opposite:
{code:java}
public static final String CACHE_NAME = "JmxPermissionsCache";
@Deprecated
public static final String DEPRECATED_CACHE_NAME = "JMXPermissionsCache";
{code}
JMXPermissionsCache is what we have currently
([https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/auth/jmx/AuthorizationProxy.java#L483]).
It needs to be renamed to match the class name.
> Provide a nodetool way of invalidating auth caches
> --
>
> Key: CASSANDRA-16404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16404
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization
>Reporter: Sumanth Pasupuleti
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We currently have nodetool commands to invalidate certain caches like
> KeyCache, RowCache and CounterCache.
> Being able to invalidate auth caches as well can come in handy in situations
> where, critical backend auth changes may need to be in effect right away for
> all the connections, especially in configurations where cache validity is
> chosen to be for a longer duration. An example can be that an authenticated
> user "User1" is no longer authorized to access a table resource "table1" and
> it is vital that this change is reflected right away, without having to wait
> for cache expiry/refresh to trigger.
--
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-15135) SASI tokenizer options not validated before being added to schema
[ https://issues.apache.org/jira/browse/CASSANDRA-15135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400601#comment-17400601 ] Stefan Miklosovic commented on CASSANDRA-15135: --- thanks for the review, ci on the way, i ll ping you once it is prepared to be +1 for you. > SASI tokenizer options not validated before being added to schema > - > > Key: CASSANDRA-15135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15135 > Project: Cassandra > Issue Type: Bug > Components: Feature/SASI >Reporter: Vincent White >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > If you attempt to create a SASI index with an illegal argument combination > the index will be added to the schema tables before trying instantiate the > tokenizer which causes a RuntimeException. Since the index was written to the > schema tables, cassandra will hit the same exception and fail to start when > it tries to load the schema on boot. > The branch below includes a unit test to reproduce the issue. > ||3.11|| > |[PoC|https://github.com/vincewhite/cassandra/commit/089547946d284ae3feb0d5620067b85b8fd66ebc]| > -- 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-16725) Implement nodetool getauditlog command
[ https://issues.apache.org/jira/browse/CASSANDRA-16725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400587#comment-17400587 ] Ekaterina Dimitrova commented on CASSANDRA-16725: - The implementation and CI run look good to me. There is only one thing I miss in the puzzle - why do we need [this|https://github.com/apache/cassandra/pull/1051/files#diff-9bf2c26bc294ef9085e16bf287490223665eaa2eb8ec24bcf5bd8653c713644bR5797] unused _enableAuditLog_ method? Should it be deprecated? I am a bit confused. I think you might want to add a comment about that and also put those 4 _enableAuditLog_ methods in the same order in StorageService and StorageServiceMbean. Thank you. > Implement nodetool getauditlog command > -- > > Key: CASSANDRA-16725 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16725 > Project: Cassandra > Issue Type: New Feature > Components: Tool/auditlogging >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1 > > Time Spent: 14h 10m > Remaining Estimate: 0h > > There is getfullquerylog already, there is not any reason why getauditlog > should not be there too. A user can not retrieve runtime configuration of > Audit log, it might be only enabled and disabled via jmx but its state can > not be queried in runtime. -- 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-website] branch asf-staging updated: latest changes from Paul Au (17th August 2021)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
The following commit(s) were added to refs/heads/asf-staging by this push:
new 86d5e6a latest changes from Paul Au (17th August 2021)
86d5e6a is described below
commit 86d5e6a1e97ba7103e7e288a236ac236d2857054
Author: mck
AuthorDate: Tue Aug 17 21:29:18 2021 +0200
latest changes from Paul Au (17th August 2021)
---
content/_/blog.html| 50 ++-
content/_/blog/Apache-Cassandra-4.0-is-Here.html | 2 +-
.../Apache-Cassandra-Changelog-9-August-2021.html | 447 +
...ndra-4.0-is-Here.html => Upgrade-Advisory.html} | 44 +-
content/_/community.html | 2 +-
content/_/download.html| 48 +--
content/search-index.js| 2 +-
content/sitemap.xml| 116 +++---
8 files changed, 596 insertions(+), 115 deletions(-)
diff --git a/content/_/blog.html b/content/_/blog.html
index 9fb1ae8..e6f377d 100644
--- a/content/_/blog.html
+++ b/content/_/blog.html
@@ -185,6 +185,54 @@
+Apache Cassandra
Upgrade Advisory
+August 16, 2021
+
+
+
+
+
+Users of Apache Cassandra 3.023, 3.0.24, 3.11.9 and 3.11.10 should upgrade
due to the potential for data corruption during schema changes.
+
+
+
+
+Read More
+
+
+
+
+
+
+
+
+
+
+
+Apache Cassandra
Changelog #9
+August 16, 2021
+
+
+
+
+
+Release of 4.0 GA, 3.0.25, and 3.0.11, upgrade advisory and Jon Meredith
becomes committer.
+
+
+
+
+Read More
+
+
+
+
+
+
+
+
+
+
+
Apache Cassandra 4.0
Overview
August 06, 2021
@@ -210,7 +258,7 @@
Apache Cassandra 4.0 is
Here
-July 19, 2021
+July 27, 2021
diff --git a/content/_/blog/Apache-Cassandra-4.0-is-Here.html
b/content/_/blog/Apache-Cassandra-4.0-is-Here.html
index 9b88346..13c6d8d 100644
--- a/content/_/blog/Apache-Cassandra-4.0-is-Here.html
+++ b/content/_/blog/Apache-Cassandra-4.0-is-Here.html
@@ -173,7 +173,7 @@
Apache Cassandra 4.0 is Here
-July 18, 2020 | The Apache Cassandra Community
+July 27, 2021 | The Apache Cassandra Community
diff --git a/content/_/blog/Apache-Cassandra-Changelog-9-August-2021.html
b/content/_/blog/Apache-Cassandra-Changelog-9-August-2021.html
new file mode 100644
index 000..d67f798
--- /dev/null
+++ b/content/_/blog/Apache-Cassandra-Changelog-9-August-2021.html
@@ -0,0 +1,447 @@
+
+
+
+
+
+Apache Cassandra | Apache Cassandra Documentation
+
+https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,400;0,700;1,400family=Red+Hat+Display:ital,wght@0,400;0,500;0,700;1,400;1,500display=swap;
rel="stylesheet">
+
+
+https://purl.org/dc/terms/;>
+
+
+
+
+
+ const script = document.createElement("script");
+ const domain = window.location.hostname;
+ script.type = "text/javascript";
+ script.src = "https://plausible.cassandra.apache.org/js/plausible.js";;
+ script.setAttribute("data-domain",domain);
+ script.setAttribute("defer",'true');
+ script.setAttribute("async",'true');
+ document.getElementsByTagName("head")[0].appendChild(script);
+
+
+
+https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js";>
+
+
+ https://cassandra.apache.org; />
+
+
+
+
+https://cassandra.apache.org;>
+
+
+
+
+
+Get Started
+
+
+
+
+
+
+
+Cassandra Basics
+
+
+
+
+
+
+
+
+
+Quickstart
+
+
+
+
+
+
+
+
+
+Ecosystem
+
+
+
+
+
+Documentation
+
+Community
+
+
+
+
+
+
+
+Welcome
+
+
+
+
+
+
+
+
+
+Discussions
+
+
+
+
+
+
+
+
+
[jira] [Updated] (CASSANDRA-16835) Scrub still uses "row" to mean "partitions", and has broken code
[ https://issues.apache.org/jira/browse/CASSANDRA-16835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16835: Since Version: 3.11.0 Source Control Link: https://github.com/apache/cassandra/commit/e581a85b93acff0fecef7d41d9a94a2f89f810ba Resolution: Fixed Status: Resolved (was: Ready to Commit) > Scrub still uses "row" to mean "partitions", and has broken code > > > Key: CASSANDRA-16835 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16835 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > > 2 issues in the scrub code: > 1) It still uses "row" to mean "partition". And not only in the code, but > also in user messages. As we've fairly systematically remove such instances > elsewhere in 3.0+, having it in scrub is going to confuse users which will > almost surely misinterpret the results. If scrub says that it dropped 2 > unreadable "rows" from your sstable, you might be ok with that when we're > actually talking about CQL rows, but not if we talk of 2 full partitions. > 2) There is a branch at the end of scrub that is supposed to handle the case > where scrubbing a sstable generates no output at all (the sstable is > completely hosed usually), mostly providing a more user friendly message. The > code is broken (and has been for a long time, since CASSANDRA-7066 I believe) > however such that this branch can simply never be taken (even when it > should). While admittedly pretty minor, no reason to leave it that way. -- 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-16835) Scrub still uses "row" to mean "partitions", and has broken code
[ https://issues.apache.org/jira/browse/CASSANDRA-16835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16835: Since Version: (was: 3.11.0) > Scrub still uses "row" to mean "partitions", and has broken code > > > Key: CASSANDRA-16835 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16835 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > > 2 issues in the scrub code: > 1) It still uses "row" to mean "partition". And not only in the code, but > also in user messages. As we've fairly systematically remove such instances > elsewhere in 3.0+, having it in scrub is going to confuse users which will > almost surely misinterpret the results. If scrub says that it dropped 2 > unreadable "rows" from your sstable, you might be ok with that when we're > actually talking about CQL rows, but not if we talk of 2 full partitions. > 2) There is a branch at the end of scrub that is supposed to handle the case > where scrubbing a sstable generates no output at all (the sstable is > completely hosed usually), mostly providing a more user friendly message. The > code is broken (and has been for a long time, since CASSANDRA-7066 I believe) > however such that this branch can simply never be taken (even when it > should). While admittedly pretty minor, no reason to leave it that way. -- 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-16835) Scrub still uses "row" to mean "partitions", and has broken code
[ https://issues.apache.org/jira/browse/CASSANDRA-16835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400576#comment-17400576 ] Ekaterina Dimitrova commented on CASSANDRA-16835: - Committed, thanks. To https://github.com/apache/cassandra.git 770dee5a57..e581a85b93 cassandra-3.11 -> cassandra-3.11 af6654cb06..cb19b39827 cassandra-4.0 -> cassandra-4.0 dc77cb8729..5b325b8c51 trunk -> trunk > Scrub still uses "row" to mean "partitions", and has broken code > > > Key: CASSANDRA-16835 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16835 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > > 2 issues in the scrub code: > 1) It still uses "row" to mean "partition". And not only in the code, but > also in user messages. As we've fairly systematically remove such instances > elsewhere in 3.0+, having it in scrub is going to confuse users which will > almost surely misinterpret the results. If scrub says that it dropped 2 > unreadable "rows" from your sstable, you might be ok with that when we're > actually talking about CQL rows, but not if we talk of 2 full partitions. > 2) There is a branch at the end of scrub that is supposed to handle the case > where scrubbing a sstable generates no output at all (the sstable is > completely hosed usually), mostly providing a more user friendly message. The > code is broken (and has been for a long time, since CASSANDRA-7066 I believe) > however such that this branch can simply never be taken (even when it > should). While admittedly pretty minor, no reason to leave it that way. -- 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/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 5b325b8c514911070ce63f5dafa897f321780a2b Merge: dc77cb8 cb19b39 Author: Ekaterina Dimitrova AuthorDate: Tue Aug 17 15:15:34 2021 -0400 Merge branch 'cassandra-4.0' into trunk CHANGES.txt| 1 + .../apache/cassandra/db/compaction/Scrubber.java | 167 +++-- .../cql3/validation/operations/TTLTest.java| 2 +- test/unit/org/apache/cassandra/db/ScrubTest.java | 39 +++-- 4 files changed, 109 insertions(+), 100 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (dc77cb8 -> 5b325b8)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from dc77cb8 Merge branch 'cassandra-4.0' into trunk add e581a85 Fixup scrub output when no data post-scrub and clear up old use of row, which really means partition patch by Ekaterina Dimitrova; reviewed by Brandon Williams for CASSANDRA-16835 add cb19b39 Merge branch 'cassandra-3.11' into cassandra-4.0 new 5b325b8 Merge branch 'cassandra-4.0' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../apache/cassandra/db/compaction/Scrubber.java | 167 +++-- .../cql3/validation/operations/TTLTest.java| 2 +- test/unit/org/apache/cassandra/db/ScrubTest.java | 39 +++-- 4 files changed, 109 insertions(+), 100 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (af6654c -> cb19b39)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from af6654c Merge branch 'cassandra-3.11' into cassandra-4.0 add e581a85 Fixup scrub output when no data post-scrub and clear up old use of row, which really means partition patch by Ekaterina Dimitrova; reviewed by Brandon Williams for CASSANDRA-16835 add cb19b39 Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../apache/cassandra/db/compaction/Scrubber.java | 167 +++-- .../cql3/validation/operations/TTLTest.java| 2 +- test/unit/org/apache/cassandra/db/ScrubTest.java | 39 +++-- 4 files changed, 109 insertions(+), 100 deletions(-) - 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 (770dee5 -> e581a85)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 770dee5 Regenerate CircleCI's MIDRES config file add e581a85 Fixup scrub output when no data post-scrub and clear up old use of row, which really means partition patch by Ekaterina Dimitrova; reviewed by Brandon Williams for CASSANDRA-16835 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../apache/cassandra/db/compaction/Scrubber.java | 153 +++-- test/unit/org/apache/cassandra/db/ScrubTest.java | 15 +- 3 files changed, 87 insertions(+), 82 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15821) Metrics Documentation Enhancements
[
https://issues.apache.org/jira/browse/CASSANDRA-15821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-15821:
Assignee: (was: Brandon Williams)
> Metrics Documentation Enhancements
> --
>
> Key: CASSANDRA-15821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15821
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Stephen Mallette
>Priority: Normal
> Fix For: 4.0.x
>
>
> CASSANDRA-15582 involves quality around metrics and it was mentioned that
> reviewing and [improving
> documentation|https://github.com/apache/cassandra/blob/trunk/doc/source/operating/metrics.rst]
> around metrics would fall into that scope. Please consider some of this
> analysis in determining what improvements to make here:
> Please see [this
> spreadsheet|https://docs.google.com/spreadsheets/d/1iPWfCMIG75CI6LbYuDtCTjEOvZw-5dyH-e08bc63QnI/edit?usp=sharing]
> that itemizes almost all of cassandra's metrics and whether they are
> documented or not (and other notes). That spreadsheet is "almost all"
> because there are some metrics that don't seem to initialize as part of
> Cassandra startup (i was able to trigger some to initialize, but all were not
> immediately obvious). The missing metrics seem to be related to the following:
> * ThreadPool metrics - only some initialize at startup the list of which
> follow below
> * Streaming Metrics
> * HintedHandoff Metrics
> * HintsService Metrics
> Here are the ThreadPool scopes that get listed:
> {code}
> AntiEntropyStage
> CacheCleanupExecutor
> CompactionExecutor
> GossipStage
> HintsDispatcher
> MemtableFlushWriter
> MemtablePostFlush
> MemtableReclaimMemory
> MigrationStage
> MutationStage
> Native-Transport-Requests
> PendingRangeCalculator
> PerDiskMemtableFlushWriter_0
> ReadStage
> Repair-Task
> RequestResponseStage
> Sampler
> SecondaryIndexManagement
> ValidationExecutor
> ViewBuildExecutor
> {code}
> I noticed that Keyspace Metrics have this note: "Most of these metrics are
> the same as the Table Metrics above, only they are aggregated at the Keyspace
> level." I think I've isolated those metrics on table that are not on keyspace
> to specifically be:
> {code}
> BloomFilterFalsePositives
> BloomFilterFalseRatio
> BytesAnticompacted
> BytesFlushed
> BytesMutatedAnticompaction
> BytesPendingRepair
> BytesRepaired
> BytesUnrepaired
> CompactionBytesWritten
> CompressionRatio
> CoordinatorReadLatency
> CoordinatorScanLatency
> CoordinatorWriteLatency
> EstimatedColumnCountHistogram
> EstimatedPartitionCount
> EstimatedPartitionSizeHistogram
> KeyCacheHitRate
> LiveSSTableCount
> MaxPartitionSize
> MeanPartitionSize
> MinPartitionSize
> MutatedAnticompactionGauge
> PercentRepaired
> RowCacheHitOutOfRange
> RowCacheHit
> RowCacheMiss
> SpeculativeSampleLatencyNanos
> SyncTime
> WaitingOnFreeMemtableSpace
> DroppedMutations
> {code}
> Someone with greater knowledge of this area might consider it worth the
> effort to see if any of these metrics should be aggregated to the keyspace
> level in case they were inadvertently missed. In any case, perhaps the
> documentation could easily now reflect which metric names could be expected
> on Keyspace.
> The DroppedMessage metrics have a much larger body of scopes than just what
> were documented:
> {code}
> ASYMMETRIC_SYNC_REQ
> BATCH_REMOVE_REQ
> BATCH_REMOVE_RSP
> BATCH_STORE_REQ
> BATCH_STORE_RSP
> CLEANUP_MSG
> COUNTER_MUTATION_REQ
> COUNTER_MUTATION_RSP
> ECHO_REQ
> ECHO_RSP
> FAILED_SESSION_MSG
> FAILURE_RSP
> FINALIZE_COMMIT_MSG
> FINALIZE_PROMISE_MSG
> FINALIZE_PROPOSE_MSG
> GOSSIP_DIGEST_ACK
> GOSSIP_DIGEST_ACK2
> GOSSIP_DIGEST_SYN
> GOSSIP_SHUTDOWN
> HINT_REQ
> HINT_RSP
> INTERNAL_RSP
> MUTATION_REQ
> MUTATION_RSP
> PAXOS_COMMIT_REQ
> PAXOS_COMMIT_RSP
> PAXOS_PREPARE_REQ
> PAXOS_PREPARE_RSP
> PAXOS_PROPOSE_REQ
> PAXOS_PROPOSE_RSP
> PING_REQ
> PING_RSP
> PREPARE_CONSISTENT_REQ
> PREPARE_CONSISTENT_RSP
> PREPARE_MSG
> RANGE_REQ
> RANGE_RSP
> READ_REPAIR_REQ
> READ_REPAIR_RSP
> READ_REQ
> READ_RSP
> REPAIR_RSP
> REPLICATION_DONE_REQ
> REPLICATION_DONE_RSP
> REQUEST_RSP
> SCHEMA_PULL_REQ
> SCHEMA_PULL_RSP
> SCHEMA_PUSH_REQ
> SCHEMA_PUSH_RSP
> SCHEMA_VERSION_REQ
> SCHEMA_VERSION_RSP
> SNAPSHOT_MSG
> SNAPSHOT_REQ
> SNAPSHOT_RSP
> STATUS_REQ
> STATUS_RSP
> SYNC_REQ
> SYNC_RSP
> TRUNCATE_REQ
> TRUNCATE_RSP
> VALIDATION_REQ
> VALIDATION_RSP
> _SAMPLE
> _TEST_1
> _TEST_2
> _TRACE
> {code}
> I suppose I may yet be missing some metrics as my knowledge of what's
> available is limited to what I can get from JMX after cassandra
> initialization (and some initial starting commands) and what's int he
> documentation. If something is present that is missing from both then I won't
> know it's there. Anyway, perhaps this issue can
[jira] [Updated] (CASSANDRA-13720) Clean up repair code
[ https://issues.apache.org/jira/browse/CASSANDRA-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-13720: -- Status: Ready to Commit (was: Review In Progress) > Clean up repair code > > > Key: CASSANDRA-13720 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13720 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Simon Zhou >Assignee: Simon Zhou >Priority: Normal > Fix For: 4.x > > > Lots of unused code. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13720) Clean up repair code
[ https://issues.apache.org/jira/browse/CASSANDRA-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400533#comment-17400533 ] Andres de la Peña commented on CASSANDRA-13720: --- [~e.dimitrova] Nothing to add, I think we are ready to commit. I can commit tomorrow, unless you have time to commit today, as you prefer. > Clean up repair code > > > Key: CASSANDRA-13720 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13720 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Simon Zhou >Assignee: Simon Zhou >Priority: Normal > Fix For: 4.x > > > Lots of unused code. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15135) SASI tokenizer options not validated before being added to schema
[ https://issues.apache.org/jira/browse/CASSANDRA-15135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-15135: -- Status: Review In Progress (was: Needs Reviewer) > SASI tokenizer options not validated before being added to schema > - > > Key: CASSANDRA-15135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15135 > Project: Cassandra > Issue Type: Bug > Components: Feature/SASI >Reporter: Vincent White >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > If you attempt to create a SASI index with an illegal argument combination > the index will be added to the schema tables before trying instantiate the > tokenizer which causes a RuntimeException. Since the index was written to the > schema tables, cassandra will hit the same exception and fail to start when > it tries to load the schema on boot. > The branch below includes a unit test to reproduce the issue. > ||3.11|| > |[PoC|https://github.com/vincewhite/cassandra/commit/089547946d284ae3feb0d5620067b85b8fd66ebc]| > -- 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-15135) SASI tokenizer options not validated before being added to schema
[ https://issues.apache.org/jira/browse/CASSANDRA-15135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400524#comment-17400524 ] Andres de la Peña commented on CASSANDRA-15135: --- Nice catch, overall the approach looks good to me. I have left some comments in the PR. Also, do we have CI results? > SASI tokenizer options not validated before being added to schema > - > > Key: CASSANDRA-15135 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15135 > Project: Cassandra > Issue Type: Bug > Components: Feature/SASI >Reporter: Vincent White >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > If you attempt to create a SASI index with an illegal argument combination > the index will be added to the schema tables before trying instantiate the > tokenizer which causes a RuntimeException. Since the index was written to the > schema tables, cassandra will hit the same exception and fail to start when > it tries to load the schema on boot. > The branch below includes a unit test to reproduce the issue. > ||3.11|| > |[PoC|https://github.com/vincewhite/cassandra/commit/089547946d284ae3feb0d5620067b85b8fd66ebc]| > -- 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-13720) Clean up repair code
[ https://issues.apache.org/jira/browse/CASSANDRA-13720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400520#comment-17400520 ] Ekaterina Dimitrova commented on CASSANDRA-13720: - Thanks for confirming, not an issue that you squashed as it is a small patch, but normally we try not to do it for bigger works with more people involved. Can be easier to follow. :) [~adelapena], are we ready to commit this one? Do you have anything to add here? > Clean up repair code > > > Key: CASSANDRA-13720 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13720 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Simon Zhou >Assignee: Simon Zhou >Priority: Normal > Fix For: 4.x > > > Lots of unused code. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16721) Repaired data tracking on a read coordinator is susceptible to races between local and remote requests
[
https://issues.apache.org/jira/browse/CASSANDRA-16721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400123#comment-17400123
]
Caleb Rackliffe edited comment on CASSANDRA-16721 at 8/17/21, 4:44 PM:
---
I took a stab at it [here|https://github.com/apache/cassandra/pull/1149].
(There are still a few TODOs lying around.) Let's see if I
[broke|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-16721-local-rdi]
anything...
UPDATE: The unit and in-jvm tests look ok, with the exception of
{{RowIterationTest}}, where there is something strange going on between tests
when we drop tables and keyspaces. (Looks like I forgot to close the controller
in the modified read utilities.)
was (Author: maedhroz):
I took a stab at it [here|https://github.com/apache/cassandra/pull/1149].
(There are still a few TODOs lying around.) Let's see if I
[broke|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-16721-local-rdi]
anything...
UPDATE: The unit and in-jvm tests look ok, with the exception of
{{RowIterationTest}}, where there is something strange going on between tests
when we drop tables and keyspaces.
> Repaired data tracking on a read coordinator is susceptible to races between
> local and remote requests
> --
>
> Key: CASSANDRA-16721
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16721
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0.x
>
>
> At read time on a coordinator which is also a replica, the local and remote
> reads can race such that the remote responses are received while the local
> read is executing. If the remote responses are mismatching, triggering a
> {{DigestMismatchException}} and subsequent round of full data reads and read
> repair, the local runnable may find the {{isTrackingRepairedStatus}} flag
> flipped mid-execution. If this happens after a certain point in execution,
> it would mean
> that the RepairedDataInfo instance in use is the singleton null object
> {{RepairedDataInfo.NULL_REPAIRED_DATA_INFO}}. If this happens, it can lead to
> an NPE when calling {{RepairedDataInfo::extend}} when the local results are
> iterated.
--
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-16721) Repaired data tracking on a read coordinator is susceptible to races between local and remote requests
[
https://issues.apache.org/jira/browse/CASSANDRA-16721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400123#comment-17400123
]
Caleb Rackliffe edited comment on CASSANDRA-16721 at 8/17/21, 4:31 PM:
---
I took a stab at it [here|https://github.com/apache/cassandra/pull/1149].
(There are still a few TODOs lying around.) Let's see if I
[broke|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-16721-local-rdi]
anything...
UPDATE: The unit and in-jvm tests look ok, with the exception of
{{RowIterationTest}}, where there is something strange going on between tests
when we drop tables and keyspaces.
was (Author: maedhroz):
I took a stab at it [here|https://github.com/apache/cassandra/pull/1149].
(There are still a few TODOs lying around.) Let's see if I
[broke|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-16721-local-rdi]
anything...
> Repaired data tracking on a read coordinator is susceptible to races between
> local and remote requests
> --
>
> Key: CASSANDRA-16721
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16721
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Normal
> Fix For: 4.0.x
>
>
> At read time on a coordinator which is also a replica, the local and remote
> reads can race such that the remote responses are received while the local
> read is executing. If the remote responses are mismatching, triggering a
> {{DigestMismatchException}} and subsequent round of full data reads and read
> repair, the local runnable may find the {{isTrackingRepairedStatus}} flag
> flipped mid-execution. If this happens after a certain point in execution,
> it would mean
> that the RepairedDataInfo instance in use is the singleton null object
> {{RepairedDataInfo.NULL_REPAIRED_DATA_INFO}}. If this happens, it can lead to
> an NPE when calling {{RepairedDataInfo::extend}} when the local results are
> iterated.
--
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-16850) Add client warnings and abort to tombstone and coordinator reads which go past a low/high watermark
[
https://issues.apache.org/jira/browse/CASSANDRA-16850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400474#comment-17400474
]
Blake Eggleston commented on CASSANDRA-16850:
-
bq. you are saying the global one should as well?
Sure, I think so, though I think we need a top level "Aborts" meter if we have
the component ones
bq. I think we could do Map where the string is the simple name
of the class?
That sounds a little brittle. If you're worried about complicating exception
handling, you could add a method to {{ClientRequestMetrics}} that accepts an
exception and marks the appropriate field.
Also, I think the change to ReadCommand.trackWarnings should be reverted (and
the later change to LocalReadRunnable). Adding a config flag to turn the client
warnings on/off is a good idea, but it should be applied at the coordinator,
and the replicas should do what the coordinator asks. That includes the local
runnable too, the coordinator should tell the local runnable whether to track
warnings or not. Since an incorrectly interpreted flag would result in an
incorrect client response, we shouldn't leave any room for race edge cases.
> Add client warnings and abort to tombstone and coordinator reads which go
> past a low/high watermark
> ---
>
> Key: CASSANDRA-16850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16850
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We currently will abort queries if we hit too many tombstones, but its common
> that we would want to also warn clients (client warnings) about this before
> we get that point; its also common that different logic would like to be able
> to warn/abort about client options (such as reading a large partition). To
> allow this we should add a concept of low/high watermarks (warn/abort) to
> tombstones and coordinator reads.
> Another issue is that current aborts look the same as a random failure, so
> from an SLA point of view it would be good to differentiate between user
> behavior being rejected and unexplained issue.
--
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-16859) allow blocking IPs from updating metrics about traffic
[ https://issues.apache.org/jira/browse/CASSANDRA-16859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-16859: - Reviewers: Caleb Rackliffe, Jon Meredith (was: Caleb Rackliffe) > allow blocking IPs from updating metrics about traffic > -- > > Key: CASSANDRA-16859 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16859 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > It is common that network scans happen for some companies, and when these > scans happen they will send packets to the Cassandra ports which do not match > our protocol; when this happens we fail and increment metrics to show this. > To avoid these scans polluting our metrics, we should allow users to block > their own IP subnets from updating these metrics. -- 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-16451) Add ability to ttl snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-16451:
--
Fix Version/s: 4.x
> Add ability to ttl snapshots
>
>
> Key: CASSANDRA-16451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16451
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Paulo Motta
>Assignee: Abuli Palagashvili
>Priority: Normal
> Labels: gsoc2021, mentor
> Fix For: 4.x
>
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> It should be possible to add a TTL to snapshots, after which it automatically
> cleans itself up.
> This will be useful together with the {{auto_snapshot}} option, where you
> want to keep an emergency snapshot in case of accidental drop or truncation
> but automatically remove it after a specified period when it's no longer
> useful. So in addition to allowing a user to specify a snapshot ttl on
> {{nodetool snapshot}} we should have a {{auto_snapshot_ttl}} option that
> allows a user to set a ttl for automatic snaphots on drop/truncate.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16858) CircleCI MIDRES might be missing some changes in 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-16858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16858:
--
Fix Version/s: (was: 3.11.x)
3.11.12
Since Version: 3.11.11
Source Control Link:
https://github.com/apache/cassandra/commit/770dee5a57da96696b3df64384326786c0506762
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> CircleCI MIDRES might be missing some changes in 3.11
> -
>
> Key: CASSANDRA-16858
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16858
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.11.12
>
>
> I've noticed that when we run {{.circleci/generate.sh}} in 3.11 the file
> {{config.yml.MIDRES}} is modified, when I'd say it shouldn't be changed. If
> I'm right running that script should be noop when there hasn't been changes
> in {{config-2_1.yml}}, and indeed the file isn't modified in the other
> branches.
> Not sure yet, but I think that this might be the result of not having
> generated a new {{config.yml.MIDRES}} with the script when merging 3.0 into
> 3.11 during CASSANDRA-16804.
--
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-16858) CircleCI MIDRES might be missing some changes in 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-16858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400427#comment-17400427
]
Andres de la Peña commented on CASSANDRA-16858:
---
Thanks for confirming it, committed to 3.11 as
[770dee5a57da96696b3df64384326786c0506762|https://github.com/apache/cassandra/commit/770dee5a57da96696b3df64384326786c0506762].
> CircleCI MIDRES might be missing some changes in 3.11
> -
>
> Key: CASSANDRA-16858
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16858
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.11.x
>
>
> I've noticed that when we run {{.circleci/generate.sh}} in 3.11 the file
> {{config.yml.MIDRES}} is modified, when I'd say it shouldn't be changed. If
> I'm right running that script should be noop when there hasn't been changes
> in {{config-2_1.yml}}, and indeed the file isn't modified in the other
> branches.
> Not sure yet, but I think that this might be the result of not having
> generated a new {{config.yml.MIDRES}} with the script when merging 3.0 into
> 3.11 during CASSANDRA-16804.
--
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-4.0 updated (ce21eb5 -> af6654c)
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from ce21eb5 Add tests for the Hint service metrics new 770dee5 Regenerate CircleCI's MIDRES config file new af6654c Merge branch 'cassandra-3.11' into cassandra-4.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: - 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-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit dc77cb8729f0cd711479071bd32f0923105ab1a8 Merge: 8d6b155 af6654c Author: Andrés de la Peña AuthorDate: Tue Aug 17 15:19:37 2021 +0100 Merge branch 'cassandra-4.0' into trunk - 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: Regenerate CircleCI's MIDRES config file
This is an automated email from the ASF dual-hosted git repository.
adelapena 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 770dee5 Regenerate CircleCI's MIDRES config file
770dee5 is described below
commit 770dee5a57da96696b3df64384326786c0506762
Author: Andrés de la Peña
AuthorDate: Tue Aug 17 15:18:22 2021 +0100
Regenerate CircleCI's MIDRES config file
patch by Andrés de la Peña; reviewed by Ekaterina Dimitrova for
CASSANDRA-16858
---
.circleci/config.yml.MIDRES | 79 ++---
1 file changed, 74 insertions(+), 5 deletions(-)
diff --git a/.circleci/config.yml.MIDRES b/.circleci/config.yml.MIDRES
index 1222997..798ff35 100644
--- a/.circleci/config.yml.MIDRES
+++ b/.circleci/config.yml.MIDRES
@@ -21,10 +21,10 @@ jobs:
j8_jvm_upgrade_dtests:
docker:
- image: apache/cassandra-testing-ubuntu2004-java11-w-dependencies:20210304
-resource_class: medium
+resource_class: large
working_directory: ~/
shell: /bin/bash -eo pipefail -l
-parallelism: 1
+parallelism: 4
steps:
- attach_workspace:
at: /home/cassandra
@@ -826,6 +826,68 @@ jobs:
- REPEATED_JVM_UPGRADE_DTEST_STOP_ON_FAILURE: false
- JAVA_HOME: /usr/lib/jvm/java-8-openjdk-amd64
- JDK_HOME: /usr/lib/jvm/java-8-openjdk-amd64
+ utests_stress:
+docker:
+- image: apache/cassandra-testing-ubuntu2004-java11-w-dependencies:20210304
+resource_class: medium
+working_directory: ~/
+shell: /bin/bash -eo pipefail -l
+parallelism: 1
+steps:
+- attach_workspace:
+at: /home/cassandra
+- run:
+name: Run Unit Tests (stress-test)
+command: |
+ export PATH=$JAVA_HOME/bin:$PATH
+ time mv ~/cassandra /tmp
+ cd /tmp/cassandra
+ if [ -d ~/dtest_jars ]; then
+cp ~/dtest_jars/dtest* /tmp/cassandra/build/
+ fi
+ ant stress-test
-Dtest.classlistfile=/tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
-Dtest.classlistprefix=unit
+no_output_timeout: 15m
+- store_test_results:
+path: /tmp/cassandra/build/test/output/
+- store_artifacts:
+path: /tmp/cassandra/build/test/output
+destination: junitxml
+- store_artifacts:
+path: /tmp/cassandra/build/test/logs
+destination: logs
+environment:
+- JAVA8_HOME: /usr/lib/jvm/java-8-openjdk-amd64
+- ANT_HOME: /usr/share/ant
+- LANG: en_US.UTF-8
+- KEEP_TEST_DIR: true
+- DEFAULT_DIR: /home/cassandra/cassandra-dtest
+- PYTHONIOENCODING: utf-8
+- PYTHONUNBUFFERED: true
+- CASS_DRIVER_NO_EXTENSIONS: true
+- CASS_DRIVER_NO_CYTHON: true
+- CASSANDRA_SKIP_SYNC: true
+- DTEST_REPO: git://github.com/apache/cassandra-dtest.git
+- DTEST_BRANCH: trunk
+- CCM_MAX_HEAP_SIZE: 1024M
+- CCM_HEAP_NEWSIZE: 256M
+- REPEATED_UTEST_TARGET: testsome
+- REPEATED_UTEST_CLASS: null
+- REPEATED_UTEST_METHODS: null
+- REPEATED_UTEST_COUNT: 100
+- REPEATED_UTEST_STOP_ON_FAILURE: false
+- REPEATED_DTEST_NAME: null
+- REPEATED_DTEST_VNODES: false
+- REPEATED_DTEST_COUNT: 100
+- REPEATED_DTEST_STOP_ON_FAILURE: false
+- REPEATED_UPGRADE_DTEST_NAME: null
+- REPEATED_UPGRADE_DTEST_COUNT: 100
+- REPEATED_UPGRADE_DTEST_STOP_ON_FAILURE: false
+- REPEATED_JVM_UPGRADE_DTEST_CLASS: null
+- REPEATED_JVM_UPGRADE_DTEST_METHODS: null
+- REPEATED_JVM_UPGRADE_DTEST_COUNT: 100
+- REPEATED_JVM_UPGRADE_DTEST_STOP_ON_FAILURE: false
+- JAVA_HOME: /usr/lib/jvm/java-8-openjdk-amd64
+- JDK_HOME: /usr/lib/jvm/java-8-openjdk-amd64
j8_unit_tests:
docker:
- image: apache/cassandra-testing-ubuntu2004-java11-w-dependencies:20210304
@@ -1011,10 +1073,10 @@ jobs:
j8_jvm_dtests:
docker:
- image: apache/cassandra-testing-ubuntu2004-java11-w-dependencies:20210304
-resource_class: medium
+resource_class: large
working_directory: ~/
shell: /bin/bash -eo pipefail -l
-parallelism: 1
+parallelism: 10
steps:
- attach_workspace:
at: /home/cassandra
@@ -1135,7 +1197,7 @@ jobs:
if [ -d ~/dtest_jars ]; then
cp ~/dtest_jars/dtest* /tmp/cassandra/build/
fi
- ant clean long-test
+ ant long-test
-Dtest.classlistfile=/tmp/java_tests_${CIRCLE_NODE_INDEX}_final.txt
-Dtest.classlistprefix=unit
no_output_timeout: 15m
- store_test_results:
path: /tmp/cassandra/build/test/output/
@@ -1579,6 +1641,13 @@ workflows:
- utests_compression:
requires:
- start_utests_compression
+- start_utests_stress:
+type: approval
+requires:
+- build
+- utests_stress:
+requires:
+- start_utests_stress
- start_j8_dtest_jars_build:
type:
[cassandra] branch trunk updated (8d6b155 -> dc77cb8)
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 8d6b155 Merge branch 'cassandra-4.0' into trunk new 770dee5 Regenerate CircleCI's MIDRES config file new af6654c Merge branch 'cassandra-3.11' into cassandra-4.0 new dc77cb8 Merge branch 'cassandra-4.0' into trunk The 3 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 cassandra-4.0
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit af6654cb062331ac4fd344c559afd36f524a9baf Merge: ce21eb5 770dee5 Author: Andrés de la Peña AuthorDate: Tue Aug 17 15:19:13 2021 +0100 Merge branch 'cassandra-3.11' into cassandra-4.0 # Conflicts: # .circleci/config.yml.MIDRES - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16189) Add tests for the Hint service metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-16189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-16189: -- Fix Version/s: (was: 4.0.x) 4.1 4.0.1 Source Control Link: https://github.com/apache/cassandra/commit/8d6b1558bec3a940941fb392c0a555122c72026f Resolution: Fixed Status: Resolved (was: Ready to Commit) > Add tests for the Hint service metrics > -- > > Key: CASSANDRA-16189 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16189 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Benjamin Lerer >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.0.1, 4.1 > > Attachments: 0001-added-hints-metrics-test.patch > > Time Spent: 10m > Remaining Estimate: 0h > > There are currently no tests for the hint metrics -- 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-16189) Add tests for the Hint service metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-16189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400419#comment-17400419
]
Andres de la Peña commented on CASSANDRA-16189:
---
Thanks for the review, committed to {{cassandra-4.0}} as
[ce21eb5fac385098b7ed19c77167a38b5dee230a|https://github.com/apache/cassandra/commit/ce21eb5fac385098b7ed19c77167a38b5dee230a]
and merged to
[trunk|https://github.com/apache/cassandra/commit/8d6b1558bec3a940941fb392c0a555122c72026f].
> Add tests for the Hint service metrics
> --
>
> Key: CASSANDRA-16189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16189
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Benjamin Lerer
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: 0001-added-hints-metrics-test.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are currently no tests for the hint metrics
--
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-4.0 updated: Add tests for the Hint service metrics
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-4.0 by this push:
new ce21eb5 Add tests for the Hint service metrics
ce21eb5 is described below
commit ce21eb5fac385098b7ed19c77167a38b5dee230a
Author: Andrés de la Peña
AuthorDate: Tue Aug 17 13:43:29 2021 +0100
Add tests for the Hint service metrics
patch by Andrés de la Peña; reviewed by Benjamin Lerer for CASSANDRA-16189
---
.../distributed/impl/InstanceMetrics.java | 15 +-
.../test/metrics/HintsServiceMetricsTest.java | 231 +
2 files changed, 241 insertions(+), 5 deletions(-)
diff --git
a/test/distributed/org/apache/cassandra/distributed/impl/InstanceMetrics.java
b/test/distributed/org/apache/cassandra/distributed/impl/InstanceMetrics.java
index 3bd5894..939691d 100644
---
a/test/distributed/org/apache/cassandra/distributed/impl/InstanceMetrics.java
+++
b/test/distributed/org/apache/cassandra/distributed/impl/InstanceMetrics.java
@@ -69,10 +69,7 @@ class InstanceMetrics implements Metrics
public double getHistogram(String name, MetricValue value)
{
Histogram histogram = metricsRegistry.getHistograms().get(name);
-if (value == MetricValue.COUNT)
-return histogram.getCount();
-
-return getValue(histogram.getSnapshot(), value);
+return getValue(histogram, value);
}
public Map getHistograms(Predicate filter,
MetricValue value)
@@ -81,7 +78,7 @@ class InstanceMetrics implements Metrics
for (Map.Entry e :
metricsRegistry.getHistograms().entrySet())
{
if (filter.test(e.getKey()))
-values.put(e.getKey(), getValue(e.getValue().getSnapshot(),
value));
+values.put(e.getKey(), getValue(e.getValue(), value));
}
return values;
}
@@ -135,6 +132,14 @@ class InstanceMetrics implements Metrics
return values;
}
+static double getValue(Histogram histogram, MetricValue value)
+{
+if (value == MetricValue.COUNT)
+return histogram.getCount();
+
+return getValue(histogram.getSnapshot(), value);
+}
+
static double getValue(Snapshot snapshot, MetricValue value)
{
switch (value)
diff --git
a/test/distributed/org/apache/cassandra/distributed/test/metrics/HintsServiceMetricsTest.java
b/test/distributed/org/apache/cassandra/distributed/test/metrics/HintsServiceMetricsTest.java
new file mode 100644
index 000..a47c782
--- /dev/null
+++
b/test/distributed/org/apache/cassandra/distributed/test/metrics/HintsServiceMetricsTest.java
@@ -0,0 +1,231 @@
+/*
+ * 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.distributed.test.metrics;
+
+import java.util.Arrays;
+import java.util.concurrent.Callable;
+import java.util.concurrent.CompletableFuture;
+import java.util.concurrent.atomic.AtomicBoolean;
+import java.util.concurrent.atomic.AtomicInteger;
+
+import org.junit.Test;
+
+import net.bytebuddy.ByteBuddy;
+import net.bytebuddy.dynamic.loading.ClassLoadingStrategy;
+import net.bytebuddy.implementation.MethodDelegation;
+import net.bytebuddy.implementation.bind.annotation.SuperCall;
+import org.apache.cassandra.distributed.Cluster;
+import org.apache.cassandra.distributed.api.ICoordinator;
+import org.apache.cassandra.distributed.api.IInvokableInstance;
+import org.apache.cassandra.distributed.shared.Metrics;
+import org.apache.cassandra.distributed.test.TestBaseImpl;
+import org.apache.cassandra.hints.Hint;
+import org.apache.cassandra.metrics.HintsServiceMetrics;
+import org.apache.cassandra.net.Verb;
+import org.awaitility.core.ThrowingRunnable;
+
+import static java.util.concurrent.TimeUnit.MINUTES;
+import static java.util.concurrent.TimeUnit.SECONDS;
+import static net.bytebuddy.matcher.ElementMatchers.named;
+import static net.bytebuddy.matcher.ElementMatchers.takesArguments;
+import static org.apache.cassandra.distributed.api.ConsistencyLevel.QUORUM;
+import static
[cassandra] branch trunk updated (76f1a64 -> 8d6b155)
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 76f1a64 Merge branch 'cassandra-4.0' into trunk new ce21eb5 Add tests for the Hint service metrics new 8d6b155 Merge branch 'cassandra-4.0' into trunk The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../distributed/impl/InstanceMetrics.java | 15 +- .../test/metrics/HintsServiceMetricsTest.java | 231 + 2 files changed, 241 insertions(+), 5 deletions(-) create mode 100644 test/distributed/org/apache/cassandra/distributed/test/metrics/HintsServiceMetricsTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 8d6b1558bec3a940941fb392c0a555122c72026f Merge: 76f1a64 ce21eb5 Author: Andrés de la Peña AuthorDate: Tue Aug 17 15:03:14 2021 +0100 Merge branch 'cassandra-4.0' into trunk .../distributed/impl/InstanceMetrics.java | 15 +- .../test/metrics/HintsServiceMetricsTest.java | 231 + 2 files changed, 241 insertions(+), 5 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16843) auto-snapshots for dropped tables don't appear in nodetool listsnapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400413#comment-17400413
]
Brandon Williams commented on CASSANDRA-16843:
--
bq. centralizing snapshot management on a `SnapshotManager` module decoupled
from CFS
You have read my mind on where I'd like to see things go! If only that didn't
seem a bit too heavy handed for point releases...
> auto-snapshots for dropped tables don't appear in nodetool listsnapshots
>
>
> Key: CASSANDRA-16843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16843
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: James Brown
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> Auto snapshots from dropped tables don't seem to show up in {{nodetool
> listsnapshots}} (even though they do get cleared by {{nodetool
> clearsnapshot}}). This makes them kind of annoying to clean up, since you
> need to muck about in the data directory to find them.
> Erick on the mailing list said that this seems to be an oversight and that
> clearsnapshot was fixed by
> [CASSANDRA-6418|https://issues.apache.org/jira/browse/CASSANDRA-6418].
> I reproduced this both on 3.11.11 and 4.0.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-16843) auto-snapshots for dropped tables don't appear in nodetool listsnapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400410#comment-17400410
]
Paulo Motta commented on CASSANDRA-16843:
-
bq. For trunk I think we should probably refactor snapshot handling altogether
to dissolve the marriage between CFs and snapshots a bit, but for existing
versions I'm not sure what the least invasive way of reworking this is yet.
We've been going towards this direction on CASSANDRA-16451 by centralizing
snapshot management on a `SnapshotManager` module decoupled from CFS, but so
far restricted to snapshots created with TTL. Myself and [~stefan.miklosovic]
plan to extend this to "legacy" snapshots after that work is finished which
will make it easier to solve this issue on trunk/4.1.
> auto-snapshots for dropped tables don't appear in nodetool listsnapshots
>
>
> Key: CASSANDRA-16843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16843
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: James Brown
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> Auto snapshots from dropped tables don't seem to show up in {{nodetool
> listsnapshots}} (even though they do get cleared by {{nodetool
> clearsnapshot}}). This makes them kind of annoying to clean up, since you
> need to muck about in the data directory to find them.
> Erick on the mailing list said that this seems to be an oversight and that
> clearsnapshot was fixed by
> [CASSANDRA-6418|https://issues.apache.org/jira/browse/CASSANDRA-6418].
> I reproduced this both on 3.11.11 and 4.0.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-16835) Scrub still uses "row" to mean "partitions", and has broken code
[ https://issues.apache.org/jira/browse/CASSANDRA-16835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400407#comment-17400407 ] Ekaterina Dimitrova commented on CASSANDRA-16835: - All known errors. Except [this one|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1082/workflows/8dacef5d-46f4-4b59-a8f7-08824bf1180f/jobs/6407/tests#failed-test-0] which is stable in Jenkins but shows as flaky in the multiplexer so I am going to open a separate ticket for it. Preparing to commit > Scrub still uses "row" to mean "partitions", and has broken code > > > Key: CASSANDRA-16835 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16835 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > > 2 issues in the scrub code: > 1) It still uses "row" to mean "partition". And not only in the code, but > also in user messages. As we've fairly systematically remove such instances > elsewhere in 3.0+, having it in scrub is going to confuse users which will > almost surely misinterpret the results. If scrub says that it dropped 2 > unreadable "rows" from your sstable, you might be ok with that when we're > actually talking about CQL rows, but not if we talk of 2 full partitions. > 2) There is a branch at the end of scrub that is supposed to handle the case > where scrubbing a sstable generates no output at all (the sstable is > completely hosed usually), mostly providing a more user friendly message. The > code is broken (and has been for a long time, since CASSANDRA-7066 I believe) > however such that this branch can simply never be taken (even when it > should). While admittedly pretty minor, no reason to leave it that way. -- 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-16843) auto-snapshots for dropped tables don't appear in nodetool listsnapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400409#comment-17400409
]
Stefan Miklosovic commented on CASSANDRA-16843:
---
We plan to overhaul snapshots a lot in a forseeable future so one might expect
improvements and refactoring which would enable what you need.
> auto-snapshots for dropped tables don't appear in nodetool listsnapshots
>
>
> Key: CASSANDRA-16843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16843
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: James Brown
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> Auto snapshots from dropped tables don't seem to show up in {{nodetool
> listsnapshots}} (even though they do get cleared by {{nodetool
> clearsnapshot}}). This makes them kind of annoying to clean up, since you
> need to muck about in the data directory to find them.
> Erick on the mailing list said that this seems to be an oversight and that
> clearsnapshot was fixed by
> [CASSANDRA-6418|https://issues.apache.org/jira/browse/CASSANDRA-6418].
> I reproduced this both on 3.11.11 and 4.0.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-16843) auto-snapshots for dropped tables don't appear in nodetool listsnapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400406#comment-17400406
]
Brandon Williams commented on CASSANDRA-16843:
--
I'm aware of it. It's another wrinkle to this problem that can't really be
dealt with before the existing issues, but I'll take another look when it lands.
> auto-snapshots for dropped tables don't appear in nodetool listsnapshots
>
>
> Key: CASSANDRA-16843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16843
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: James Brown
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> Auto snapshots from dropped tables don't seem to show up in {{nodetool
> listsnapshots}} (even though they do get cleared by {{nodetool
> clearsnapshot}}). This makes them kind of annoying to clean up, since you
> need to muck about in the data directory to find them.
> Erick on the mailing list said that this seems to be an oversight and that
> clearsnapshot was fixed by
> [CASSANDRA-6418|https://issues.apache.org/jira/browse/CASSANDRA-6418].
> I reproduced this both on 3.11.11 and 4.0.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-16843) auto-snapshots for dropped tables don't appear in nodetool listsnapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400404#comment-17400404
]
Stefan Miklosovic commented on CASSANDRA-16843:
---
FYI we are working on this https://github.com/apache/cassandra/pull/1046/files
We plan to merge it basically this week (right [~paulo]?) We might try to get
back to this afterwards to see if anything changed in that regard.
> auto-snapshots for dropped tables don't appear in nodetool listsnapshots
>
>
> Key: CASSANDRA-16843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16843
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: James Brown
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> Auto snapshots from dropped tables don't seem to show up in {{nodetool
> listsnapshots}} (even though they do get cleared by {{nodetool
> clearsnapshot}}). This makes them kind of annoying to clean up, since you
> need to muck about in the data directory to find them.
> Erick on the mailing list said that this seems to be an oversight and that
> clearsnapshot was fixed by
> [CASSANDRA-6418|https://issues.apache.org/jira/browse/CASSANDRA-6418].
> I reproduced this both on 3.11.11 and 4.0.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-16404) Provide a nodetool way of invalidating auth caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400403#comment-17400403
]
Sam Tunnicliffe commented on CASSANDRA-16404:
-
Rather than going back to the old bean names, we have a precedent of aliasing
and deprecating them. I've pushed a additional commit to my branch which fixes
the original test failure in this way. I've also extended the dtest to cover
both the old and new bean name (for {{NetworkAuthTest}} only, it didn't seem
worth adding new tests for the JMX cache just for this).
Also (temporarily) modified circle config to use my own dtest branch & started
a new apache ci job
[here|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1032]
> Provide a nodetool way of invalidating auth caches
> --
>
> Key: CASSANDRA-16404
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16404
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization
>Reporter: Sumanth Pasupuleti
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We currently have nodetool commands to invalidate certain caches like
> KeyCache, RowCache and CounterCache.
> Being able to invalidate auth caches as well can come in handy in situations
> where, critical backend auth changes may need to be in effect right away for
> all the connections, especially in configurations where cache validity is
> chosen to be for a longer duration. An example can be that an authenticated
> user "User1" is no longer authorized to access a table resource "table1" and
> it is vital that this change is reflected right away, without having to wait
> for cache expiry/refresh to trigger.
--
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-16843) auto-snapshots for dropped tables don't appear in nodetool listsnapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400400#comment-17400400
]
Brandon Williams edited comment on CASSANDRA-16843 at 8/17/21, 1:44 PM:
This unfortunately is not a simple thing to fix in an elegant manner. We have
a habit of assuming the lifetimes of snapshots will always be contained by
their respective CFs. It is that assumption that got us into both
CASSANDRA-6418 and CASSANDRA-6821, and now this ticket as well. Most of the
code that handles snapshots is in instance methods of Directories.java, which
is instantiated with CFMetatadata, and ultimately StorageService is accessing
information through them from the ColumnFamilyStore... which won't exist for
dropped tables.
For trunk I think we should probably refactor snapshot handling altogether to
dissolve the marriage between CFs and snapshots a bit, but for existing
versions I'm not sure what the least invasive way of reworking this is yet.
was (Author: brandon.williams):
This unfortunately not a simple thing to fix in an elegant manner. We have a
habit of assuming the lifetimes of snapshots will always be contained by their
respective CFs. It is that assumption that got us into both CASSANDRA-6418 and
CASSANDRA-6821, and now this ticket as well. Most of the code that handles
snapshots is in instance methods of Directories.java, which is instantiated
with CFMetatadata, and ultimately StorageService is accessing information
through them from the ColumnFamilyStore... which won't exist for dropped tables.
For trunk I think we should probably refactor snapshot handling altogether to
dissolve the marriage between CFs and snapshots a bit, but for existing
versions I'm not sure what the least invasive way of reworking this is yet.
> auto-snapshots for dropped tables don't appear in nodetool listsnapshots
>
>
> Key: CASSANDRA-16843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16843
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: James Brown
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> Auto snapshots from dropped tables don't seem to show up in {{nodetool
> listsnapshots}} (even though they do get cleared by {{nodetool
> clearsnapshot}}). This makes them kind of annoying to clean up, since you
> need to muck about in the data directory to find them.
> Erick on the mailing list said that this seems to be an oversight and that
> clearsnapshot was fixed by
> [CASSANDRA-6418|https://issues.apache.org/jira/browse/CASSANDRA-6418].
> I reproduced this both on 3.11.11 and 4.0.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-16843) auto-snapshots for dropped tables don't appear in nodetool listsnapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-16843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400400#comment-17400400
]
Brandon Williams commented on CASSANDRA-16843:
--
This unfortunately not a simple thing to fix in an elegant manner. We have a
habit of assuming the lifetimes of snapshots will always be contained by their
respective CFs. It is that assumption that got us into both CASSANDRA-6418 and
CASSANDRA-6821, and now this ticket as well. Most of the code that handles
snapshots is in instance methods of Directories.java, which is instantiated
with CFMetatadata, and ultimately StorageService is accessing information
through them from the ColumnFamilyStore... which won't exist for dropped tables.
For trunk I think we should probably refactor snapshot handling altogether to
dissolve the marriage between CFs and snapshots a bit, but for existing
versions I'm not sure what the least invasive way of reworking this is yet.
> auto-snapshots for dropped tables don't appear in nodetool listsnapshots
>
>
> Key: CASSANDRA-16843
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16843
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: James Brown
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> Auto snapshots from dropped tables don't seem to show up in {{nodetool
> listsnapshots}} (even though they do get cleared by {{nodetool
> clearsnapshot}}). This makes them kind of annoying to clean up, since you
> need to muck about in the data directory to find them.
> Erick on the mailing list said that this seems to be an oversight and that
> clearsnapshot was fixed by
> [CASSANDRA-6418|https://issues.apache.org/jira/browse/CASSANDRA-6418].
> I reproduced this both on 3.11.11 and 4.0.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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400395#comment-17400395 ] Brandon Williams commented on CASSANDRA-16855: -- It looks like there are still some json-simple references in tools/stress. > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16855: - Status: Open (was: Patch Available) > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400379#comment-17400379 ] Brandon Williams edited comment on CASSANDRA-16855 at 8/17/21, 1:30 PM: [Circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-16855] and [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1031/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1031/pipeline] was (Author: brandon.williams): [Circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-16855] and [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1030/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1030/pipeline] > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-14344) Support filtering using IN restrictions
[
https://issues.apache.org/jira/browse/CASSANDRA-14344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14344:
---
Status: Review In Progress (was: Patch Available)
> Support filtering using IN restrictions
> ---
>
> Key: CASSANDRA-14344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14344
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/CQL
>Reporter: Dikang Gu
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 14344-trunk-2.txt, 14344-trunk-3.patch,
> 14344-trunk-inexpression-approach-2.txt,
> 14344-trunk-inexpression-approach.txt, 14344-trunk.txt
>
>
> Support IN filter query like this:
>
> CREATE TABLE ks1.t1 (
> key int,
> col1 int,
> col2 int,
> value int,
> PRIMARY KEY (key, col1, col2)
> ) WITH CLUSTERING ORDER BY (col1 ASC, col2 ASC)
>
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1) allow filtering;
>
> key | col1 | col2 | value
> -+++---
> 1 | 1 | 1 | 1
> 1 | 2 | 1 | 3
>
> (2 rows)
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1, 2) allow filtering;
> *{color:#ff}InvalidRequest: Error from server: code=2200 [Invalid query]
> message="IN restrictions are not supported on indexed columns"{color}*
> cqlsh:ks1>
--
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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400379#comment-17400379 ] Brandon Williams commented on CASSANDRA-16855: -- [Circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-16855] and [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1030/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1030/pipeline] > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.1, 5.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16855: - Fix Version/s: (was: 4.1) (was: 5.x) 4.x > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16858) CircleCI MIDRES might be missing some changes in 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-16858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16858:
Status: Ready to Commit (was: Review In Progress)
> CircleCI MIDRES might be missing some changes in 3.11
> -
>
> Key: CASSANDRA-16858
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16858
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.11.x
>
>
> I've noticed that when we run {{.circleci/generate.sh}} in 3.11 the file
> {{config.yml.MIDRES}} is modified, when I'd say it shouldn't be changed. If
> I'm right running that script should be noop when there hasn't been changes
> in {{config-2_1.yml}}, and indeed the file isn't modified in the other
> branches.
> Not sure yet, but I think that this might be the result of not having
> generated a new {{config.yml.MIDRES}} with the script when merging 3.0 into
> 3.11 during CASSANDRA-16804.
--
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-16858) CircleCI MIDRES might be missing some changes in 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-16858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400377#comment-17400377
]
Ekaterina Dimitrova commented on CASSANDRA-16858:
-
I just pushed a Circle CI run with the regenerated file. It seems things are
[going
well|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1080/workflows/11fe255f-1ff1-4959-baf9-1e57ca546c6e]
and I think we are more than ready to commit. Thank you!
> CircleCI MIDRES might be missing some changes in 3.11
> -
>
> Key: CASSANDRA-16858
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16858
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.11.x
>
>
> I've noticed that when we run {{.circleci/generate.sh}} in 3.11 the file
> {{config.yml.MIDRES}} is modified, when I'd say it shouldn't be changed. If
> I'm right running that script should be noop when there hasn't been changes
> in {{config-2_1.yml}}, and indeed the file isn't modified in the other
> branches.
> Not sure yet, but I think that this might be the result of not having
> generated a new {{config.yml.MIDRES}} with the script when merging 3.0 into
> 3.11 during CASSANDRA-16804.
--
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-16203) Rack Aware Topology Strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-16203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16203: -- Fix Version/s: (was: 5.x) 4.x > Rack Aware Topology Strategy > > > Key: CASSANDRA-16203 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16203 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership >Reporter: Cameron Zemek >Assignee: Cameron Zemek >Priority: Normal > Fix For: 4.x > > Attachments: rackaware.patch > > > If replication factor > racks then NetworkTopologyStrategy assigns the extras > in ring order. This means losing a rack can result in the loss of quorum. I > have implemented a similar topology strategy that evenly distributes replicas > across racks. -- 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-16203) Rack Aware Topology Strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-16203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400376#comment-17400376 ] Stefan Miklosovic commented on CASSANDRA-16203: --- Yeah I am of same opinion, it might go just right now imho. I ll try to make a progress here. Thanks. > Rack Aware Topology Strategy > > > Key: CASSANDRA-16203 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16203 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership >Reporter: Cameron Zemek >Assignee: Cameron Zemek >Priority: Normal > Fix For: 5.x > > Attachments: rackaware.patch > > > If replication factor > racks then NetworkTopologyStrategy assigns the extras > in ring order. This means losing a rack can result in the loss of quorum. I > have implemented a similar topology strategy that evenly distributes replicas > across racks. -- 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-16860) Add Snapshot Expiry via TTL to NodeTool
[
https://issues.apache.org/jira/browse/CASSANDRA-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-16860:
Reviewers: Paulo Motta
> Add Snapshot Expiry via TTL to NodeTool
> ---
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Jack Casey
>Assignee: Jack Casey
>Priority: Normal
> Fix For: 4.x
>
>
> h1. Summary
> Opening this issue in reference to [this WIP
> PR|https://github.com/apache/cassandra/pull/1148]:
> This functionality allows users of Cassandra to remove snapshots ad-hoc,
> based on a TTL. This is to address the problem of snapshots accumulating. For
> example, an organization I work for aims to keep snapshots for 30 days,
> however we don't have any way to easily clean them after those 30 days are up.
> This is similar to the goals set in:
> https://issues.apache.org/jira/browse/CASSANDRA-16451 however would be
> available for Cassandra 3.x.
> h1. Functionality
> This adds a new command to NodeTool, called {{expiresnapshot}} with the
> following options:
> NAME
> nodetool expiresnapshots - Removes snapshots that are older than a TTL
> in days
> SYNOPSIS
> nodetool [(-h | --host )] [(-p | --port )]
> [(-pw | --password )]
> [(-pwf | --password-file )]
> [(-u | --username )] expiresnapshots [--dry-run]
> (-t | --ttl )
> OPTIONS
> --dry-run
> Run without actually clearing snapshots
> -h , --host
> Node hostname or ip address
> -p , --port
> Remote jmx agent port number
> -pw , --password
> Remote jmx agent password
> -pwf , --password-file
> Path to the JMX password file
> -t , --ttl
> TTL (in days) to expire snapshots
> -u , --username
> Remote jmx agent username
> The snapshot date is taken by converting the default snapshot name timestamps
> (epoch time in miliseconds). For this reason, snapshot names that don't
> contain a timestamp in this format will not be cleared.
> h1. Example Use
> This Cassandra environment has a number of snapshots, a few are recent, and a
> few outdated:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1529173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1599173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.77 MiB
> To validate the removal runs as expected, we can use the `--dry-run` option:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30 --dry-run
> Starting simulated cleanup of snapshots older than 30 days
> Clearing (dry run): 1529173922063
> Clearing (dry run): 1599173922063
> Cleared (dry run): 2 snapshots
> Now that we are confident the correct snapshots will be removed, we can omit
> the {{--dry-run}} flag:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30
> Starting cleanup of snapshots older than 30 days
> Clearing: 1529173922063
> Clearing: 1599173922063
> Cleared: 2 snapshots
> To confirm our changes are successful, we list the snapshots that still
> remain:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.06 MiB
> h1. Next Steps
> To be completed:
> - Tests
> - Documentation updates
> I am a new to this repository, and am fuzzy on a few details even after
> reading the contribution guide Any advice on the following would be greatly
> appreciated!
> - What branch would this type of change be merged into? Currently, I'm
> targeting {{apache:trunk}} by default
> - Is there a test strategy/pattern for this type of change? I was not able
> to find any existing tests for similar {{nodetool}} commands
> Thanks!
--
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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16855: - Reviewers: Brandon Williams > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.1, 5.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16855) Replace minor use of `json-simple` with Jackson
[ https://issues.apache.org/jira/browse/CASSANDRA-16855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16855: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > Replace minor use of `json-simple` with Jackson > --- > > Key: CASSANDRA-16855 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16855 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies, Local/Other, Tool/nodetool >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Labels: pull-request-available > Fix For: 4.1, 5.x > > > Jackson library is used for most JSON reading/writing, but there are couple > of places where older "json-simple" library is used, mostly for diagnostics > output. Replacing those minor usages would allow removal of a dependency, one > for which the last release was made in 2012. > Places where json-simple is used are: > * src/java/org/apache/cassandra/db/ColumnFamilyStore.java > * src/java/org/apache/cassandra/db/commitlog/CommitLogDescriptor.java > * src/java/org/apache/cassandra/hints/HintsDescriptor.java > * src/java/org/apache/cassandra/tools/nodetool/stats/StatsPrinter.java > (and some matching usage in couple of test classes) > I can take a stab at replacing these uses; it also looks like test coverage > may be spotty for some (StatsPrinter json/yaml part has no tests for example). > It is probably best to target this for "trunk" (4.1?). > -- 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-16860) Add Snapshot Expiry via TTL to NodeTool
[
https://issues.apache.org/jira/browse/CASSANDRA-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16860:
-
Test and Documentation Plan: add tests
Status: Patch Available (was: Open)
> Add Snapshot Expiry via TTL to NodeTool
> ---
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Jack Casey
>Assignee: Jack Casey
>Priority: Normal
> Fix For: 4.x
>
>
> h1. Summary
> Opening this issue in reference to [this WIP
> PR|https://github.com/apache/cassandra/pull/1148]:
> This functionality allows users of Cassandra to remove snapshots ad-hoc,
> based on a TTL. This is to address the problem of snapshots accumulating. For
> example, an organization I work for aims to keep snapshots for 30 days,
> however we don't have any way to easily clean them after those 30 days are up.
> This is similar to the goals set in:
> https://issues.apache.org/jira/browse/CASSANDRA-16451 however would be
> available for Cassandra 3.x.
> h1. Functionality
> This adds a new command to NodeTool, called {{expiresnapshot}} with the
> following options:
> NAME
> nodetool expiresnapshots - Removes snapshots that are older than a TTL
> in days
> SYNOPSIS
> nodetool [(-h | --host )] [(-p | --port )]
> [(-pw | --password )]
> [(-pwf | --password-file )]
> [(-u | --username )] expiresnapshots [--dry-run]
> (-t | --ttl )
> OPTIONS
> --dry-run
> Run without actually clearing snapshots
> -h , --host
> Node hostname or ip address
> -p , --port
> Remote jmx agent port number
> -pw , --password
> Remote jmx agent password
> -pwf , --password-file
> Path to the JMX password file
> -t , --ttl
> TTL (in days) to expire snapshots
> -u , --username
> Remote jmx agent username
> The snapshot date is taken by converting the default snapshot name timestamps
> (epoch time in miliseconds). For this reason, snapshot names that don't
> contain a timestamp in this format will not be cleared.
> h1. Example Use
> This Cassandra environment has a number of snapshots, a few are recent, and a
> few outdated:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1529173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1599173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.77 MiB
> To validate the removal runs as expected, we can use the `--dry-run` option:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30 --dry-run
> Starting simulated cleanup of snapshots older than 30 days
> Clearing (dry run): 1529173922063
> Clearing (dry run): 1599173922063
> Cleared (dry run): 2 snapshots
> Now that we are confident the correct snapshots will be removed, we can omit
> the {{--dry-run}} flag:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30
> Starting cleanup of snapshots older than 30 days
> Clearing: 1529173922063
> Clearing: 1599173922063
> Cleared: 2 snapshots
> To confirm our changes are successful, we list the snapshots that still
> remain:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.06 MiB
> h1. Next Steps
> To be completed:
> - Tests
> - Documentation updates
> I am a new to this repository, and am fuzzy on a few details even after
> reading the contribution guide Any advice on the following would be greatly
> appreciated!
> - What branch would this type of change be merged into? Currently, I'm
> targeting {{apache:trunk}} by default
> - Is there a test strategy/pattern for this type of change? I was not able
> to find any existing tests for similar {{nodetool}} commands
> Thanks!
--
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-16860) Add Snapshot Expiry via TTL to NodeTool
[
https://issues.apache.org/jira/browse/CASSANDRA-16860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16860:
-
Change Category: Operability
Complexity: Normal
Fix Version/s: 4.x
Assignee: Jack Casey
Status: Open (was: Triage Needed)
> Add Snapshot Expiry via TTL to NodeTool
> ---
>
> Key: CASSANDRA-16860
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16860
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/nodetool
>Reporter: Jack Casey
>Assignee: Jack Casey
>Priority: Normal
> Fix For: 4.x
>
>
> h1. Summary
> Opening this issue in reference to [this WIP
> PR|https://github.com/apache/cassandra/pull/1148]:
> This functionality allows users of Cassandra to remove snapshots ad-hoc,
> based on a TTL. This is to address the problem of snapshots accumulating. For
> example, an organization I work for aims to keep snapshots for 30 days,
> however we don't have any way to easily clean them after those 30 days are up.
> This is similar to the goals set in:
> https://issues.apache.org/jira/browse/CASSANDRA-16451 however would be
> available for Cassandra 3.x.
> h1. Functionality
> This adds a new command to NodeTool, called {{expiresnapshot}} with the
> following options:
> NAME
> nodetool expiresnapshots - Removes snapshots that are older than a TTL
> in days
> SYNOPSIS
> nodetool [(-h | --host )] [(-p | --port )]
> [(-pw | --password )]
> [(-pwf | --password-file )]
> [(-u | --username )] expiresnapshots [--dry-run]
> (-t | --ttl )
> OPTIONS
> --dry-run
> Run without actually clearing snapshots
> -h , --host
> Node hostname or ip address
> -p , --port
> Remote jmx agent port number
> -pw , --password
> Remote jmx agent password
> -pwf , --password-file
> Path to the JMX password file
> -t , --ttl
> TTL (in days) to expire snapshots
> -u , --username
> Remote jmx agent username
> The snapshot date is taken by converting the default snapshot name timestamps
> (epoch time in miliseconds). For this reason, snapshot names that don't
> contain a timestamp in this format will not be cleared.
> h1. Example Use
> This Cassandra environment has a number of snapshots, a few are recent, and a
> few outdated:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1529173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1599173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.77 MiB
> To validate the removal runs as expected, we can use the `--dry-run` option:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30 --dry-run
> Starting simulated cleanup of snapshots older than 30 days
> Clearing (dry run): 1529173922063
> Clearing (dry run): 1599173922063
> Cleared (dry run): 2 snapshots
> Now that we are confident the correct snapshots will be removed, we can omit
> the {{--dry-run}} flag:
> root@cassandra001:/cassandra# nodetool expiresnapshots --ttl 30
> Starting cleanup of snapshots older than 30 days
> Clearing: 1529173922063
> Clearing: 1599173922063
> Cleared: 2 snapshots
> To confirm our changes are successful, we list the snapshots that still
> remain:
> root@cassandra001:/cassandra# nodetool listsnapshots
> Snapshot Details:
> Snapshot name Keyspace name Column family name True size Size on disk
> 1629173909461 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173922063 users_keyspace users 362.03 KiB 362.89 KiB
> 1629173916816 users_keyspace users 362.03 KiB 362.89 KiB
> Total TrueDiskSpaceUsed: 1.06 MiB
> h1. Next Steps
> To be completed:
> - Tests
> - Documentation updates
> I am a new to this repository, and am fuzzy on a few details even after
> reading the contribution guide Any advice on the following would be greatly
> appreciated!
> - What branch would this type of change be merged into? Currently, I'm
> targeting {{apache:trunk}} by default
> - Is there a test strategy/pattern for this type of change? I was not able
> to find any existing tests for similar {{nodetool}} commands
> Thanks!
--
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-16203) Rack Aware Topology Strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-16203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400360#comment-17400360 ] Brandon Williams edited comment on CASSANDRA-16203 at 8/17/21, 12:37 PM: - Well, again since strategies are pluggable, I don't think it really matters. Nobody loses anything or takes on any risk regardless of where this gets merged, unless they choose to use it. I think of this as analogous to another compaction strategy. was (Author: brandon.williams): Well, again since strategies are pluggable, I don't think it really matters. Nobody loses anything or takes on any risk regardless of where this gets merged, unless they choose to use it. > Rack Aware Topology Strategy > > > Key: CASSANDRA-16203 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16203 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership >Reporter: Cameron Zemek >Assignee: Cameron Zemek >Priority: Normal > Fix For: 5.x > > Attachments: rackaware.patch > > > If replication factor > racks then NetworkTopologyStrategy assigns the extras > in ring order. This means losing a rack can result in the loss of quorum. I > have implemented a similar topology strategy that evenly distributes replicas > across racks. -- 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-16203) Rack Aware Topology Strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-16203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400360#comment-17400360 ] Brandon Williams commented on CASSANDRA-16203: -- Well, again since strategies are pluggable, I don't think it really matters. Nobody loses anything or takes on any risk regardless of where this gets merged, unless they choose to use it. > Rack Aware Topology Strategy > > > Key: CASSANDRA-16203 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16203 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership >Reporter: Cameron Zemek >Assignee: Cameron Zemek >Priority: Normal > Fix For: 5.x > > Attachments: rackaware.patch > > > If replication factor > racks then NetworkTopologyStrategy assigns the extras > in ring order. This means losing a rack can result in the loss of quorum. I > have implemented a similar topology strategy that evenly distributes replicas > across racks. -- 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-14557) Consider adding default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400359#comment-17400359
]
Brandon Williams commented on CASSANDRA-14557:
--
bq. inability to change it without restarting a node seems to be quite much to
demand.
JMX will allow it to be changed, but I think having to poke every node is also
going to be cumbersome and error prone.
> Consider adding default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
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-16858) CircleCI MIDRES might be missing some changes in 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-16858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16858:
--
Reviewers: Ekaterina Dimitrova (was: Andres de la Peña, Ekaterina
Dimitrova)
> CircleCI MIDRES might be missing some changes in 3.11
> -
>
> Key: CASSANDRA-16858
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16858
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.11.x
>
>
> I've noticed that when we run {{.circleci/generate.sh}} in 3.11 the file
> {{config.yml.MIDRES}} is modified, when I'd say it shouldn't be changed. If
> I'm right running that script should be noop when there hasn't been changes
> in {{config-2_1.yml}}, and indeed the file isn't modified in the other
> branches.
> Not sure yet, but I think that this might be the result of not having
> generated a new {{config.yml.MIDRES}} with the script when merging 3.0 into
> 3.11 during CASSANDRA-16804.
--
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-16858) CircleCI MIDRES might be missing some changes in 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-16858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400339#comment-17400339
]
Andres de la Peña commented on CASSANDRA-16858:
---
Thanks for checking this. I assume we are ready to commit, or do you want to
test anything else?
> CircleCI MIDRES might be missing some changes in 3.11
> -
>
> Key: CASSANDRA-16858
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16858
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.11.x
>
>
> I've noticed that when we run {{.circleci/generate.sh}} in 3.11 the file
> {{config.yml.MIDRES}} is modified, when I'd say it shouldn't be changed. If
> I'm right running that script should be noop when there hasn't been changes
> in {{config-2_1.yml}}, and indeed the file isn't modified in the other
> branches.
> Not sure yet, but I think that this might be the result of not having
> generated a new {{config.yml.MIDRES}} with the script when merging 3.0 into
> 3.11 during CASSANDRA-16804.
--
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-16858) CircleCI MIDRES might be missing some changes in 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-16858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16858:
--
Status: Patch Available (was: In Progress)
> CircleCI MIDRES might be missing some changes in 3.11
> -
>
> Key: CASSANDRA-16858
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16858
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.11.x
>
>
> I've noticed that when we run {{.circleci/generate.sh}} in 3.11 the file
> {{config.yml.MIDRES}} is modified, when I'd say it shouldn't be changed. If
> I'm right running that script should be noop when there hasn't been changes
> in {{config-2_1.yml}}, and indeed the file isn't modified in the other
> branches.
> Not sure yet, but I think that this might be the result of not having
> generated a new {{config.yml.MIDRES}} with the script when merging 3.0 into
> 3.11 during CASSANDRA-16804.
--
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-16858) CircleCI MIDRES might be missing some changes in 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-16858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16858:
--
Reviewers: Ekaterina Dimitrova, Andres de la Peña (was: Andres de la Peña,
Ekaterina Dimitrova)
Ekaterina Dimitrova, Andres de la Peña (was: Ekaterina
Dimitrova)
Status: Review In Progress (was: Patch Available)
> CircleCI MIDRES might be missing some changes in 3.11
> -
>
> Key: CASSANDRA-16858
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16858
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.11.x
>
>
> I've noticed that when we run {{.circleci/generate.sh}} in 3.11 the file
> {{config.yml.MIDRES}} is modified, when I'd say it shouldn't be changed. If
> I'm right running that script should be noop when there hasn't been changes
> in {{config-2_1.yml}}, and indeed the file isn't modified in the other
> branches.
> Not sure yet, but I think that this might be the result of not having
> generated a new {{config.yml.MIDRES}} with the script when merging 3.0 into
> 3.11 during CASSANDRA-16804.
--
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-16858) CircleCI MIDRES might be missing some changes in 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-16858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16858:
--
Status: In Progress (was: Patch Available)
> CircleCI MIDRES might be missing some changes in 3.11
> -
>
> Key: CASSANDRA-16858
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16858
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.11.x
>
>
> I've noticed that when we run {{.circleci/generate.sh}} in 3.11 the file
> {{config.yml.MIDRES}} is modified, when I'd say it shouldn't be changed. If
> I'm right running that script should be noop when there hasn't been changes
> in {{config-2_1.yml}}, and indeed the file isn't modified in the other
> branches.
> Not sure yet, but I think that this might be the result of not having
> generated a new {{config.yml.MIDRES}} with the script when merging 3.0 into
> 3.11 during CASSANDRA-16804.
--
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-16858) CircleCI MIDRES might be missing some changes in 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-16858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16858:
--
Test and Documentation Plan: Running {{.circleci/generate.sh}} should not
modify any file, and CircleCI should pass with MIDRES using the expected
resources.
Status: Patch Available (was: Open)
> CircleCI MIDRES might be missing some changes in 3.11
> -
>
> Key: CASSANDRA-16858
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16858
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.11.x
>
>
> I've noticed that when we run {{.circleci/generate.sh}} in 3.11 the file
> {{config.yml.MIDRES}} is modified, when I'd say it shouldn't be changed. If
> I'm right running that script should be noop when there hasn't been changes
> in {{config-2_1.yml}}, and indeed the file isn't modified in the other
> branches.
> Not sure yet, but I think that this might be the result of not having
> generated a new {{config.yml.MIDRES}} with the script when merging 3.0 into
> 3.11 during CASSANDRA-16804.
--
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-14309) Make hint window persistent across restarts
[
https://issues.apache.org/jira/browse/CASSANDRA-14309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-14309:
--
Status: In Progress (was: Changes Suggested)
> Make hint window persistent across restarts
> ---
>
> Key: CASSANDRA-14309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14309
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Hints
>Reporter: Kurt Greaves
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
>
> The current hint system stores a window of hints as defined by
> {{max_hint_window_in_ms}}, however this window is not persistent across
> restarts.
> Examples (cluster with RF=3 and 3 nodes, A, B, and C):
> # A goes down
> # X ms of hints are stored for A on B and C
> # A is restarted
> # A goes down again without hints replaying from B and C
> # B and C will store up to another {{max_hint_window_in_ms}} of hints for A
>
> # A goes down
> # X ms of hints are stored for A on B and C
> # B is restarted
> # B will store up to another {{max_hint_window_in_ms}} of hints for A
>
> Note that in both these scenarios they can continue forever. If A or B keeps
> getting restarted hints will continue to pile up.
>
> Idea of this ticket is to stop this behaviour from happening and only ever
> store up to {{max_hint_window_in_ms}} of hints for a particular node.
--
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-14309) Make hint window persistent across restarts
[
https://issues.apache.org/jira/browse/CASSANDRA-14309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400337#comment-17400337
]
Stefan Miklosovic commented on CASSANDRA-14309:
---
I ll take over and I ll make it optional.
> Make hint window persistent across restarts
> ---
>
> Key: CASSANDRA-14309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14309
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Hints
>Reporter: Kurt Greaves
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
>
> The current hint system stores a window of hints as defined by
> {{max_hint_window_in_ms}}, however this window is not persistent across
> restarts.
> Examples (cluster with RF=3 and 3 nodes, A, B, and C):
> # A goes down
> # X ms of hints are stored for A on B and C
> # A is restarted
> # A goes down again without hints replaying from B and C
> # B and C will store up to another {{max_hint_window_in_ms}} of hints for A
>
> # A goes down
> # X ms of hints are stored for A on B and C
> # B is restarted
> # B will store up to another {{max_hint_window_in_ms}} of hints for A
>
> Note that in both these scenarios they can continue forever. If A or B keeps
> getting restarted hints will continue to pile up.
>
> Idea of this ticket is to stop this behaviour from happening and only ever
> store up to {{max_hint_window_in_ms}} of hints for a particular node.
--
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-14309) Make hint window persistent across restarts
[
https://issues.apache.org/jira/browse/CASSANDRA-14309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic reassigned CASSANDRA-14309:
-
Assignee: Stefan Miklosovic (was: Kurt Greaves)
> Make hint window persistent across restarts
> ---
>
> Key: CASSANDRA-14309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14309
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Hints
>Reporter: Kurt Greaves
>Assignee: Stefan Miklosovic
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
>
> The current hint system stores a window of hints as defined by
> {{max_hint_window_in_ms}}, however this window is not persistent across
> restarts.
> Examples (cluster with RF=3 and 3 nodes, A, B, and C):
> # A goes down
> # X ms of hints are stored for A on B and C
> # A is restarted
> # A goes down again without hints replaying from B and C
> # B and C will store up to another {{max_hint_window_in_ms}} of hints for A
>
> # A goes down
> # X ms of hints are stored for A on B and C
> # B is restarted
> # B will store up to another {{max_hint_window_in_ms}} of hints for A
>
> Note that in both these scenarios they can continue forever. If A or B keeps
> getting restarted hints will continue to pile up.
>
> Idea of this ticket is to stop this behaviour from happening and only ever
> store up to {{max_hint_window_in_ms}} of hints for a particular node.
--
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-15134) SASI index files not included in snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-15134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-15134:
--
Fix Version/s: 4.x
4.0.x
3.11.x
> SASI index files not included in snapshots
> --
>
> Key: CASSANDRA-15134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15134
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Vincent White
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
>
> Newly written SASI index files are not being included in snapshots. This is
> because the SASI index files are not added to the components
> ({{org.apache.cassandra.io.sstable.SSTable#components}}) list of newly
> written sstables.
> Although I don't believe anything except snapshots ever tries to reference
> the SASI index files from this location, on startup Cassandra does add the
> SASI index files (if they are found on disk) of existing sstables in their
> components list. In that case sstables that existed on startup with SASI
> index files will have their SASI index files included in any snapshots.
>
> This patch updates the components list of newly written sstable once the
> index is built.
> ||3.11||4.0||Trunk||
> |[https://github.com/apache/cassandra/pull/1150]|[TBD]|[TBD]|
>
--
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-15134) SASI index files not included in snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-15134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-15134:
--
Description:
Newly written SASI index files are not being included in snapshots. This is
because the SASI index files are not added to the components
({{org.apache.cassandra.io.sstable.SSTable#components}}) list of newly written
sstables.
Although I don't believe anything except snapshots ever tries to reference the
SASI index files from this location, on startup Cassandra does add the SASI
index files (if they are found on disk) of existing sstables in their
components list. In that case sstables that existed on startup with SASI index
files will have their SASI index files included in any snapshots.
This patch updates the components list of newly written sstable once the index
is built.
||3.11||4.0||Trunk||
|[https://github.com/apache/cassandra/pull/1150]|[TBD]|[TBD]|
was:
Newly written SASI index files are not being included in snapshots. This is
because the SASI index files are not added to the components
({{org.apache.cassandra.io.sstable.SSTable#components}}) list of newly written
sstables.
Although I don't believe anything except snapshots ever tries to reference the
SASI index files from this location, on startup Cassandra does add the SASI
index files (if they are found on disk) of existing sstables in their
components list. In that case sstables that existed on startup with SASI index
files will have their SASI index files included in any snapshots.
This patch updates the components list of newly written sstable once the index
is built.
||3.11||Trunk||
|[PoC|https://github.com/vincewhite/cassandra/commit/a641298ad03250d3e4c195e05a93aad56dff8ca7]|[PoC|https://github.com/vincewhite/cassandra/commit/1cfe46688380838e7106f14446658988cfe68137]|
> SASI index files not included in snapshots
> --
>
> Key: CASSANDRA-15134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15134
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Vincent White
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> Newly written SASI index files are not being included in snapshots. This is
> because the SASI index files are not added to the components
> ({{org.apache.cassandra.io.sstable.SSTable#components}}) list of newly
> written sstables.
> Although I don't believe anything except snapshots ever tries to reference
> the SASI index files from this location, on startup Cassandra does add the
> SASI index files (if they are found on disk) of existing sstables in their
> components list. In that case sstables that existed on startup with SASI
> index files will have their SASI index files included in any snapshots.
>
> This patch updates the components list of newly written sstable once the
> index is built.
> ||3.11||4.0||Trunk||
> |[https://github.com/apache/cassandra/pull/1150]|[TBD]|[TBD]|
>
--
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-15134) SASI index files not included in snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-15134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400334#comment-17400334
]
Stefan Miklosovic commented on CASSANDRA-15134:
---
[~adelapena] would you mind to take a look here too?
maybe [~ifesdjeen] or [~xedin] might look at this too as they were touching
DataTracker mostly.
> SASI index files not included in snapshots
> --
>
> Key: CASSANDRA-15134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15134
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Vincent White
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> Newly written SASI index files are not being included in snapshots. This is
> because the SASI index files are not added to the components
> ({{org.apache.cassandra.io.sstable.SSTable#components}}) list of newly
> written sstables.
> Although I don't believe anything except snapshots ever tries to reference
> the SASI index files from this location, on startup Cassandra does add the
> SASI index files (if they are found on disk) of existing sstables in their
> components list. In that case sstables that existed on startup with SASI
> index files will have their SASI index files included in any snapshots.
>
> This patch updates the components list of newly written sstable once the
> index is built.
> ||3.11||Trunk||
> |[PoC|https://github.com/vincewhite/cassandra/commit/a641298ad03250d3e4c195e05a93aad56dff8ca7]|[PoC|https://github.com/vincewhite/cassandra/commit/1cfe46688380838e7106f14446658988cfe68137]|
>
--
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-15134) SASI index files not included in snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-15134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-15134:
--
Test and Documentation Plan: unit test
Status: Patch Available (was: In Progress)
https://github.com/apache/cassandra/pull/1150
> SASI index files not included in snapshots
> --
>
> Key: CASSANDRA-15134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15134
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Vincent White
>Assignee: Stefan Miklosovic
>Priority: Normal
>
> Newly written SASI index files are not being included in snapshots. This is
> because the SASI index files are not added to the components
> ({{org.apache.cassandra.io.sstable.SSTable#components}}) list of newly
> written sstables.
> Although I don't believe anything except snapshots ever tries to reference
> the SASI index files from this location, on startup Cassandra does add the
> SASI index files (if they are found on disk) of existing sstables in their
> components list. In that case sstables that existed on startup with SASI
> index files will have their SASI index files included in any snapshots.
>
> This patch updates the components list of newly written sstable once the
> index is built.
> ||3.11||Trunk||
> |[PoC|https://github.com/vincewhite/cassandra/commit/a641298ad03250d3e4c195e05a93aad56dff8ca7]|[PoC|https://github.com/vincewhite/cassandra/commit/1cfe46688380838e7106f14446658988cfe68137]|
>
--
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-16189) Add tests for the Hint service metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-16189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400325#comment-17400325 ] Benjamin Lerer commented on CASSANDRA-16189: +1 > Add tests for the Hint service metrics > -- > > Key: CASSANDRA-16189 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16189 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Benjamin Lerer >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.0.x > > Attachments: 0001-added-hints-metrics-test.patch > > Time Spent: 10m > Remaining Estimate: 0h > > There are currently no tests for the hint metrics -- 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-11881) OOM upgrading 2.2 to 3.6-tentative
[
https://issues.apache.org/jira/browse/CASSANDRA-11881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-11881:
---
Resolution: Cannot Reproduce
Status: Resolved (was: Awaiting Feedback)
> OOM upgrading 2.2 to 3.6-tentative
> --
>
> Key: CASSANDRA-11881
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11881
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Testing
>Reporter: Russ Hatch
>Assignee: Russ Hatch
>Priority: Normal
>
> This has been repro'd a few times while running tests, such as
> upgrade_tests/upgrade_through_versions_test.py:TestUpgrade_current_2_2_x_To_next_3_x.rolling_upgrade_test
> {noformat}
> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> java.lang.OutOfMemoryError: Java heap space
> at
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:119)
> ~[main/:na]
> at
> org.apache.cassandra.hints.LegacyHintsMigrator.compactLegacyHints(LegacyHintsMigrator.java:108)
> ~[main/:na]
> at
> org.apache.cassandra.hints.LegacyHintsMigrator.migrate(LegacyHintsMigrator.java:92)
> ~[main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:321)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:581)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:710)
> [main/:na]
> Caused by: java.util.concurrent.ExecutionException:
> java.lang.OutOfMemoryError: Java heap space
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> ~[na:1.8.0_92]
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> ~[na:1.8.0_92]
> at
> org.apache.cassandra.hints.LegacyHintsMigrator.forceCompaction(LegacyHintsMigrator.java:115)
> ~[main/:na]
> ... 5 common frames omitted
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at
> org.apache.cassandra.db.RowIndexEntry$LegacyShallowIndexedEntry.deserialize(RowIndexEntry.java:519)
> ~[main/:na]
> at
> org.apache.cassandra.db.RowIndexEntry$Serializer.deserialize(RowIndexEntry.java:321)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:310)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableScanner$KeyScanningIterator.computeNext(BigTableScanner.java:265)
> ~[main/:na]
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.big.BigTableScanner.hasNext(BigTableScanner.java:245)
> ~[main/:na]
> at
> org.apache.cassandra.utils.MergeIterator$OneToOne.computeNext(MergeIterator.java:463)
> ~[main/:na]
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> ~[main/:na]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$2.hasNext(UnfilteredPartitionIterators.java:150)
> ~[main/:na]
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:72)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:226)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:182)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:82)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:60)
> ~[main/:na]
> at
> org.apache.cassandra.db.compaction.CompactionManager$10.runMayThrow(CompactionManager.java:805)
> ~[main/:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[main/:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_92]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_92]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_92]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> ~[na:1.8.0_92]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_92]
> ERROR [CompactionExecutor:3] 2016-05-23 14:34:25,066 CassandraDaemon.java:213
> - Exception in thread Thread[CompactionExecutor:3,1,main]
> java.lang.OutOfMemoryError: Java heap space
> at
> org.apache.cassandra.db.RowIndexEntry$LegacyShallowIndexedEntry.deserialize(RowIndexEntry.java:519)
>
[jira] [Updated] (CASSANDRA-14644) CircleCI Builds should optional run in-tree tests other than test/unit
[ https://issues.apache.org/jira/browse/CASSANDRA-14644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-14644: --- Resolution: Cannot Reproduce Status: Resolved (was: Open) > CircleCI Builds should optional run in-tree tests other than test/unit > -- > > Key: CASSANDRA-14644 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14644 > Project: Cassandra > Issue Type: Bug > Components: CI, Legacy/Testing >Reporter: Jordan West >Assignee: Benjamin Lerer >Priority: Urgent > Labels: CI > > Currently, circleci is hardcoded to search for tests in the test/unit > directory only: > https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L166. > This means tests under `test-compression` and `test-long` are not run. Like > dtests, there should be a simple way to modify the config to run these as > well. -- 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-14644) CircleCI Builds should optional run in-tree tests other than test/unit
[ https://issues.apache.org/jira/browse/CASSANDRA-14644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer reassigned CASSANDRA-14644: -- Assignee: Vinay Chella (was: Benjamin Lerer) > CircleCI Builds should optional run in-tree tests other than test/unit > -- > > Key: CASSANDRA-14644 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14644 > Project: Cassandra > Issue Type: Bug > Components: CI, Legacy/Testing >Reporter: Jordan West >Assignee: Vinay Chella >Priority: Urgent > Labels: CI > > Currently, circleci is hardcoded to search for tests in the test/unit > directory only: > https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L166. > This means tests under `test-compression` and `test-long` are not run. Like > dtests, there should be a simple way to modify the config to run these as > well. -- 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-14644) CircleCI Builds should optional run in-tree tests other than test/unit
[ https://issues.apache.org/jira/browse/CASSANDRA-14644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer reassigned CASSANDRA-14644: -- Assignee: Benjamin Lerer (was: Vinay Chella) > CircleCI Builds should optional run in-tree tests other than test/unit > -- > > Key: CASSANDRA-14644 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14644 > Project: Cassandra > Issue Type: Bug > Components: CI, Legacy/Testing >Reporter: Jordan West >Assignee: Benjamin Lerer >Priority: Urgent > Labels: CI > > Currently, circleci is hardcoded to search for tests in the test/unit > directory only: > https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L166. > This means tests under `test-compression` and `test-long` are not run. Like > dtests, there should be a simple way to modify the config to run these as > well. -- 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-14644) CircleCI Builds should optional run in-tree tests other than test/unit
[ https://issues.apache.org/jira/browse/CASSANDRA-14644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400318#comment-17400318 ] Benjamin Lerer commented on CASSANDRA-14644: Closing the ticket. Feel free to reopen it if it is still needed. > CircleCI Builds should optional run in-tree tests other than test/unit > -- > > Key: CASSANDRA-14644 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14644 > Project: Cassandra > Issue Type: Bug > Components: CI, Legacy/Testing >Reporter: Jordan West >Assignee: Vinay Chella >Priority: Urgent > Labels: CI > > Currently, circleci is hardcoded to search for tests in the test/unit > directory only: > https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L166. > This means tests under `test-compression` and `test-long` are not run. Like > dtests, there should be a simple way to modify the config to run these as > well. -- 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
