[jira] [Updated] (CASSANDRA-17214) Cannot restart a node when there are other nodes being down in in-jvm dtest framework
[
https://issues.apache.org/jira/browse/CASSANDRA-17214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-17214:
--
Bug Category: Parent values: Code(13163)
Complexity: Low Hanging Fruit
Discovered By: User Report
Severity: Low
Status: Open (was: Triage Needed)
> Cannot restart a node when there are other nodes being down in in-jvm dtest
> framework
> -
>
> Key: CASSANDRA-17214
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17214
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> Such scenario:
> {code:java}
> @Test
> public void test() throws Exception
> {
> try (Cluster cluster =
> init(Cluster.build(2).withDataDirCount(1)).start()))
> {
> FBUtilities.waitOnFuture(cluster.get(2).shutdown());
> FBUtilities.waitOnFuture(cluster.get(1).shutdown());
> cluster.get(1).startup();
> cluster.get(2).startup();
> }
> }
> {code}
> throws
> {noformat}
> java.lang.IllegalStateException: Can't use shut down instances, delegate is
> null
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.delegate(AbstractCluster.java:210)
> at
> org.apache.cassandra.distributed.impl.DelegatingInvokableInstance.getMessagingVersion(DelegatingInvokableInstance.java:90)
> at
> org.apache.cassandra.distributed.action.GossipHelper.unsafeStatusToNormal(GossipHelper.java:95)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$null$10(Instance.java:640)
> {noformat}
> when we do not use {{Gossiper}} feature flag.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17214) Cannot restart a node when there are other nodes being down in in-jvm dtest framework
[
https://issues.apache.org/jira/browse/CASSANDRA-17214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-17214:
--
Test and Documentation Plan: run tests
Status: Patch Available (was: Open)
> Cannot restart a node when there are other nodes being down in in-jvm dtest
> framework
> -
>
> Key: CASSANDRA-17214
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17214
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> Such scenario:
> {code:java}
> @Test
> public void test() throws Exception
> {
> try (Cluster cluster =
> init(Cluster.build(2).withDataDirCount(1)).start()))
> {
> FBUtilities.waitOnFuture(cluster.get(2).shutdown());
> FBUtilities.waitOnFuture(cluster.get(1).shutdown());
> cluster.get(1).startup();
> cluster.get(2).startup();
> }
> }
> {code}
> throws
> {noformat}
> java.lang.IllegalStateException: Can't use shut down instances, delegate is
> null
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.delegate(AbstractCluster.java:210)
> at
> org.apache.cassandra.distributed.impl.DelegatingInvokableInstance.getMessagingVersion(DelegatingInvokableInstance.java:90)
> at
> org.apache.cassandra.distributed.action.GossipHelper.unsafeStatusToNormal(GossipHelper.java:95)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$null$10(Instance.java:640)
> {noformat}
> when we do not use {{Gossiper}} feature flag.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17238) Constants$Literal.getText does not escape ' chars
[
https://issues.apache.org/jira/browse/CASSANDRA-17238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sina Siadat updated CASSANDRA-17238:
Description:
The [current
implementation|https://sourcegraph.com/github.com/apache/cassandra@b83d722b99de79d131f58512564b901b11907182/-/blob/src/java/org/apache/cassandra/cql3/Constants.java?L358-361]
is only adding single quotes around the text:
{code:java}
public String getText()
{
return type == Type.STRING ? String.format("'%s'", text) : text;
}
{code}
So, getText for this string:
{code:java}
'this is a ''quoted'' word'
{code}
would return
{code:java}
'this is a 'quoted' word'
{code}
Maybe something like this would fix it, if necessary:
{code:java}
public String getText()
{
return type == Type.STRING ? String.format("'%s'",
StringUtils.replace(text, "'", "''")) : text;
}
{code}
was:
The [current
implementation|https://sourcegraph.com/github.com/apache/cassandra@b83d722b99de79d131f58512564b901b11907182/-/blob/src/java/org/apache/cassandra/cql3/Constants.java?L358-361]
is only adding single quotes around the text:
{code:java}
public String getText()
{
return type == Type.STRING ? String.format("'%s'", text) : text;
}
{code}
So, getText for this string:
{code}
'this is a ''quoted'' word'
{code}
would return
{code}
'this is a 'quoted' word'
{code}
Something like this is necessary:
{code:java}
public String getText()
{
return type == Type.STRING ? String.format("'%s'",
StringUtils.replace(text, "'", "''")) : text;
}
{code}
> Constants$Literal.getText does not escape ' chars
> -
>
> Key: CASSANDRA-17238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17238
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sina Siadat
>Priority: Normal
>
> The [current
> implementation|https://sourcegraph.com/github.com/apache/cassandra@b83d722b99de79d131f58512564b901b11907182/-/blob/src/java/org/apache/cassandra/cql3/Constants.java?L358-361]
> is only adding single quotes around the text:
> {code:java}
> public String getText()
> {
> return type == Type.STRING ? String.format("'%s'", text) : text;
> }
> {code}
> So, getText for this string:
> {code:java}
> 'this is a ''quoted'' word'
> {code}
> would return
> {code:java}
> 'this is a 'quoted' word'
> {code}
> Maybe something like this would fix it, if necessary:
> {code:java}
> public String getText()
> {
> return type == Type.STRING ? String.format("'%s'",
> StringUtils.replace(text, "'", "''")) : text;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17238) Constants$Literal.getText does not escape ' chars
[
https://issues.apache.org/jira/browse/CASSANDRA-17238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469431#comment-17469431
]
Sina Siadat edited comment on CASSANDRA-17238 at 1/6/22, 11:57 PM:
---
Yes, CQL keywords wouldn't need this kind of protection, but the problem here
is for getText when type is Type.STRING. Is it ever used with inputs of that
type? If so and if I'm not mistaken, getText for this CQL string:
{code:java}
'this is a ''quoted'' word'
{code}
would return
{code:java}
'this is a 'quoted' word'
{code}
which is probably an incorrect representation of the CQL string.
was (Author: JIRAUSER283097):
Yes, CQL keywords wouldn't need this kind of protection, but the problem here
is for getText when type is Type.STRING. So, getText for this CQL string:
{code}
'this is a ''quoted'' word'
{code}
would return
{code}
'this is a 'quoted' word'
{code}
which is an incorrect representation of the CQL string.
> Constants$Literal.getText does not escape ' chars
> -
>
> Key: CASSANDRA-17238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17238
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sina Siadat
>Priority: Normal
>
> The [current
> implementation|https://sourcegraph.com/github.com/apache/cassandra@b83d722b99de79d131f58512564b901b11907182/-/blob/src/java/org/apache/cassandra/cql3/Constants.java?L358-361]
> is only adding single quotes around the text:
> {code:java}
> public String getText()
> {
> return type == Type.STRING ? String.format("'%s'", text) : text;
> }
> {code}
> So, getText for this string:
> {code}
> 'this is a ''quoted'' word'
> {code}
> would return
> {code}
> 'this is a 'quoted' word'
> {code}
> Something like this is necessary:
> {code:java}
> public String getText()
> {
> return type == Type.STRING ? String.format("'%s'",
> StringUtils.replace(text, "'", "''")) : text;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17242) Remove Python 2.x support from CQLSH
Brad Schoening created CASSANDRA-17242: -- Summary: Remove Python 2.x support from CQLSH Key: CASSANDRA-17242 URL: https://issues.apache.org/jira/browse/CASSANDRA-17242 Project: Cassandra Issue Type: Task Components: CQL/Interpreter Reporter: Brad Schoening Python 2 has now reached EOL and should be removed from CQLSH and other Cassandra components. "We are volunteers who make and take care of the Python programming language. We have decided that January 1, 2020, was the day that we sunset Python 2. That means that we will not improve it anymore after that day, even if someone finds a security problem in it. You should upgrade to Python 3 as soon as you can. And if many people keep using Python 2, then that makes it hard for [the volunteers who use Python to make software|https://python3statement.org/#sections50-why]. They can't use the good new things in Python 3 to improve the tools they make. As of January 1st, 2020 no new bug reports, fixes, or changes will be made to Python 2, and Python 2 is no longer supported. " [https://www.python.org/doc/sunset-python-2/] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17239) Race in CompactionExecutorTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-17239:
-
Fix Version/s: 3.0.26
3.11.12
4.0.2
(was: 3.0.x)
(was: 3.11.x)
(was: 4.0.x)
Since Version: 2.2.11
Source Control Link:
https://github.com/apache/cassandra/commit/7f2c0d7e5f896fa1e466c9e7c1dbf9db9157eea8
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Race in CompactionExecutorTest
> --
>
> Key: CASSANDRA-17239
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17239
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> CompactionExecutorTest has a race between the runnable/callable under test
> completing
> and the {{afterExecute}} method stashing it for the test. Replace the
> wait/sleep loop
> with a {{SimpleCondition}} that is signaled once the test task throwable has
> been recorded.
> This seems fairly hard to hit but has happened on CI. It took about 2600
> iterations on my MacBook to trigger, but you can artificially hit frequently
> by adding a sleep at the start of the afterExecute method.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. jonmeredith pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 837adcf0a26a704b10ece4e90db267c085021342 Merge: 54aee87 57a7b8a Author: Jon Meredith AuthorDate: Thu Jan 6 14:33:33 2022 -0700 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] 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository.
jonmeredith pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 57a7b8a70ddcc4e5a690e22f67166a63afb74b3a
Merge: 0aad2e9 78f5057
Author: Jon Meredith
AuthorDate: Thu Jan 6 14:31:54 2022 -0700
Merge branch 'cassandra-3.11' into cassandra-4.0
CHANGES.txt| 1 +
.../db/compaction/CompactionExecutorTest.java | 32 +-
2 files changed, 20 insertions(+), 13 deletions(-)
diff --cc CHANGES.txt
index 0fd51ec,3e5dc2b..c84e643
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -45,24 -27,19 +45,25 @@@ Merged from 3.0
* Catch UnsatisfiedLinkError in WindowsTimer (CASSANDRA-16085)
* Avoid removing batch when it's not created during view replication
(CASSANDRA-16175)
* Make the addition of regular column to COMPACT tables throw an
InvalidRequestException (CASSANDRA-14564)
- * Fix materialized view schema backup as table (CASSANDRA-12734)
- * Avoid signaling DigestResolver until the minimum number of responses are
guaranteed to be visible (CASSANDRA-16883)
- * Fix secondary indexes on primary key columns skipping some writes
(CASSANDRA-16868)
- * Fix incorrect error message in LegacyLayout (CASSANDRA-15136)
- * Use JMX to validate nodetool --jobs parameter (CASSANDRA-16104)
- * Handle properly UnsatisfiedLinkError in NativeLibrary#getProcessID()
(CASSANDRA-16578)
- * Remove mutation data from error log message (CASSANDRA-16817)
+ * Race in CompactionExecutorTest (CASSANDRA-17239)
-Merged from 2.2:
- * Add python2 location to RPMs (CASSANDRA-16822)
-
-3.11.11
+4.0.1
+ * Tolerate missing DNS entry when completing a host replacement
(CASSANDRA-16873)
+ * Harden PrunableArrayQueue against Pruner implementations that might throw
exceptions (CASSANDRA-16866)
+ * Move RepairedDataInfo to the execution controller rather than the
ReadCommand to avoid unintended sharing (CASSANDRA-16721)
+ * Bump zstd-jni version to 1.5.0-4 (CASSANDRA-16884)
+ * Remove assumption that all urgent messages are small (CASSANDRA-16877)
+ * ArrayClustering.unsharedHeapSize does not include the data so undercounts
the heap size (CASSANDRA-16845)
+ * Improve help, doc and error messages about sstabledump -k and -x arguments
(CASSANDRA-16818)
+ * Add repaired/unrepaired bytes back to nodetool (CASSANDRA-15282)
+ * Upgrade lz4-java to 1.8.0 to add RH6 support back (CASSANDRA-16753)
+ * Improve DiagnosticEventService.publish(event) logging message of events
(CASSANDRA-16749)
+ * Cleanup dependency scopes (CASSANDRA-16704)
+ * Make JmxHistogram#getRecentValues() and JmxTimer#getRecentValues()
thread-safe (CASSANDRA-16707)
+Merged from 3.11:
+ * Validate SASI tokenizer options before adding index to schema
(CASSANDRA-15135)
+ * Fixup scrub output when no data post-scrub and clear up old use of row,
which really means partition (CASSANDRA-16835)
+ * Reduce thread contention in CommitLogSegment and HintsBuffer
(CASSANDRA-16072)
* Make cqlsh use the same set of reserved keywords than the server uses
(CASSANDRA-15663)
* Optimize bytes skipping when reading SSTable files (CASSANDRA-14415)
* Enable tombstone compactions when unchecked_tombstone_compaction is set in
TWCS (CASSANDRA-14496)
diff --cc
test/unit/org/apache/cassandra/db/compaction/CompactionExecutorTest.java
index ab3d9e5,918d58c..cca2997
--- a/test/unit/org/apache/cassandra/db/compaction/CompactionExecutorTest.java
+++ b/test/unit/org/apache/cassandra/db/compaction/CompactionExecutorTest.java
@@@ -63,9 -69,14 +70,14 @@@ public class CompactionExecutorTes
public void destroy() throws Exception
{
executor.shutdown();
-executor.awaitTermination(1, TimeUnit.MINUTES);
+Assert.assertTrue(executor.awaitTermination(1, TimeUnit.MINUTES));
}
+ void awaitExecution() throws Exception
+ {
+ assert afterExecuteCompleted.await(10, TimeUnit.SECONDS) :
"afterExecute failed to complete";
+ }
+
@Test
public void testFailedRunnable() throws Exception
{
-
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 (0aad2e9 -> 57a7b8a)
This is an automated email from the ASF dual-hosted git repository. jonmeredith pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 0aad2e9 Merge branch 'cassandra-3.11' into cassandra-4.0 new 071ecb5 Race in CompactionExecutorTest new 78f5057 Merge branch 'cassandra-3.0' into cassandra-3.11 new 57a7b8a Merge branch 'cassandra-3.11' into cassandra-4.0 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: CHANGES.txt| 1 + .../db/compaction/CompactionExecutorTest.java | 32 +- 2 files changed, 20 insertions(+), 13 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (54aee87 -> 837adcf)
This is an automated email from the ASF dual-hosted git repository. jonmeredith pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 54aee87 Merge branch 'cassandra-4.0' into trunk new 071ecb5 Race in CompactionExecutorTest new 78f5057 Merge branch 'cassandra-3.0' into cassandra-3.11 new 57a7b8a Merge branch 'cassandra-3.11' into cassandra-4.0 new 837adcf Merge branch 'cassandra-4.0' into trunk The 4 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] branch cassandra-3.11 updated (05b0eae -> 78f5057)
This is an automated email from the ASF dual-hosted git repository. jonmeredith pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 05b0eae Migrate documentation to AsciiDoc new 071ecb5 Race in CompactionExecutorTest new 78f5057 Merge branch 'cassandra-3.0' into cassandra-3.11 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../db/compaction/CompactionExecutorTest.java | 32 +- 2 files changed, 20 insertions(+), 13 deletions(-) - 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.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository.
jonmeredith pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 78f50573ad9238c34c7779a8dc33967d65944964
Merge: 05b0eae 071ecb5
Author: Jon Meredith
AuthorDate: Thu Jan 6 14:30:31 2022 -0700
Merge branch 'cassandra-3.0' into cassandra-3.11
CHANGES.txt| 1 +
.../db/compaction/CompactionExecutorTest.java | 32 +-
2 files changed, 20 insertions(+), 13 deletions(-)
diff --cc
test/unit/org/apache/cassandra/db/compaction/CompactionExecutorTest.java
index 2f8b5b2,b1f29b3..918d58c
--- a/test/unit/org/apache/cassandra/db/compaction/CompactionExecutorTest.java
+++ b/test/unit/org/apache/cassandra/db/compaction/CompactionExecutorTest.java
@@@ -25,7 -24,7 +24,8 @@@ import org.junit.After
import org.junit.Before;
import org.junit.Test;
import org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor;
+import org.apache.cassandra.config.DatabaseDescriptor;
+ import org.apache.cassandra.utils.concurrent.SimpleCondition;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;
@@@ -54,8 -58,9 +59,10 @@@ public class CompactionExecutorTes
@Before
public void setup()
{
+DatabaseDescriptor.daemonInitialization();
executor = new TestTaskExecutor();
+ testTaskThrowable = null;
+ afterExecuteCompleted = new SimpleCondition();
}
@After
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated: Race in CompactionExecutorTest
This is an automated email from the ASF dual-hosted git repository.
jonmeredith pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
new 071ecb5 Race in CompactionExecutorTest
071ecb5 is described below
commit 071ecb52465837c90520423c2bc80eb886936953
Author: Jon Meredith
AuthorDate: Thu Jan 6 11:12:21 2022 -0700
Race in CompactionExecutorTest
patch by Jon Meredith; reviewed by Josh McKenzie for CASSANDRA-17239
---
CHANGES.txt| 1 +
.../db/compaction/CompactionExecutorTest.java | 32 +-
2 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 085e1ff..6ed2033 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -22,6 +22,7 @@
* Use JMX to validate nodetool --jobs parameter (CASSANDRA-16104)
* Handle properly UnsatisfiedLinkError in NativeLibrary#getProcessID()
(CASSANDRA-16578)
* Remove mutation data from error log message (CASSANDRA-16817)
+ * Race in CompactionExecutorTest (CASSANDRA-17239)
Merged from 2.2:
* Add python2 location to RPMs (CASSANDRA-16822)
diff --git
a/test/unit/org/apache/cassandra/db/compaction/CompactionExecutorTest.java
b/test/unit/org/apache/cassandra/db/compaction/CompactionExecutorTest.java
index 9b07da9..b1f29b3 100644
--- a/test/unit/org/apache/cassandra/db/compaction/CompactionExecutorTest.java
+++ b/test/unit/org/apache/cassandra/db/compaction/CompactionExecutorTest.java
@@ -18,13 +18,13 @@
package org.apache.cassandra.db.compaction;
-import java.util.concurrent.Future;
import java.util.concurrent.TimeUnit;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor;
+import org.apache.cassandra.utils.concurrent.SimpleCondition;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotNull;
@@ -32,8 +32,12 @@ import static org.junit.Assert.assertNotNull;
public class CompactionExecutorTest
{
static Throwable testTaskThrowable = null;
+static SimpleCondition afterExecuteCompleted = null;
private static class TestTaskExecutor extends
CompactionManager.CompactionExecutor
{
+// afterExecute runs immediately after the task completes, but it may
+// race with the main thread checking the result, so make the main
thread wait
+// with a simple condition
@Override
public void afterExecute(Runnable r, Throwable t)
{
@@ -42,6 +46,7 @@ public class CompactionExecutorTest
t = DebuggableThreadPoolExecutor.extractThrowable(r);
}
testTaskThrowable = t;
+afterExecuteCompleted.signalAll();
}
@Override
protected void beforeExecute(Thread t, Runnable r)
@@ -54,6 +59,8 @@ public class CompactionExecutorTest
public void setup()
{
executor = new TestTaskExecutor();
+testTaskThrowable = null;
+afterExecuteCompleted = new SimpleCondition();
}
@After
@@ -63,16 +70,19 @@ public class CompactionExecutorTest
executor.awaitTermination(1, TimeUnit.MINUTES);
}
+void awaitExecution() throws Exception
+{
+assert afterExecuteCompleted.await(10, TimeUnit.SECONDS) :
"afterExecute failed to complete";
+}
+
@Test
public void testFailedRunnable() throws Exception
{
-testTaskThrowable = null;
-Future tt = executor.submitIfRunning(
+executor.submitIfRunning(
() -> { assert false : "testFailedRunnable"; }
, "compactionExecutorTest");
-while (!tt.isDone())
-Thread.sleep(10);
+awaitExecution();
assertNotNull(testTaskThrowable);
assertEquals(testTaskThrowable.getMessage(), "testFailedRunnable");
}
@@ -80,13 +90,11 @@ public class CompactionExecutorTest
@Test
public void testFailedCallable() throws Exception
{
-testTaskThrowable = null;
-Future tt = executor.submitIfRunning(
+executor.submitIfRunning(
() -> { assert false : "testFailedCallable"; return 1; }
, "compactionExecutorTest");
-while (!tt.isDone())
-Thread.sleep(10);
+awaitExecution();
assertNotNull(testTaskThrowable);
assertEquals(testTaskThrowable.getMessage(), "testFailedCallable");
}
@@ -94,13 +102,11 @@ public class CompactionExecutorTest
@Test
public void testExceptionRunnable() throws Exception
{
-testTaskThrowable = null;
-Future tt = executor.submitIfRunning(
+executor.submitIfRunning(
() -> { throw new RuntimeException("testExceptionRunnable"); }
, "compactionExecutorTest");
-while (!tt.isDone())
-Thread.sleep(10);
+
[jira] [Updated] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17190:
-
Status: Open (was: Patch Available)
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Manish Ghildiyal
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470196#comment-17470196
]
Brandon Williams commented on CASSANDRA-17190:
--
Unfortunately, the failures
([here|https://app.circleci.com/pipelines/github/driftx/cassandra/315/workflows/64b1e141-7948-4a49-9df7-9b9bab42eb63/jobs/2972/tests#failed-test-0],
[here|https://app.circleci.com/pipelines/github/driftx/cassandra/315/workflows/8f0c71a5-e377-400a-a698-94ecb5a83c0e/jobs/2978/tests#failed-test-0])
for the
[test_udf_overload|https://github.com/apache/cassandra-dtest/blob/trunk/user_functions_test.py#L136]
dtest are legitimate and caused by this patch, I manually verified as well.
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Manish Ghildiyal
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17190:
-
Status: Patch Available (was: Review In Progress)
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Manish Ghildiyal
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17239) Race in CompactionExecutorTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470195#comment-17470195
]
Jon Meredith commented on CASSANDRA-17239:
--
Test failures unrelated to CompactionExecutorTest - going ahead with merge
> Race in CompactionExecutorTest
> --
>
> Key: CASSANDRA-17239
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17239
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> CompactionExecutorTest has a race between the runnable/callable under test
> completing
> and the {{afterExecute}} method stashing it for the test. Replace the
> wait/sleep loop
> with a {{SimpleCondition}} that is signaled once the test task throwable has
> been recorded.
> This seems fairly hard to hit but has happened on CI. It took about 2600
> iterations on my MacBook to trigger, but you can artificially hit frequently
> by adding a sleep at the start of the afterExecute method.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17241) Improve audit logging documentation for production
[
https://issues.apache.org/jira/browse/CASSANDRA-17241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470173#comment-17470173
]
Romain Hardouin edited comment on CASSANDRA-17241 at 1/6/22, 8:20 PM:
--
I've pushed a PR with information and system.log examples to help users when
Googling warnings like:
* Failed to shrink file as it exists no longer
* Overriding roll cycle from xxx to yyy
Some Chronicle Queue 5.20.123 links:
* SingleChronicleQueueBuilder
[overrideRollCycle()|https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.123/src/main/java/net/openhft/chronicle/queue/impl/single/SingleChronicleQueueBuilder.java#L477]
log
* Inference when [metadata is
deleted|https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.123/src/main/java/net/openhft/chronicle/queue/impl/single/SingleChronicleQueueBuilder.java#L446-L447]
* JVM properties
[chronicle.queue.synchronousFileShrinking|https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.123/src/main/java/net/openhft/chronicle/queue/impl/single/QueueFileShrinkManager.java#L36-L37]
* Roll cycles
[values|https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.123/src/main/java/net/openhft/chronicle/queue/RollCycles.java#L30]
was (Author: rha):
I've pushed a PR with information and system.log examples to help users when
Googling warnings like:
* Failed to shrink file as it exists no longer
* Overriding roll cycle from xxx to yyy
Some Chronicle Queue links:
* SingleChronicleQueueBuilder
[overrideRollCycle()|https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.123/src/main/java/net/openhft/chronicle/queue/impl/single/SingleChronicleQueueBuilder.java#L477]
log
* Inference when [metadata is
deleted|https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.123/src/main/java/net/openhft/chronicle/queue/impl/single/SingleChronicleQueueBuilder.java#L446-L447]
* JVM properties
[chronicle.queue.synchronousFileShrinking|https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.123/src/main/java/net/openhft/chronicle/queue/impl/single/QueueFileShrinkManager.java#L36-L37]
> Improve audit logging documentation for production
> --
>
> Key: CASSANDRA-17241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17241
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Romain Hardouin
>Assignee: Romain Hardouin
>Priority: Normal
> Fix For: 4.0.x
>
>
> After using audit logging in production, it turns out that documentation is
> lacking some important information.
> Namely:
> * {{roll_cycle}} can be overriden by Chronicle Queue
> * {{max_log_size}} is ignored if {{archive_command}} option is set
> * {{archive_command}} prevents Chronicle Queue Shrink Manager from working
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17241) Improve audit logging documentation for production
[
https://issues.apache.org/jira/browse/CASSANDRA-17241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470173#comment-17470173
]
Romain Hardouin commented on CASSANDRA-17241:
-
I've pushed a PR with information and system.log examples to help users when
Googling warnings like:
* Failed to shrink file as it exists no longer
* Overriding roll cycle from xxx to yyy
Some Chronicle Queue links:
* SingleChronicleQueueBuilder
[overrideRollCycle()|https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.123/src/main/java/net/openhft/chronicle/queue/impl/single/SingleChronicleQueueBuilder.java#L477]
log
* Inference when [metadata is
deleted|https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.123/src/main/java/net/openhft/chronicle/queue/impl/single/SingleChronicleQueueBuilder.java#L446-L447]
* JVM properties
[chronicle.queue.synchronousFileShrinking|https://github.com/OpenHFT/Chronicle-Queue/blob/chronicle-queue-5.20.123/src/main/java/net/openhft/chronicle/queue/impl/single/QueueFileShrinkManager.java#L36-L37]
> Improve audit logging documentation for production
> --
>
> Key: CASSANDRA-17241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17241
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Romain Hardouin
>Assignee: Romain Hardouin
>Priority: Normal
> Fix For: 4.0.x
>
>
> After using audit logging in production, it turns out that documentation is
> lacking some important information.
> Namely:
> * {{roll_cycle}} can be overriden by Chronicle Queue
> * {{max_log_size}} is ignored if {{archive_command}} option is set
> * {{archive_command}} prevents Chronicle Queue Shrink Manager from working
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17241) Improve audit logging documentation for production
[
https://issues.apache.org/jira/browse/CASSANDRA-17241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17241:
-
Test and Documentation Plan: docs
Status: Patch Available (was: Open)
> Improve audit logging documentation for production
> --
>
> Key: CASSANDRA-17241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17241
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Romain Hardouin
>Assignee: Romain Hardouin
>Priority: Normal
> Fix For: 4.0.x
>
>
> After using audit logging in production, it turns out that documentation is
> lacking some important information.
> Namely:
> * {{roll_cycle}} can be overriden by Chronicle Queue
> * {{max_log_size}} is ignored if {{archive_command}} option is set
> * {{archive_command}} prevents Chronicle Queue Shrink Manager from working
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17241) Improve audit logging documentation for production
[
https://issues.apache.org/jira/browse/CASSANDRA-17241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17241:
-
Change Category: Operability
Complexity: Normal
Fix Version/s: 4.0.x
Status: Open (was: Triage Needed)
> Improve audit logging documentation for production
> --
>
> Key: CASSANDRA-17241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17241
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Romain Hardouin
>Assignee: Romain Hardouin
>Priority: Normal
> Fix For: 4.0.x
>
>
> After using audit logging in production, it turns out that documentation is
> lacking some important information.
> Namely:
> * {{roll_cycle}} can be overriden by Chronicle Queue
> * {{max_log_size}} is ignored if {{archive_command}} option is set
> * {{archive_command}} prevents Chronicle Queue Shrink Manager from working
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17241) Improve audit logging documentation for production
[
https://issues.apache.org/jira/browse/CASSANDRA-17241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Hardouin updated CASSANDRA-17241:
Description:
After using audit logging in production, it turns out that documentation is
lacking some important information.
Namely:
* {{roll_cycle}} can be overriden by Chronicle Queue
* {{max_log_size}} is ignored if {{archive_command}} option is set
* {{archive_command}} prevents Chronicle Queue Shrink Manager from working
was:
After using audit logging in production, it turns out that documentation is
lacking some important information.
Namely:
* {{roll_cycle}} cannot be changed just by modifying cassandra.yaml
* {{max_log_size}} is ignored if {{archive_command}} option is set
* {{archive_command}} prevents Chronicle Queue Shrink Manager from working
> Improve audit logging documentation for production
> --
>
> Key: CASSANDRA-17241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17241
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Romain Hardouin
>Assignee: Romain Hardouin
>Priority: Normal
>
> After using audit logging in production, it turns out that documentation is
> lacking some important information.
> Namely:
> * {{roll_cycle}} can be overriden by Chronicle Queue
> * {{max_log_size}} is ignored if {{archive_command}} option is set
> * {{archive_command}} prevents Chronicle Queue Shrink Manager from working
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17241) Improve audit logging documentation for production
Romain Hardouin created CASSANDRA-17241:
---
Summary: Improve audit logging documentation for production
Key: CASSANDRA-17241
URL: https://issues.apache.org/jira/browse/CASSANDRA-17241
Project: Cassandra
Issue Type: Improvement
Components: Documentation/Website
Reporter: Romain Hardouin
Assignee: Romain Hardouin
After using audit logging in production, it turns out that documentation is
lacking some important information.
Namely:
* {{roll_cycle}} cannot be changed just by modifying cassandra.yaml
* {{max_log_size}} is ignored if {{archive_command}} option is set
* {{archive_command}} prevents Chronicle Queue Shrink Manager from working
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17239) Race in CompactionExecutorTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470104#comment-17470104
]
Jon Meredith commented on CASSANDRA-17239:
--
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|cassandra-3.0|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-17239-cassandra-3.0-3F4CD5B8-B00A-4F97-B022-85FA3FED27A1]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-17239-cassandra-3.0-3F4CD5B8-B00A-4F97-B022-85FA3FED27A1]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1350/]|
|cassandra-3.11|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-17239-cassandra-3.11-3F4CD5B8-B00A-4F97-B022-85FA3FED27A1]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-17239-cassandra-3.11-3F4CD5B8-B00A-4F97-B022-85FA3FED27A1]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1351/]|
|cassandra-4.0|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-17239-cassandra-4.0-3F4CD5B8-B00A-4F97-B022-85FA3FED27A1]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-17239-cassandra-4.0-3F4CD5B8-B00A-4F97-B022-85FA3FED27A1]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1352/]|
(no change to trunk, will add the merge commit to resolve).
> Race in CompactionExecutorTest
> --
>
> Key: CASSANDRA-17239
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17239
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> CompactionExecutorTest has a race between the runnable/callable under test
> completing
> and the {{afterExecute}} method stashing it for the test. Replace the
> wait/sleep loop
> with a {{SimpleCondition}} that is signaled once the test task throwable has
> been recorded.
> This seems fairly hard to hit but has happened on CI. It took about 2600
> iterations on my MacBook to trigger, but you can artificially hit frequently
> by adding a sleep at the start of the afterExecute method.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470082#comment-17470082
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/6/22, 5:44 PM:
--
Moved back to 4.x as the patch has backward compatibility, introducing no
breaking changes which aligns with our release discussions.
{quote}we would probably save ourselves some UX trouble later on if we allow a
single space between values and units. (ex. Allow both 10MiB and 10 MiB.)
{quote}
This is very easy to introduce but I think it is confusing to have both,
similar to what we decided about the letter case. I would prefer to keep the
current version only. Let me know what you think.
{quote}The second is trying, where possible, to leave the cases where we throw
{{ConfigurationException}} intact. (This mostly applies to the cases where we
might throw it via JMX, i.e. we have something of a contract at the moment.)
{quote}
Good point, I will handle it, thanks.
was (Author: e.dimitrova):
Moved back to 4.x as the patch has backward compatibility, introducing no
breaking changes which aligns with our release discussions.
{quote}r on if we allow a single space between values and units. (ex. Allow
both 10MiB and 10 MiB
{quote}
This is very easy to introduce but I think it is confusing to have both,
similar to what we decided about the letter case. I would prefer to keep the
current version only. Let me know what you think.
{quote}The second is trying, where possible, to leave the cases where we throw
{{ConfigurationException}} intact. (This mostly applies to the cases where we
might throw it via JMX, i.e. we have something of a contract at the moment.)
{quote}
Good point, I will handle it, thanks.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470082#comment-17470082
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/6/22, 5:43 PM:
--
Moved back to 4.x as the patch has backward compatibility, introducing no
breaking changes which aligns with our release discussions.
{quote}r on if we allow a single space between values and units. (ex. Allow
both 10MiB and 10 MiB
{quote}
This is very easy to introduce but I think it is confusing to have both,
similar to what we decided about the letter case. I would prefer to keep the
current version only. Let me know what you think.
{quote}The second is trying, where possible, to leave the cases where we throw
{{ConfigurationException}} intact. (This mostly applies to the cases where we
might throw it via JMX, i.e. we have something of a contract at the moment.)
{quote}
Good point, I will handle it, thanks.
was (Author: e.dimitrova):
Moved back to 4.x as the patch has backward compatibility, introducing no
breaking changes which aligns with our release discussions.
{quote}r on if we allow a single space between values and units. (ex. Allow
both {{10MiB }}and {{10 MiB}}
{quote}
This is very easy to introduce but I think it is confusing to have both,
similar to what we decided about the letter case. I would prefer to keep the
current version only. Let me know what you think.
{quote}bq. The second is trying, where possible, to leave the cases where we
throw {{ConfigurationException}} intact. (This mostly applies to the cases
where we might throw it via JMX, i.e. we have something of a contract at the
moment.)
{quote}
Good point, I will handle it, thanks.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470082#comment-17470082
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-
Moved back to 4.x as the patch has backward compatibility, introducing no
breaking changes which aligns with our release discussions.
{quote}r on if we allow a single space between values and units. (ex. Allow
both {{10MiB }}and {{10 MiB}}
{quote}
This is very easy to introduce but I think it is confusing to have both,
similar to what we decided about the letter case. I would prefer to keep the
current version only. Let me know what you think.
{quote}bq. The second is trying, where possible, to leave the cases where we
throw {{ConfigurationException}} intact. (This mostly applies to the cases
where we might throw it via JMX, i.e. we have something of a contract at the
moment.)
{quote}
Good point, I will handle it, thanks.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15234:
Fix Version/s: 4.x
(was: 5.x)
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470013#comment-17470013
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/6/22, 4:16 PM:
--
Thank you [~maedhroz] . I already addressed the first two commits review
comments, I will address the third commit comments now. Then I will rebase on
the latest changes from December and take care of the newest added config in a
new commit. I will ping you when I am done.
{quote}It's ok that the patch bumps build.xml to 5.0, if warranted (on the
presumption we are honouring capability or providing a deprecation cycle where
appropriate).
{quote}
In theory we have backward compatibility with the old yaml, no breaking
changes which someone might say it qualifies for 4.1. Should I hit the mailing
list about that?
Also, for general visibility - I opted out of adding new JMX methods as there
are already tickets for updating config through Virtual tables people work on
and also there is no plan to change nodetool.
was (Author: e.dimitrova):
Thank you [~maedhroz] . I already addressed the first two commits review
comments, I will address the third commit comments now. Then I will rebase on
the latest changes from December and take care of the newest added config in a
new commit. I will ping you when I am done.
{quote}{quote} It's ok that the patch bumps build.xml to 5.0, if warranted (on
the presumption we are honouring capability or providing a deprecation cycle
where appropriate).
{quote}{quote}
In theory we have backward compatibility with the old yaml, no breaking
changes which someone might say it qualifies for 4.1. Should I hit the mailing
list about that?
Also, for general visibility - I opted out of adding new JMX methods as there
are already tickets for updating config through Virtual tables people work on
and also there is no plan to change nodetool.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470013#comment-17470013
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/6/22, 4:16 PM:
--
Thank you [~maedhroz] . I already addressed the first two commits review
comments, I will address the third commit comments now. Then I will rebase on
the latest changes from December and take care of the newest added config in a
new commit. I will ping you when I am done.
{quote}{quote} It's ok that the patch bumps build.xml to 5.0, if warranted (on
the presumption we are honouring capability or providing a deprecation cycle
where appropriate).
{quote}{quote}
In theory we have backward compatibility with the old yaml, no breaking
changes which someone might say it qualifies for 4.1. Should I hit the mailing
list about that?
Also, for general visibility - I opted out of adding new JMX methods as there
are already tickets for updating config through Virtual tables people work on
and also there is no plan to change nodetool.
was (Author: e.dimitrova):
Thank you [~maedhroz] . I already addressed those on the first two commits, I
will address the third commit comments now. Then I will rebase on the latest
changes from December and take care of the newest added config in a new commit.
I will ping you when I am done.
{quote}bq. It's ok that the patch bumps build.xml to 5.0, if warranted (on the
presumption we are honouring capability or providing a deprecation cycle where
appropriate).
{quote}
In theory we have backward compatibility with the old yaml, no breaking
changes which someone might say it qualifies for 4.1. Should I hit the mailing
list about that?
Also, for general visibility - I opted out of adding new JMX methods as there
are already tickets for updating config through Virtual tables people work on
and also there is no plan to change nodetool.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470013#comment-17470013
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-
Thank you [~maedhroz] . I already addressed those on the first two commits, I
will address the third commit comments now. Then I will rebase on the latest
changes from December and take care of the newest added config in a new commit.
I will ping you when I am done.
{quote}bq. It's ok that the patch bumps build.xml to 5.0, if warranted (on the
presumption we are honouring capability or providing a deprecation cycle where
appropriate).
{quote}
In theory we have backward compatibility with the old yaml, no breaking
changes which someone might say it qualifies for 4.1. Should I hit the mailing
list about that?
Also, for general visibility - I opted out of adding new JMX methods as there
are already tickets for updating config through Virtual tables people work on
and also there is no plan to change nodetool.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17239) Race in CompactionExecutorTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469978#comment-17469978
]
Josh McKenzie commented on CASSANDRA-17239:
---
+1. Had a question about whether inheriting the 10 second timeout w/out
revising it makes sense from a "brittleness and future containerized test
execution environments will make us sad" perspective but still; this should fix
it.
> Race in CompactionExecutorTest
> --
>
> Key: CASSANDRA-17239
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17239
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CompactionExecutorTest has a race between the runnable/callable under test
> completing
> and the {{afterExecute}} method stashing it for the test. Replace the
> wait/sleep loop
> with a {{SimpleCondition}} that is signaled once the test task throwable has
> been recorded.
> This seems fairly hard to hit but has happened on CI. It took about 2600
> iterations on my MacBook to trigger, but you can artificially hit frequently
> by adding a sleep at the start of the afterExecute method.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17239) Race in CompactionExecutorTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17239:
--
Reviewers: Josh McKenzie
> Race in CompactionExecutorTest
> --
>
> Key: CASSANDRA-17239
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17239
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CompactionExecutorTest has a race between the runnable/callable under test
> completing
> and the {{afterExecute}} method stashing it for the test. Replace the
> wait/sleep loop
> with a {{SimpleCondition}} that is signaled once the test task throwable has
> been recorded.
> This seems fairly hard to hit but has happened on CI. It took about 2600
> iterations on my MacBook to trigger, but you can artificially hit frequently
> by adding a sleep at the start of the afterExecute method.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17239) Race in CompactionExecutorTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17239:
--
Reviewers: Josh McKenzie, Josh McKenzie (was: Josh McKenzie)
Josh McKenzie, Josh McKenzie (was: Josh McKenzie)
Status: Review In Progress (was: Patch Available)
> Race in CompactionExecutorTest
> --
>
> Key: CASSANDRA-17239
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17239
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CompactionExecutorTest has a race between the runnable/callable under test
> completing
> and the {{afterExecute}} method stashing it for the test. Replace the
> wait/sleep loop
> with a {{SimpleCondition}} that is signaled once the test task throwable has
> been recorded.
> This seems fairly hard to hit but has happened on CI. It took about 2600
> iterations on my MacBook to trigger, but you can artificially hit frequently
> by adding a sleep at the start of the afterExecute method.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17239) Race in CompactionExecutorTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17239:
--
Status: Ready to Commit (was: Review In Progress)
> Race in CompactionExecutorTest
> --
>
> Key: CASSANDRA-17239
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17239
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CompactionExecutorTest has a race between the runnable/callable under test
> completing
> and the {{afterExecute}} method stashing it for the test. Replace the
> wait/sleep loop
> with a {{SimpleCondition}} that is signaled once the test task throwable has
> been recorded.
> This seems fairly hard to hit but has happened on CI. It took about 2600
> iterations on my MacBook to trigger, but you can artificially hit frequently
> by adding a sleep at the start of the afterExecute method.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10537) CONTAINS and CONTAINS KEY support for Lightweight Transactions
[
https://issues.apache.org/jira/browse/CASSANDRA-10537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469970#comment-17469970
]
ROCHETEAU Antoine commented on CASSANDRA-10537:
---
Hello,
I just take a look into this improvement and so far this is the current state
of my working branch:
Use of *CONTAINS* operator is allowed on collection (evaluation of the
condition is performed on lists, sets and maps values)
Use of *CONTAINS KEY* operator is allowed on map only (evaluation is performed
on map keyset)
So these conditions are now valid and working:
{{IF list_column CONTAINS 'bar'}}
{{IF set_column CONTAINS 'bar'}}
{{IF map_column CONTAINS 'bar'}}
{{IF map_column CONTAINS KEY 'foo'}}
These are not and will throw an {_}InvalidRequestException{_}:
{{IF list_column CONTAINS KEY 'bar'}}
{{IF set_column CONTAINS KEY 'bar'}}
{{IF text_column CONTAINS 'bar'}}
Finally, these are still throwing a {_}SyntaxException{_}:
{{IF list_column[1] CONTAINS 'bar'}}
{{IF map_column['foo'] CONTAINS 'bar'}}
{{IF udt_column.a CONTAINS 'bar' }}
Modifications are quite light so i haven't started the refactoring of
_ColumnCondition_ mentioned by [~ifesdjeen] (even if i'm agree on its benefits).
Should I submit a pull request in this current state or did i miss something ?
Best regards,
Antoine
> CONTAINS and CONTAINS KEY support for Lightweight Transactions
> --
>
> Key: CASSANDRA-10537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Nimi Wariboko Jr.
>Priority: Normal
> Labels: AdventCalendar2021, CQL, lhf
> Fix For: 4.x
>
>
> Conditional updates currently do not support CONTAINS and CONTAINS KEY
> conditions. Queries such as
> {{UPDATE mytable SET somefield = 4 WHERE pk = 'pkv' IF set_column CONTAINS
> 5;}}
> are not possible.
> Would it also be possible to support the negation of these (ex. testing that
> a value does not exist inside a set)?
> +Additional Information for newcomers:+
> Negation should not be supported as for the moment we do not support it
> within restrictions either.
> One way to approch this bug is to use test driven development. You can modify
> {{InsertUpdateIfConditionCollectionsTest}} to allow CONTAINS and CONTAINS KEY
> operators and go through the different failures.
> The following changes will need to be done.
> * The {{columnCondition}} rule from the ANTLR {{Parser.g}} file should be
> updated to accept {{containsOperator}}.
> * {{ColumnCondition.Raw#prepareTerms}} should be modified in the case where
> the operator is a CONTAINS or CONTAINS KEY as the {{receiver}} is not the
> collection but keys or values of the collection. Look at
> {{SingleColumnRelation#makeCollectionReceiver}}.
> * {{ColumnCollection.MultiCellCollectionBound#valueAppliesTo}} will need to
> be changed for {{Map}} and {{Set}} to process CONTAINS operators.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17048) Replace sequential sstable generation identifier with UUID v1
[ https://issues.apache.org/jira/browse/CASSANDRA-17048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469963#comment-17469963 ] Andres de la Peña commented on CASSANDRA-17048: --- Here is a new round of CI for the last changes on the PR: ||PR||CI|| |[trunk|https://github.com/apache/cassandra/pull/1276]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1226/workflows/0ccfbbcd-08b0-4454-ba32-f3dc63b58f73] [j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1226/workflows/517e03b4-466e-4270-b041-954fb736db93]| It seems that the patch is still breaking multiple tests. > Replace sequential sstable generation identifier with UUID v1 > - > > Key: CASSANDRA-17048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17048 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.1 > > Time Spent: 6h 40m > Remaining Estimate: 0h > > Replace the current sequential sstable generation identifier with ULID based. > ULID is better because we do not need to scan the existing files to pick the > starting number as well as we can generate globally unique identifiers. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469556#comment-17469556
]
Brandon Williams edited comment on CASSANDRA-17190 at 1/6/22, 3:10 PM:
---
I accidentally ran the dtests there without increasing the resources so those
failures can be ignored, and everything else looks good, but I also started
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1347/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1347/pipeline]
was (Author: brandon.williams):
I accidentally ran the dtests there without increasing the resources so those
failures can be ignored, and everything else looks good, but I also started
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1346/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1346/pipeline]
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Manish Ghildiyal
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17240) CEP-19: Trie memtable implementation
[ https://issues.apache.org/jira/browse/CASSANDRA-17240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Branimir Lambov updated CASSANDRA-17240: Description: Trie-based memtable implementation as described in CEP-19, built on top of CASSANDRA-17034 and CASSANDRA-6936. The implementation is available in this [branch|https://github.com/blambov/cassandra/tree/CASSANDRA-17240]. was:Trie-based memtable implementation as described in CEP-19, built on top of CASSANDRA-17034 and CASSANDRA-6936. > CEP-19: Trie memtable implementation > > > Key: CASSANDRA-17240 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17240 > Project: Cassandra > Issue Type: Improvement > Components: Local/Memtable >Reporter: Branimir Lambov >Priority: Normal > > Trie-based memtable implementation as described in CEP-19, built on top of > CASSANDRA-17034 and CASSANDRA-6936. > The implementation is available in this > [branch|https://github.com/blambov/cassandra/tree/CASSANDRA-17240]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17240) CEP-19: Trie memtable implementation
Branimir Lambov created CASSANDRA-17240: --- Summary: CEP-19: Trie memtable implementation Key: CASSANDRA-17240 URL: https://issues.apache.org/jira/browse/CASSANDRA-17240 Project: Cassandra Issue Type: Improvement Components: Local/Memtable Reporter: Branimir Lambov Trie-based memtable implementation as described in CEP-19, built on top of CASSANDRA-17034 and CASSANDRA-6936. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: ninja-fix: remove interactive/tty (`-i -t`) from docker run command
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
The following commit(s) were added to refs/heads/trunk by this push:
new d27bb8c ninja-fix: remove interactive/tty (`-i -t`) from docker run
command
d27bb8c is described below
commit d27bb8c995d87b424f2ad170630f67ba5aaad71a
Author: mck
AuthorDate: Thu Jan 6 11:29:28 2022 +0100
ninja-fix: remove interactive/tty (`-i -t`) from docker run command
---
run.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/run.sh b/run.sh
index 5514c9b..5da4514 100755
--- a/run.sh
+++ b/run.sh
@@ -316,7 +316,7 @@ exec_docker_run_command() {
remove_container_option=""
fi
- exec_docker_command "run -i -t ${remove_container_option} $*"
+ exec_docker_command "run ${remove_container_option} $*"
}
exec_docker_build_command() {
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17062) Expose Auth Caches metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-17062:
Status: Changes Suggested (was: Review In Progress)
[~azotcsit] thanks for the PR, the new VT and tool output look good but I've
got a couple of comments regarding the implementation:
I'm all for the distinction between weighted/unweighted caches at the
presentation layer, but is there really a need to enforce this in the model
code? The only real difference between the types at this level is the units of
size/capacity, which are not explicit and only referenced in comments. I don't
see any harm in the all cache metrics including a {{{}weightedSize{}}}, for
unweighted caches this is just equal to {{size}} and simply isn't included in
the VT/nodetool output.
As implemented, the mechanism of tracking hits/misses isn't correct. Because
the auth caches use {{LoadingCache}} which transparently fetches missing
entries, the hit rate is inflated and the miss rate undercounted. As it is, a
miss would only be recorded if key is not cached *and* isn't found in the
underlying storage. Likewise, a cache miss followed by a load from storage is
counted as a hit.
I've pushed a couple of commits that address these points to
[https://github.com/beobal/cassandra/tree/samt/17062-trunk]. When you get
chance, take a look and see what you think.
> Expose Auth Caches metrics
> --
>
> Key: CASSANDRA-17062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17062
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Observability/Metrics,
> Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Unlike to other caches (row, key, counter), Auth Caches lack some monitoring
> capabilities. Here are a few particular changes to get this inequity fixed:
> # Add auth caches to _system_views.caches_ VT
> # Expose auth caches metrics via JMX
> # Add auth caches details to _nodetool info_
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17062) Expose Auth Caches metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-17062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-17062: Reviewers: Sam Tunnicliffe Status: Review In Progress (was: Patch Available) > Expose Auth Caches metrics > -- > > Key: CASSANDRA-17062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17062 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables, Observability/Metrics, > Tool/nodetool >Reporter: Aleksei Zotov >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 4.x > > > Unlike to other caches (row, key, counter), Auth Caches lack some monitoring > capabilities. Here are a few particular changes to get this inequity fixed: > # Add auth caches to _system_views.caches_ VT > # Expose auth caches metrics via JMX > # Add auth caches details to _nodetool info_ > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469818#comment-17469818
]
Michael Semb Wever edited comment on CASSANDRA-15234 at 1/6/22, 10:16 AM:
--
bq. Ah, and of course, we'll have to make a decision in terms of whether this
hits 4.1 or not. If it doesn't, it seems like we wouldn't be able to merge to
trunk.
It's ok that the patch bumps build.xml to 5.0, if warranted (on the presumption
we are honouring capability or providing a deprecation cycle where appropriate).
was (Author: michaelsembwever):
> Ah, and of course, we'll have to make a decision in terms of whether this
> hits 4.1 or not. If it doesn't, it seems like we wouldn't be able to merge to
> trunk.
It's ok that the patch bumps build.xml to 5.0, if warranted (on the presumption
we are honouring capability or providing a deprecation cycle where appropriate).
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469818#comment-17469818
]
Michael Semb Wever commented on CASSANDRA-15234:
> Ah, and of course, we'll have to make a decision in terms of whether this
> hits 4.1 or not. If it doesn't, it seems like we wouldn't be able to merge to
> trunk.
It's ok that the patch bumps build.xml to 5.0, if warranted (on the presumption
we are honouring capability or providing a deprecation cycle where appropriate).
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
