[jira] [Updated] (CASSANDRA-16856) Prevent broken concurrent schema pulls
[ https://issues.apache.org/jira/browse/CASSANDRA-16856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16856: Since Version: 3.11.x Source Control Link: https://github.com/apache/cassandra/commit/23b61a5fa1de17cc6b8a1d7c300053160bfc728a Resolution: Fixed Status: Resolved (was: Ready to Commit) > Prevent broken concurrent schema pulls > -- > > Key: CASSANDRA-16856 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16856 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1, 3.11.x, 4.0.x > > > There's a race condition around pulling schema changes, that can occur in > case the schema changes push/propagation mechanism is not immediately > effective (e.g. because of network delay, or because of the pulling node > being down, etc.). > If schema changes happen on node 1, these changes do not reach node 2 > immediately through the SCHEMA.PUSH mechanism, and are first recognized > during gossiping, the corresponding SCHEMA.PULL request from node 2 can catch > the node 1 schema in the middle of it being modified by another schema change > request. This can easily lead to problems (e.g. if a new table is being > added, and the node 2 request reads the changes that need to be applied to > system_schema.tables, but not the ones that need to be applied to > system_schema.columns). > This PR addresses that by synchronizing the SCHEMA.PULL "RPC call" executed > in node 1 by a request from node 2 with the method for applying schema > changes in node 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
[cassandra] branch trunk updated (304deea -> 0581820)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 304deea Merge branch cassandra-4.0 into trunk new 23b61a5 Prevent broken concurrent schema pulls new f80b177 Merge branch 'cassandra-3.11' into cassandra-4.0 new 0581820 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: src/java/org/apache/cassandra/schema/SchemaKeyspace.java| 4 +--- .../org/apache/cassandra/schema/SchemaKeyspaceTest.java | 13 + 2 files changed, 14 insertions(+), 3 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: Prevent broken concurrent schema pulls
This is an automated email from the ASF dual-hosted git repository.
bereng 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 23b61a5 Prevent broken concurrent schema pulls
23b61a5 is described below
commit 23b61a5fa1de17cc6b8a1d7c300053160bfc728a
Author: Bereng
AuthorDate: Mon Aug 16 07:46:33 2021 +0200
Prevent broken concurrent schema pulls
patch by Dimitar Dimitrov and Berenguer Blasi; reviewed by Brandon
Williams, Berenguer Blasi for CASSANDRA-16856
Co-authored-by: Dimitar Dimitrov
Co-authored-by: Berenguer Blasi
---
src/java/org/apache/cassandra/schema/SchemaKeyspace.java| 2 +-
.../org/apache/cassandra/service/MigrationCoordinator.java | 1 +
src/java/org/apache/cassandra/service/MigrationManager.java | 1 +
.../org/apache/cassandra/schema/SchemaKeyspaceTest.java | 13 +
4 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
b/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
index b852072..68c0b07 100644
--- a/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
+++ b/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
@@ -380,7 +380,7 @@ public final class SchemaKeyspace
return PartitionRangeReadCommand.allDataRead(cfs.metadata,
FBUtilities.nowInSeconds());
}
-public static Collection convertSchemaToMutations()
+public static synchronized Collection convertSchemaToMutations()
{
Map mutationMap = new HashMap<>();
diff --git a/src/java/org/apache/cassandra/service/MigrationCoordinator.java
b/src/java/org/apache/cassandra/service/MigrationCoordinator.java
index 10c7551..ce5f269 100644
--- a/src/java/org/apache/cassandra/service/MigrationCoordinator.java
+++ b/src/java/org/apache/cassandra/service/MigrationCoordinator.java
@@ -481,6 +481,7 @@ public class MigrationCoordinator
{
try
{
+logger.debug("Pulled schema from endpoint {};",
endpoint);
mergeSchemaFrom(endpoint, mutations);
}
catch (Exception e)
diff --git a/src/java/org/apache/cassandra/service/MigrationManager.java
b/src/java/org/apache/cassandra/service/MigrationManager.java
index 8d8a0bd..21daef2 100644
--- a/src/java/org/apache/cassandra/service/MigrationManager.java
+++ b/src/java/org/apache/cassandra/service/MigrationManager.java
@@ -431,6 +431,7 @@ public class MigrationManager
private static void pushSchemaMutation(InetAddress endpoint,
Collection schema)
{
+logger.debug("Pushing schema to endpoint {}", endpoint);
MessageOut> msg = new
MessageOut<>(MessagingService.Verb.DEFINITIONS_UPDATE,
schema,
MigrationsSerializer.instance);
diff --git a/test/unit/org/apache/cassandra/schema/SchemaKeyspaceTest.java
b/test/unit/org/apache/cassandra/schema/SchemaKeyspaceTest.java
index f3ee85d..19f06e5 100644
--- a/test/unit/org/apache/cassandra/schema/SchemaKeyspaceTest.java
+++ b/test/unit/org/apache/cassandra/schema/SchemaKeyspaceTest.java
@@ -19,6 +19,8 @@
package org.apache.cassandra.schema;
import java.io.IOException;
+import java.lang.reflect.Method;
+import java.lang.reflect.Modifier;
import java.nio.ByteBuffer;
import java.util.ArrayList;
import java.util.Collection;
@@ -92,6 +94,17 @@ public class SchemaKeyspaceTest
SchemaLoader.standardCFMD(KEYSPACE1,
CF_STANDARD1));
}
+/** See CASSANDRA-16856. Make sure schema pulls are synchronized to
prevent concurrent schema pull/writes
+ *
+ * @throws Exception
+ */
+@Test
+public void testSchemaPullSynchoricity() throws Exception
+{
+Method method =
SchemaKeyspace.class.getDeclaredMethod("convertSchemaToMutations");
+assertTrue(Modifier.isSynchronized(method.getModifiers()));
+}
+
@Test
public void testThriftConversion() throws Exception
{
-
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.
bereng pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit f80b177f6f615724c445ed16d2b0cb7b48461375
Merge: 433274b 23b61a5
Author: Bereng
AuthorDate: Thu Aug 19 07:36:07 2021 +0200
Merge branch 'cassandra-3.11' into cassandra-4.0
src/java/org/apache/cassandra/schema/SchemaKeyspace.java| 4 +---
.../org/apache/cassandra/schema/SchemaKeyspaceTest.java | 13 +
2 files changed, 14 insertions(+), 3 deletions(-)
diff --cc src/java/org/apache/cassandra/schema/SchemaKeyspace.java
index 65e9adb,68c0b07..e8c22b1
--- a/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
+++ b/src/java/org/apache/cassandra/schema/SchemaKeyspace.java
@@@ -39,12 -41,10 +39,11 @@@ import org.apache.cassandra.db.filter.C
import org.apache.cassandra.db.marshal.*;
import org.apache.cassandra.db.partitions.*;
import org.apache.cassandra.db.rows.*;
-import org.apache.cassandra.db.filter.ColumnFilter;
-import org.apache.cassandra.db.view.View;
-import org.apache.cassandra.exceptions.ConfigurationException;
import org.apache.cassandra.exceptions.InvalidRequestException;
- import org.apache.cassandra.exceptions.StartupException;
+import org.apache.cassandra.service.reads.SpeculativeRetryPolicy;
+import org.apache.cassandra.schema.ColumnMetadata.ClusteringOrder;
+import org.apache.cassandra.schema.Keyspaces.KeyspacesDiff;
+import org.apache.cassandra.service.reads.repair.ReadRepairStrategy;
import org.apache.cassandra.transport.ProtocolVersion;
import org.apache.cassandra.utils.ByteBufferUtil;
import org.apache.cassandra.utils.FBUtilities;
@@@ -52,11 -53,9 +51,10 @@@
import static java.lang.String.format;
import static java.util.stream.Collectors.toList;
+import static java.util.stream.Collectors.toSet;
+
- import static org.apache.cassandra.cql3.ColumnIdentifier.maybeQuote;
import static org.apache.cassandra.cql3.QueryProcessor.executeInternal;
import static org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal;
-import static org.apache.cassandra.schema.CQLTypeParser.parse;
/**
* system_schema.* tables and methods for manipulating them.
@@@ -390,12 -377,12 +388,12 @@@ public final class SchemaKeyspac
private static ReadCommand getReadCommandForTableSchema(String
schemaTableName)
{
ColumnFamilyStore cfs = getSchemaCFS(schemaTableName);
-return PartitionRangeReadCommand.allDataRead(cfs.metadata,
FBUtilities.nowInSeconds());
+return PartitionRangeReadCommand.allDataRead(cfs.metadata(),
FBUtilities.nowInSeconds());
}
- static Collection convertSchemaToMutations()
-public static synchronized Collection convertSchemaToMutations()
++static synchronized Collection convertSchemaToMutations()
{
-Map mutationMap = new HashMap<>();
+Map mutationMap =
new HashMap<>();
for (String table : ALL)
convertSchemaToMutations(mutationMap, table);
diff --cc test/unit/org/apache/cassandra/schema/SchemaKeyspaceTest.java
index bf62203,19f06e5..c0c56aa
--- a/test/unit/org/apache/cassandra/schema/SchemaKeyspaceTest.java
+++ b/test/unit/org/apache/cassandra/schema/SchemaKeyspaceTest.java
@@@ -19,10 -19,16 +19,12 @@@
package org.apache.cassandra.schema;
import java.io.IOException;
+ import java.lang.reflect.Method;
+ import java.lang.reflect.Modifier;
import java.nio.ByteBuffer;
-import java.util.ArrayList;
-import java.util.Collection;
import java.util.Collections;
import java.util.HashSet;
-import java.util.List;
import java.util.Set;
-import java.util.UUID;
import com.google.common.collect.ImmutableMap;
@@@ -61,7 -94,55 +63,18 @@@ public class SchemaKeyspaceTes
SchemaLoader.standardCFMD(KEYSPACE1,
CF_STANDARD1));
}
+ /** See CASSANDRA-16856. Make sure schema pulls are synchronized to
prevent concurrent schema pull/writes
+ *
+ * @throws Exception
+ */
+ @Test
+ public void testSchemaPullSynchoricity() throws Exception
+ {
+ Method method =
SchemaKeyspace.class.getDeclaredMethod("convertSchemaToMutations");
+ assertTrue(Modifier.isSynchronized(method.getModifiers()));
+ }
+
@Test
-public void testThriftConversion() throws Exception
-{
-CfDef cfDef = new
CfDef().setDefault_validation_class(AsciiType.class.getCanonicalName())
- .setComment("Test comment")
- .setColumn_metadata(columnDefs)
- .setKeyspace(KEYSPACE1)
- .setName(CF_STANDARD1);
-
-// convert Thrift to CFMetaData
-CFMetaData cfMetaData = ThriftConversion.fromThrift(cfDef);
-
-CfDef thriftCfDef = new CfDef();
-thriftCfDef.keyspace = KEYSPACE1;
-thriftCfDef.name
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository.
bereng pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 058182025931e6b508d70fa9cfd294c7c860b185
Merge: 304deea f80b177
Author: Bereng
AuthorDate: Thu Aug 19 07:38:41 2021 +0200
Merge branch 'cassandra-4.0' into trunk
src/java/org/apache/cassandra/schema/SchemaKeyspace.java| 4 +---
.../org/apache/cassandra/schema/SchemaKeyspaceTest.java | 13 +
2 files changed, 14 insertions(+), 3 deletions(-)
diff --cc test/unit/org/apache/cassandra/schema/SchemaKeyspaceTest.java
index bf62203,c0c56aa..44fb2c0
--- a/test/unit/org/apache/cassandra/schema/SchemaKeyspaceTest.java
+++ b/test/unit/org/apache/cassandra/schema/SchemaKeyspaceTest.java
@@@ -61,6 -63,17 +63,17 @@@ public class SchemaKeyspaceTes
SchemaLoader.standardCFMD(KEYSPACE1,
CF_STANDARD1));
}
+ /** See CASSANDRA-16856. Make sure schema pulls are synchronized to
prevent concurrent schema pull/writes
- *
- * @throws Exception
- */
-@Test
-public void testSchemaPullSynchoricity() throws Exception
-{
-Method method =
SchemaKeyspace.class.getDeclaredMethod("convertSchemaToMutations");
-assertTrue(Modifier.isSynchronized(method.getModifiers()));
-}
++*
++* @throws Exception
++*/
++ @Test
++ public void testSchemaPullSynchoricity() throws Exception
++ {
++ Method method =
SchemaKeyspace.class.getDeclaredMethod("convertSchemaToMutations");
++ assertTrue(Modifier.isSynchronized(method.getModifiers()));
++ }
+
@Test
public void testConversionsInverses() 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 (433274b -> f80b177)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 433274b Merge branch cassandra-3.11 into cassandra-4.0 new 23b61a5 Prevent broken concurrent schema pulls new f80b177 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: src/java/org/apache/cassandra/schema/SchemaKeyspace.java| 4 +--- .../org/apache/cassandra/schema/SchemaKeyspaceTest.java | 13 + 2 files changed, 14 insertions(+), 3 deletions(-) - 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&focusedCommentId=17401388#comment-17401388 ] Tatu Saloranta commented on CASSANDRA-16855: One benchmark that seems quite relevant : [https://github.com/fabienrenaud/java-json-benchmark] It includes Jackson 2.10 as well as jsonsimple (in some places mentioned as "simplejson") – latter for just first 2 cases as it only supports non-POJO reading/writing (scalars, Lists, Maps) and not POJOs. Benchmark is based on jmh and seems quite solid; it is written by someone other than author of either of json libraries (may be author of dsl-json/jsoniter, not 100% sure; but someone familiar with the domain). :) Results suggest, fwtw, Jackson to be 2-3x faster at reading and 5x faster at writing of the stuff tested. > 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-16364) Joining nodes simultaneously with auto_bootstrap:false can cause token collision
[
https://issues.apache.org/jira/browse/CASSANDRA-16364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401387#comment-17401387
]
Roman Chyla commented on CASSANDRA-16364:
-
I was about to object, but before that I went to check again – and so now, i'm
getting the same error even with auto_bootstrap:true – while in the morning it
was working; it's haphazard and seemingly random, sorry for the noise
> Joining nodes simultaneously with auto_bootstrap:false can cause token
> collision
>
>
> Key: CASSANDRA-16364
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16364
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Paulo Motta
>Priority: Normal
> Fix For: 4.0.x
>
>
> While raising a 6-node ccm cluster to test 4.0-beta4, 2 nodes chosen the same
> tokens using the default {{allocate_tokens_for_local_rf}}. However they both
> succeeded bootstrap with colliding tokens.
> We were familiar with this issue from CASSANDRA-13701 and CASSANDRA-16079,
> and the workaround to fix this is to avoid parallel bootstrap when using
> {{allocate_tokens_for_local_rf}}.
> However, since this is the default behavior, we should try to detect and
> prevent this situation when possible, since it can break users relying on
> parallel bootstrap behavior.
> I think we could prevent this as following:
> 1. announce intent to bootstrap via gossip (ie. add node on gossip without
> token information)
> 2. wait for gossip to settle for a longer period (ie. ring delay)
> 3. allocate tokens (if multiple bootstrap attempts are detected, tie break
> via node-id)
> 4. broadcast tokens and move on with bootstrap
--
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&focusedCommentId=17401386#comment-17401386 ] Tatu Saloranta commented on CASSANDRA-16855: I added that one unit tests to (try to) ensure that `StatsPrinter` behavior did not change (there was one special case wrt NaNs). Coverage for other aspects is probably more limited, at least direct tests. As to performance I would expect Jackson to at least be not-slower and likely faster (based on benchmarking I have done over the years) but would not expect differences to necessarily surface to higher level tests. JSON processing is probably not big enough part of cpu load for that. I can find links to external tests but not sure they would help with specific usage. But if it was easy enough, could probably add `jmh` based tests for one of aspects. > 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-16829) WEBSITE - August 2021 updates
[ https://issues.apache.org/jira/browse/CASSANDRA-16829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16829: --- Fix Version/s: 4.0.1 Source Control Link: https://github.com/apache/cassandra-website/commit/18e52d17b1571a14a0b80ce9b9ec2af55feeca42 https://github.com/apache/cassandra-website/commit/5dc53ee58ce539723299beef5bc7890234767f59 Resolution: Fixed Status: Resolved (was: Ready to Commit) Slack discussions on this deployment [here|https://the-asf.slack.com/archives/C01RY1LUPD5/p1629217427037700] to [here|https://the-asf.slack.com/archives/C01RY1LUPD5/p1629320656067800]. > WEBSITE - August 2021 updates > - > > Key: CASSANDRA-16829 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16829 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Assignee: Paul Au >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.1, 4.0 > > Attachments: Apache Cassandra Antora Site Updates.zip > > > Updates to be made to the website that include: > * add blog post: Apache-Cassandra-4.0-Overview.adoc to pages/blog > * added Apache Cassandra 4.0 Overview card to blog page > * If unable to post on August 6, 2021, the above will need an edit to publish > dates > * added case study for Stibo Systems to case studies page > * add 4.0-overview-1.png and 4.0-overview-2.png to images/blog > * add stibo-systems.png to images/companies > * instagram.*png* to replace instagram.*jpg* in images/companies > * corrected logo for Instagram and added Stibo Systems logo to home page index > * corrected logo for Instagram and added Stibo Systems logo to case studies > page -- 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-16829) WEBSITE - August 2021 updates
[ https://issues.apache.org/jira/browse/CASSANDRA-16829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16829: --- Status: Ready to Commit (was: Review In Progress) > WEBSITE - August 2021 updates > - > > Key: CASSANDRA-16829 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16829 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Assignee: Paul Au >Priority: Normal > Labels: pull-request-available > Fix For: 4.0 > > Attachments: Apache Cassandra Antora Site Updates.zip > > > Updates to be made to the website that include: > * add blog post: Apache-Cassandra-4.0-Overview.adoc to pages/blog > * added Apache Cassandra 4.0 Overview card to blog page > * If unable to post on August 6, 2021, the above will need an edit to publish > dates > * added case study for Stibo Systems to case studies page > * add 4.0-overview-1.png and 4.0-overview-2.png to images/blog > * add stibo-systems.png to images/companies > * instagram.*png* to replace instagram.*jpg* in images/companies > * corrected logo for Instagram and added Stibo Systems logo to home page index > * corrected logo for Instagram and added Stibo Systems logo to case studies > page -- 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-16829) WEBSITE - August 2021 updates
[ https://issues.apache.org/jira/browse/CASSANDRA-16829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16829: --- Status: Review In Progress (was: Patch Available) > WEBSITE - August 2021 updates > - > > Key: CASSANDRA-16829 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16829 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Assignee: Paul Au >Priority: Normal > Labels: pull-request-available > Fix For: 4.0 > > Attachments: Apache Cassandra Antora Site Updates.zip > > > Updates to be made to the website that include: > * add blog post: Apache-Cassandra-4.0-Overview.adoc to pages/blog > * added Apache Cassandra 4.0 Overview card to blog page > * If unable to post on August 6, 2021, the above will need an edit to publish > dates > * added case study for Stibo Systems to case studies page > * add 4.0-overview-1.png and 4.0-overview-2.png to images/blog > * add stibo-systems.png to images/companies > * instagram.*png* to replace instagram.*jpg* in images/companies > * corrected logo for Instagram and added Stibo Systems logo to home page index > * corrected logo for Instagram and added Stibo Systems logo to case studies > page -- 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-16829) WEBSITE - August 2021 updates
[ https://issues.apache.org/jira/browse/CASSANDRA-16829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16829: --- Status: Patch Available (was: In Progress) Pushed [18e52d17b1571a14a0b80ce9b9ec2af55feeca42|https://github.com/apache/cassandra-website/commit/18e52d17b1571a14a0b80ce9b9ec2af55feeca42] and [5dc53ee58ce539723299beef5bc7890234767f59|https://github.com/apache/cassandra-website/commit/5dc53ee58ce539723299beef5bc7890234767f59] > WEBSITE - August 2021 updates > - > > Key: CASSANDRA-16829 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16829 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Assignee: Paul Au >Priority: Normal > Labels: pull-request-available > Fix For: 4.0 > > Attachments: Apache Cassandra Antora Site Updates.zip > > > Updates to be made to the website that include: > * add blog post: Apache-Cassandra-4.0-Overview.adoc to pages/blog > * added Apache Cassandra 4.0 Overview card to blog page > * If unable to post on August 6, 2021, the above will need an edit to publish > dates > * added case study for Stibo Systems to case studies page > * add 4.0-overview-1.png and 4.0-overview-2.png to images/blog > * add stibo-systems.png to images/companies > * instagram.*png* to replace instagram.*jpg* in images/companies > * corrected logo for Instagram and added Stibo Systems logo to home page index > * corrected logo for Instagram and added Stibo Systems logo to case studies > page -- 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-16865) Avoid logging full stack trace when index summary redistribution is cancelled
[ https://issues.apache.org/jira/browse/CASSANDRA-16865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-16865: -- Fix Version/s: 4.0.x > Avoid logging full stack trace when index summary redistribution is cancelled > - > > Key: CASSANDRA-16865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16865 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.0.x > > > When a compaction process is interrupted in an expected fashion, we don't > need to dump full stack. Clutters up the logs. -- 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-16866) Harden PrunableArrayQueue in the face of failures
[ https://issues.apache.org/jira/browse/CASSANDRA-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-16866: -- Test and Documentation Plan: Add tests to PrunableArrayQueueTest to ensure correctness in the face of unreliable inputs. No documentation change needed. Status: Patch Available (was: Open) > Harden PrunableArrayQueue in the face of failures > - > > Key: CASSANDRA-16866 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16866 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.0.x > > > We've seen AssertionErrors in internode messaging deserialization lead to a > property violation w/PrunableArrayQueue having null objects remaining present > in the queue. We should harden the PAQ against cases like this and improve > test coverage for exception handling as applicable. -- 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-16761) New Cassandra Website and Documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-16761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380763#comment-17380763
]
Michael Semb Wever edited comment on CASSANDRA-16761 at 8/18/21, 8:45 PM:
--
the antora built version of the new website design is on staging:
https://cassandra.staged.apache.org/
following manual steps were required, after the antora generation…
{code}
# push to staging, after having built with antora
git switch asf-staging
# copy everything to content/ directory
cp -r site-content/build/html/* content/
# move around the in-tree docs
rm -fR content/doc/4.0 content/doc/4.0.0 content/doc/3.11 content/doc/3.11.11
content/doc/stable content/doc/latest
cp -r content/Cassandra/3.11 content/doc/3.11.11
mv content/Cassandra/3.11 content/doc/
cp -r content/Cassandra/4.0 content/doc/4.0.0
cp -r content/Cassandra/4.0 content/doc/stable
cp -r content/Cassandra/4.0 content/doc/latest
mv content/Cassandra/4.0 content/doc/
# update the .htaccess file
nano content/.htaccess
# remove hardcoded domain name
for f in $(rg -l "https://cassandra.apache.org/"; content/_) ; do sed -i ''
's/https:\/\/cassandra.apache.org\//\//g' $f ; done
git add content
git commit content
git push origin asf-staging
{code}
The {{.htaccess}} addition is
{code}
RedirectMatch 301 "^/$" "/_/index.html"
RewriteCond %{REQUEST_URI} !^/doc/.*
RewriteCond %{REQUEST_URI} ^(.*)/$
RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
# temp – while in-tree antora are building to /Cassandra/
RewriteCond %{REQUEST_URI} !^/doc/.*
RewriteCond %{REQUEST_URI} ^/Cassandra/(.*)$
RewriteRule ^/?Cassandra/(.*)$ /doc/$1 [R=301,L]
# development in-tree docs have been moved to cassandra-website
RewriteCond %{REQUEST_URI} ^/doc/latest/development/(.+).html [NC]
RewriteRule ^/?doc/latest/development/(.+).html$ /_/development/$1.html
[R=301,L]
# redirects to new antora in-tree docs
RewriteCond %{REQUEST_URI} !^/doc/latest/index.html [NC]
RewriteCond %{REQUEST_URI} !^/doc/latest/cassandra [NC]
RewriteRule ^/?doc/latest/(.+)$ /doc/latest/cassandra/$1 [R=301,L]
RewriteCond %{REQUEST_URI} !^/doc/stable/index.html [NC]
RewriteCond %{REQUEST_URI} !^/doc/stable/cassandra [NC]
RewriteRule ^/?doc/stable/(.+)$ /doc/stable/cassandra/$1 [R=301,L]
RewriteCond %{REQUEST_URI} !^/doc/4.0/index.html [NC]
RewriteCond %{REQUEST_URI} !^/doc/4.0/cassandra [NC]
RewriteRule ^/?doc/4.0/(.+)$ /doc/4.0/cassandra/$1 [R=301,L]
RewriteCond %{REQUEST_URI} !^/doc/3.11/index.html [NC]
RewriteCond %{REQUEST_URI} !^/doc/3.11/cassandra [NC]
RewriteRule ^/?doc/3.11/(.+)$ /doc/3.11/cassandra/$1 [R=301,L]
{code}
was (Author: michaelsembwever):
the antora built version of the new website design is on staging:
https://cassandra.staged.apache.org/
following manual steps were required, after the antora generation…
{code}
# push to staging, after having built with antora
git switch asf-staging
# copy everything to content/ directory
cp -r site-content/build/html/* content/
# update the .htaccess file
nano content/.htaccess
# remove hardcoded domain name
for f in $(rg -l "https://cassandra.apache.org/"; content/_) ; do sed -i ''
's/https:\/\/cassandra.apache.org\//\//g' $f ; done
git add content
git commit content
git push origin asf-staging
{code}
The {{.htaccess}} addition is
{code}
RedirectMatch 301 "^/$" "/_/index.html"
RewriteCond %{REQUEST_URI} !^/doc/.*
RewriteCond %{REQUEST_URI} ^(.*)/$
RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
# development in-tree docs have been moved to cassandra-website
RewriteCond %{REQUEST_URI} ^/doc/latest/development/(.+).html [NC]
RewriteRule ^/?doc/latest/development/(.+).html$ /_/development/$1.html
[R=301,L]
# redirects to new antora in-tree docs
RewriteCond %{REQUEST_URI} !^/doc/latest/index.html [NC]
RewriteCond %{REQUEST_URI} !^/doc/latest/cassandra [NC]
RewriteRule ^/?doc/latest/(.+)$ /doc/latest/cassandra/$1 [R=301,L]
RewriteCond %{REQUEST_URI} !^/doc/stable/index.html [NC]
RewriteCond %{REQUEST_URI} !^/doc/stable/cassandra [NC]
RewriteRule ^/?doc/stable/(.+)$ /doc/stable/cassandra/$1 [R=301,L]
RewriteCond %{REQUEST_URI} !^/doc/4.0/index.html [NC]
RewriteCond %{REQUEST_URI} !^/doc/4.0/cassandra [NC]
RewriteRule ^/?doc/4.0/(.+)$ /doc/4.0/cassandra/$1 [R=301,L]
RewriteCond %{REQUEST_URI} !^/doc/3.11/index.html [NC]
RewriteCond %{REQUEST_URI} !^/doc/3.11/cassandra [NC]
RewriteRule ^/?doc/3.11/(.+)$ /doc/3.11/cassandra/$1 [R=301,L]
{code}
> New Cassandra Website and Documentation
> ---
>
> Key: CASSANDRA-16761
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16761
> Project: Cassandra
> Issue Type: Epic
> Components: Documentation/Website
>Reporter: Anthony Grasso
>Assignee: Anthony Grasso
>Priority: High
> Fix For: 4.0.x
>
>
> This epic captures the work asso
[jira] [Updated] (CASSANDRA-16866) Harden PrunableArrayQueue in the face of failures
[ https://issues.apache.org/jira/browse/CASSANDRA-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-16866: -- Change Category: Operability Complexity: Normal Fix Version/s: 4.0.x Status: Open (was: Triage Needed) > Harden PrunableArrayQueue in the face of failures > - > > Key: CASSANDRA-16866 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16866 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.0.x > > > We've seen AssertionErrors in internode messaging deserialization lead to a > property violation w/PrunableArrayQueue having null objects remaining present > in the queue. We should harden the PAQ against cases like this and improve > test coverage for exception handling as applicable. -- 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] 02/02: ninja-fix: hack in /Cassandra/ to /doc/ redirect
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
commit 5dc53ee58ce539723299beef5bc7890234767f59
Author: mck
AuthorDate: Wed Aug 18 18:30:45 2021 +0200
ninja-fix: hack in /Cassandra/ to /doc/ redirect
---
content/.htaccess | 5 +
1 file changed, 5 insertions(+)
diff --git a/content/.htaccess b/content/.htaccess
index d8b7945..d38e3f4 100755
--- a/content/.htaccess
+++ b/content/.htaccess
@@ -9,6 +9,11 @@ RewriteCond %{REQUEST_URI} !^/doc/.*
RewriteCond %{REQUEST_URI} ^(.*)/$
RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
+# temp – while in-tree antora are building to /Cassandra/
+RewriteCond %{REQUEST_URI} !^/doc/.*
+RewriteCond %{REQUEST_URI} ^/Cassandra/(.*)$
+RewriteRule ^/?Cassandra/(.*)$ /doc/$1 [R=301,L]
+
# development in-tree docs have been moved to cassandra-website
RewriteCond %{REQUEST_URI} ^/doc/latest/development/(.+).html [NC]
RewriteRule ^/?doc/latest/development/(.+).html$ /_/development/$1.html
[R=301,L]
-
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 (1aa3280 -> 5dc53ee)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard 1aa3280 ninja-fix: hack in /Cassandra/ to /doc/ redirect discard 7ae3955 latest changes from Paul Au (17th August 2021) new 18e52d1 latest changes from Paul Au (17th August 2021) new 5dc53ee ninja-fix: hack in /Cassandra/ to /doc/ redirect This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (1aa3280) \ N -- N -- N refs/heads/asf-staging (5dc53ee) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. 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: content/_/apachecon_cfp.html | 48 +- content/_/blog.html| 48 +- content/_/blog/Apache-Cassandra-4.0-Overview.html | 54 +- content/_/blog/Apache-Cassandra-4.0-is-Here.html | 50 +- .../Apache-Cassandra-Changelog-1-October-2020.html | 52 +- ...Apache-Cassandra-Changelog-2-December-2020.html | 52 +- .../Apache-Cassandra-Changelog-3-January-2021.html | 52 +- ...Apache-Cassandra-Changelog-4-February-2021.html | 52 +- .../Apache-Cassandra-Changelog-5-March-2021.html | 52 +- .../Apache-Cassandra-Changelog-6-April-2021.html | 52 +- .../Apache-Cassandra-Changelog-7-May-2021.html | 54 +- .../Apache-Cassandra-Changelog-8-June-2021.html| 56 +- .../Apache-Cassandra-Changelog-9-August-2021.html | 52 +- .../_/blog/Apache-Cassandra-Usage-Report-2020.html | 50 +- .../blog/Audit-Logging-in-Apache-Cassandra-4.html | 50 +- .../Cassandra-and-Kubernetes-SIG-Update-2.html | 50 +- ...andra-and-Kubernetes-SIG-Update-and-Survey.html | 50 +- ...ty-with-5x-Faster-Streaming-in-Cassandra-4.html | 50 +- ...ra's-Internals-with-Property-based-Testing.html | 50 +- ...-Zero-Copy-Streaming-in-Apache-Cassandra-4.html | 50 +- ...che-Cassandras-Front-Door-and-Backpressure.html | 50 +- ...assandra-4-Beta-Battle-Tested-From-Day-One.html | 52 +- .../_/blog/Introducing-Transient-Replication.html | 50 +- content/_/blog/Join-Cassandra-GSoC-2021.html | 52 +- ...ced-for-April-28-Cassandra-4.0-World-Party.html | 50 +- ...nced-for-April-28-Cassandra-40-World-Party.html | 50 +- content/_/blog/Testing-Apache-Cassandra-4.html | 50 +- content/_/blog/Upgrade-Advisory.html | 50 +- content/_/blog/World-Party.html| 50 +- content/_/bugs.html| 48 +- content/_/case-studies.html| 48 +- content/_/case-studies/backblaze.html | 48 +- content/_/cassandra-basics.html| 48 +- content/_/community.html | 50 +- content/_/contactus.html | 60 +- content/_/development/ci.html | 48 +- content/_/development/code_style.html | 48 +- content/_/development/dependencies.html| 48 +- content/_/development/documentation.html | 52 +- content/_/development/gettingstarted.html | 48 +- content/_/development/how_to_commit.html | 48 +- content/_/development/how_to_review.html | 48 +- content/_/development/ide.html | 48 +- content/_/development/index.html | 52 +- content/_/development/patches.html | 48 +- content/_/development/release_process.html | 48 +- content/_/development/testing.html | 48 +- content/_/docdev/index.html| 48 +- content/_/download.html| 48 +- content/_/ecosystem.html | 48 +- content/_/glossary.html| 48 +- content/_/index.html | 48 +- content/_/native_protocol.html | 48 +- content/_/quickstart.html | 48 +- content/_/resources.html | 48 +- content/_/third-party.html | 48 +- content/search-index.js| 2 +- content/sitemap-Cassandra.xml | 840 ++--- content/sitemap-_.xml
[jira] [Commented] (CASSANDRA-16866) Harden PrunableArrayQueue in the face of failures
[ https://issues.apache.org/jira/browse/CASSANDRA-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401355#comment-17401355 ] Josh McKenzie commented on CASSANDRA-16866: --- ||Item||Link|| |j8 test|[link|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/42/workflows/f252bb6c-603f-4ec8-bf35-7c9d824d18a5]| |j11 test|[link|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/42/workflows/63c341a7-0236-474a-ae65-a75259b50c15]| |branch|[link|https://github.com/apache/cassandra/compare/trunk...josh-mckenzie:CASSANDRA-16866?expand=1]| replaceAliveHost squawking on jdk11 jvm dtest; prevalent on other branches and unrelated to this change. > Harden PrunableArrayQueue in the face of failures > - > > Key: CASSANDRA-16866 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16866 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > We've seen AssertionErrors in internode messaging deserialization lead to a > property violation w/PrunableArrayQueue having null objects remaining present > in the queue. We should harden the PAQ against cases like this and improve > test coverage for exception handling as applicable. -- 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-16066) Create tooling and update repository layout to render new website
[
https://issues.apache.org/jira/browse/CASSANDRA-16066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17393398#comment-17393398
]
Michael Semb Wever edited comment on CASSANDRA-16066 at 8/18/21, 8:38 PM:
--
This work is already being used to deploy to the {{asf-staging}} and
{{asf-site}} branches.
Specifying the following steps:
{code}
cd cassandra-website
git switch anthony/CASSANDRA-16066_full_history
git pull
git switch paul/new-website
git pull
git rebase anthony/CASSANDRA-16066_full_history
./run.sh website-ui bundle
./run.sh website build -i -b cassandra:trunk,cassandra-3.11 -u
cassandra:https://github.com/polandll/cassandra.git -z
./site-ui/build/ui-bundle.zip
open site-content/build/html/Project/home.html
# see parent ticket for further steps required before pushing to staging
{code}
Review Feedback:
- the doap.rdf file must remain (see why
[here|https://projects.apache.org/doap.html])
- the {{run.sh}} is intense. Could this have been python, or a makefile, for
the sake of encouraging contributors to it? (not a blocker)
- in {{site-content/Dockerfile}} the defaults should be
{code}
ENV ANTORA_SITE_URL="/"
ENV ANTORA_SITE_START_PAGE="_"
{code}
- currently the pull request contains 70 commits, many check-point and many
duplicated commits. It should only be ~6 commits, like the
{{anthony/CASSANDRA\-16066}} branch.
was (Author: michaelsembwever):
This work is already being used to deploy to the {{asf-staging}} and
{{asf-site}} branches.
Specifying the following steps:
{code}
cd cassandra-website
git switch anthony/CASSANDRA-16066_full_history
git pull
git switch paul/new-website
git pull
git rebase anthony/CASSANDRA-16066_full_history
./run.sh website-ui bundle
./run.sh website build -i -b cassandra:trunk,cassandra-3.11 -u
cassandra:https://github.com/polandll/cassandra.git -z
./site-ui/build/ui-bundle.zip
open site-content/build/html/Project/home.html
{code}
Review Feedback:
- the doap.rdf file must remain (see why
[here|https://projects.apache.org/doap.html])
- the {{run.sh}} is intense. Could this have been python, or a makefile, for
the sake of encouraging contributors to it? (not a blocker)
- in {{site-content/Dockerfile}} the defaults should be
{code}
ENV ANTORA_SITE_URL="/"
ENV ANTORA_SITE_START_PAGE="_"
{code}
- currently the pull request contains 70 commits, many check-point and many
duplicated commits. It should only be ~6 commits, like the
{{anthony/CASSANDRA\-16066}} branch.
> Create tooling and update repository layout to render new website
> -
>
> Key: CASSANDRA-16066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16066
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Anthony Grasso
>Assignee: Anthony Grasso
>Priority: Normal
> Labels: pull-request-available
> Attachments: image-2020-09-05-13-24-13-606.png,
> image-2020-09-06-07-17-14-705.png
>
>
> *We want to modernise the way the website is built*
> Rework the cassandra-website repository to generate a UI bundle containing
> resources that Antora will use when generating the Cassandra documents and
> website.
> *The existing method is starting to become dated*
> The documentation and website templates are currently in markdown format.
> Sphinx is used to generate the Cassandra documentation and Jekyll generates
> the website content. One of the major issues with the existing website
> tooling is that the live preview server (render site as it is being updated)
> is really slow. There is a preview server that is really fast, however it is
> unable to detect changes to the content and render automatically.
> *We are migrating the docs to be rendered with Antora*
> The work in CASSANDRA-16029 is converting the document templates to AsciiDoc
> format. Sphinx is being replaced by Antora to generate the documentation
> content. This change has two advantages:
> * More flexibility if the Apache Cassandra documentation look and feel needs
> to be updated or redesigned.
> * More modern look and feel to the documentation.
> *We can use Antora to generate the website as well*
> Antora could also be used to generate the Cassandra website content. As
> suggested on the [mailing
> list|https://www.mail-archive.com/dev@cassandra.apache.org/msg15577.html]
> this would require the existing markdown templates to be converted to
> AsciiDoc as well.
> *Antora needs a UI bundle to style content*
> For Antora to generate the document content and potentially the website
> content it requires a UI bundle (ui-bundle.zip). The UI bundle contains the
> HTML templates (layouts, partials, and helpers), CSS, JavaScript, fonts, and
> (site-wide) images. As such, it pro
[jira] [Comment Edited] (CASSANDRA-16066) Create tooling and update repository layout to render new website
[
https://issues.apache.org/jira/browse/CASSANDRA-16066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17393398#comment-17393398
]
Michael Semb Wever edited comment on CASSANDRA-16066 at 8/18/21, 8:38 PM:
--
This work is already being used to deploy to the {{asf-staging}} and
{{asf-site}} branches.
Specifying the following steps:
{code}
cd cassandra-website
git switch anthony/CASSANDRA-16066_full_history
git pull
git switch paul/new-website
git pull
git rebase anthony/CASSANDRA-16066_full_history
./run.sh website-ui bundle
./run.sh website build -i -b cassandra:trunk,cassandra-3.11 -u
cassandra:https://github.com/polandll/cassandra.git -z
./site-ui/build/ui-bundle.zip
open site-content/build/html/Project/home.html
{code}
Review Feedback:
- the doap.rdf file must remain (see why
[here|https://projects.apache.org/doap.html])
- the {{run.sh}} is intense. Could this have been python, or a makefile, for
the sake of encouraging contributors to it? (not a blocker)
- in {{site-content/Dockerfile}} the defaults should be
{code}
ENV ANTORA_SITE_URL="/"
ENV ANTORA_SITE_START_PAGE="_"
{code}
- currently the pull request contains 70 commits, many check-point and many
duplicated commits. It should only be ~6 commits, like the
{{anthony/CASSANDRA\-16066}} branch.
was (Author: michaelsembwever):
This work is already being used to deploy to the {{asf-staging}} and
{{asf-site}} branches.
Specifying the following steps:
{code}
cd cassandra-website
git switch anthony/CASSANDRA-16066_full_history
git pull
git switch paul/new-website
git pull
git rebase anthony/CASSANDRA-16066_full_history
./run.sh website-ui bundle
./run.sh website build -z ./site-ui/build/ui-bundle.zip
open site-content/build/html/Project/home.html
{code}
Review Feedback:
- the doap.rdf file must remain (see why
[here|https://projects.apache.org/doap.html])
- the {{run.sh}} is intense. Could this have been python, or a makefile, for
the sake of encouraging contributors to it? (not a blocker)
- in {{site-content/Dockerfile}} the defaults should be
{code}
ENV ANTORA_SITE_URL="/"
ENV ANTORA_SITE_START_PAGE="_"
{code}
- currently the pull request contains 70 commits, many check-point and many
duplicated commits. It should only be ~6 commits, like the
{{anthony/CASSANDRA\-16066}} branch.
> Create tooling and update repository layout to render new website
> -
>
> Key: CASSANDRA-16066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16066
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Anthony Grasso
>Assignee: Anthony Grasso
>Priority: Normal
> Labels: pull-request-available
> Attachments: image-2020-09-05-13-24-13-606.png,
> image-2020-09-06-07-17-14-705.png
>
>
> *We want to modernise the way the website is built*
> Rework the cassandra-website repository to generate a UI bundle containing
> resources that Antora will use when generating the Cassandra documents and
> website.
> *The existing method is starting to become dated*
> The documentation and website templates are currently in markdown format.
> Sphinx is used to generate the Cassandra documentation and Jekyll generates
> the website content. One of the major issues with the existing website
> tooling is that the live preview server (render site as it is being updated)
> is really slow. There is a preview server that is really fast, however it is
> unable to detect changes to the content and render automatically.
> *We are migrating the docs to be rendered with Antora*
> The work in CASSANDRA-16029 is converting the document templates to AsciiDoc
> format. Sphinx is being replaced by Antora to generate the documentation
> content. This change has two advantages:
> * More flexibility if the Apache Cassandra documentation look and feel needs
> to be updated or redesigned.
> * More modern look and feel to the documentation.
> *We can use Antora to generate the website as well*
> Antora could also be used to generate the Cassandra website content. As
> suggested on the [mailing
> list|https://www.mail-archive.com/dev@cassandra.apache.org/msg15577.html]
> this would require the existing markdown templates to be converted to
> AsciiDoc as well.
> *Antora needs a UI bundle to style content*
> For Antora to generate the document content and potentially the website
> content it requires a UI bundle (ui-bundle.zip). The UI bundle contains the
> HTML templates (layouts, partials, and helpers), CSS, JavaScript, fonts, and
> (site-wide) images. As such, it provides both the visual theme and user
> interactions for the documentation. Effectively the UI bundle is the
> templates and styling that are applied to the documentatio
[jira] [Created] (CASSANDRA-16866) Harden PrunableArrayQueue in the face of failures
Josh McKenzie created CASSANDRA-16866: - Summary: Harden PrunableArrayQueue in the face of failures Key: CASSANDRA-16866 URL: https://issues.apache.org/jira/browse/CASSANDRA-16866 Project: Cassandra Issue Type: Improvement Components: Messaging/Internode Reporter: Josh McKenzie Assignee: Josh McKenzie We've seen AssertionErrors in internode messaging deserialization lead to a property violation w/PrunableArrayQueue having null objects remaining present in the queue. We should harden the PAQ against cases like this and improve test coverage for exception handling as applicable. -- 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] 02/02: ninja-fix: hack in /Cassandra/ to /doc/ redirect
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
commit 1aa3280333f17909b9a7c35400e8459e990707a9
Author: mck
AuthorDate: Wed Aug 18 18:30:45 2021 +0200
ninja-fix: hack in /Cassandra/ to /doc/ redirect
---
content/.htaccess | 5 +
1 file changed, 5 insertions(+)
diff --git a/content/.htaccess b/content/.htaccess
index d8b7945..d38e3f4 100755
--- a/content/.htaccess
+++ b/content/.htaccess
@@ -9,6 +9,11 @@ RewriteCond %{REQUEST_URI} !^/doc/.*
RewriteCond %{REQUEST_URI} ^(.*)/$
RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
+# temp – while in-tree antora are building to /Cassandra/
+RewriteCond %{REQUEST_URI} !^/doc/.*
+RewriteCond %{REQUEST_URI} ^/Cassandra/(.*)$
+RewriteRule ^/?Cassandra/(.*)$ /doc/$1 [R=301,L]
+
# development in-tree docs have been moved to cassandra-website
RewriteCond %{REQUEST_URI} ^/doc/latest/development/(.+).html [NC]
RewriteRule ^/?doc/latest/development/(.+).html$ /_/development/$1.html
[R=301,L]
-
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 (ad28197 -> 1aa3280)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard ad28197 ninja-fix: hack in /Cassandra/ to /doc/ redirect discard 2c38aea Paul Au's new changes, plus rebuild of in-tree docs discard 86d5e6a latest changes from Paul Au (17th August 2021) new 7ae3955 latest changes from Paul Au (17th August 2021) new 1aa3280 ninja-fix: hack in /Cassandra/ to /doc/ redirect This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (ad28197) \ N -- N -- N refs/heads/asf-staging (1aa3280) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. 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: content/_/blog.html| 6 +- content/_/blog/Apache-Cassandra-4.0-Overview.html | 4 +- .../Apache-Cassandra-Changelog-9-August-2021.html | 10 +- content/_/blog/Upgrade-Advisory.html | 2 +- content/_/contactus.html | 12 +- content/_/download.html| 8 +- content/search-index.js| 2 +- content/sitemap.xml| 234 - 8 files changed, 243 insertions(+), 35 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16865) Avoid logging full stack trace when index summary redistribution is cancelled
[ https://issues.apache.org/jira/browse/CASSANDRA-16865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-16865: -- Test and Documentation Plan: No need for extra documentation, and standard existing test coverage should suffice. Status: Patch Available (was: In Progress) > Avoid logging full stack trace when index summary redistribution is cancelled > - > > Key: CASSANDRA-16865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16865 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > When a compaction process is interrupted in an expected fashion, we don't > need to dump full stack. Clutters up the logs. -- 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-16865) Avoid logging full stack trace when index summary redistribution is cancelled
[ https://issues.apache.org/jira/browse/CASSANDRA-16865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-16865: -- Change Category: Operability Complexity: Low Hanging Fruit Status: Open (was: Triage Needed) > Avoid logging full stack trace when index summary redistribution is cancelled > - > > Key: CASSANDRA-16865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16865 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > When a compaction process is interrupted in an expected fashion, we don't > need to dump full stack. Clutters up the logs. -- 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-16865) Avoid logging full stack trace when index summary redistribution is cancelled
[ https://issues.apache.org/jira/browse/CASSANDRA-16865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401339#comment-17401339 ] Josh McKenzie commented on CASSANDRA-16865: --- Have a replaceAliveHost failure on j11 tests which is showing up on multiple tickets/branches and is unrelated to this change. ||Item||Link|| |j8 test|[link|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/41/workflows/9a5d36dd-cc4e-4452-9297-2cb0cf88f56f]| |j11 test|[link|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/41/workflows/5f05f7a4-ea0c-4d66-a0d5-3a0be4041251]| |branch|[link|https://github.com/apache/cassandra/compare/trunk...josh-mckenzie:CASSANDRA-16865?expand=1]| > Avoid logging full stack trace when index summary redistribution is cancelled > - > > Key: CASSANDRA-16865 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16865 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > When a compaction process is interrupted in an expected fashion, we don't > need to dump full stack. Clutters up the logs. -- 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-16865) Avoid logging full stack trace when index summary redistribution is cancelled
Josh McKenzie created CASSANDRA-16865: - Summary: Avoid logging full stack trace when index summary redistribution is cancelled Key: CASSANDRA-16865 URL: https://issues.apache.org/jira/browse/CASSANDRA-16865 Project: Cassandra Issue Type: Improvement Components: Local/Compaction Reporter: Josh McKenzie Assignee: Josh McKenzie When a compaction process is interrupted in an expected fashion, we don't need to dump full stack. Clutters up the logs. -- 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&focusedCommentId=17401323#comment-17401323 ] Brandon Williams commented on CASSANDRA-16855: -- bq. I am wondering what behavioral/performance changes we might see This is an instance where having performance testing would be rather useful, but unfortunately we don't. > 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&focusedCommentId=17401323#comment-17401323 ] Brandon Williams edited comment on CASSANDRA-16855 at 8/18/21, 7:35 PM: bq. I am wondering what behavioral/performance changes we might see This is an instance where having automated performance testing would be rather useful, but unfortunately we don't. was (Author: brandon.williams): bq. I am wondering what behavioral/performance changes we might see This is an instance where having performance testing would be rather useful, but unfortunately we don't. > 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&focusedCommentId=17401314#comment-17401314 ] Ekaterina Dimitrova commented on CASSANDRA-16855: - While it makes sense for the non-supported library to be changed, I am wondering what behavioral/performance changes we might see. I see changes around the CommitLogDescriptor for example... [~mck] brought the same topic on another ticket. I confirmed with him what are ways that this was handled in the past on the project. It seems a JMH microbench test class might be good option as long as values were in the ball park of real use-cases. > 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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16851: --- Reviewers: Ekaterina Dimitrova, Michael Semb Wever (was: Ekaterina Dimitrova) > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Time Spent: 0.5h > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401303#comment-17401303 ] Michael Semb Wever edited comment on CASSANDRA-16851 at 8/18/21, 6:47 PM: -- Agree to applying to release branches from 3.0 up. (Though I have a comment about performance in the PR.) was (Author: michaelsembwever): Agree to applying to release branches from 3.0 up. > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Time Spent: 0.5h > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401303#comment-17401303 ] Michael Semb Wever commented on CASSANDRA-16851: Agree to applying to release branches from 3.0 up. > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-11418) Nodetool status should reflect hibernate/replacing states
[ https://issues.apache.org/jira/browse/CASSANDRA-11418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401281#comment-17401281 ] Brandon Williams edited comment on CASSANDRA-11418 at 8/18/21, 6:32 PM: [Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-11418], [circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-11418] and [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1042/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1042/pipeline]. This patch shows the active replacing node as 'UR' during the replacement process. This seemed to make the most sense to me, but I'm open to bikeshedding there. was (Author: brandon.williams): [Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-11418], [circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-11418] and [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1042/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1042/pipeline]. > Nodetool status should reflect hibernate/replacing states > - > > Key: CASSANDRA-11418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11418 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability, Tool/nodetool >Reporter: Joel Knighton >Assignee: Brandon Williams >Priority: Low > Fix For: 4.x > > Attachments: cassandra-11418-trunk > > > Currently, the four options for state in nodetool status are > joining/leaving/moving/normal. > Joining nodes are determined based on bootstrap tokens, leaving nodes are > based on leaving endpoints in TokenMetadata, moving nodes are based on moving > endpoints in TokenMetadata. > This means that a node will appear in normal state when going through a > bootstrap with flag replace_address, which can be confusing to operators. > We should add another state for hibernation/replacing to make this visible. > This will require a way to get a list of all hibernating endpoints. -- 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-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401298#comment-17401298 ] Tatu Saloranta commented on CASSANDRA-16851: Security aspect wrt CVE is probably a good one regarding move from 2.9 to even just 2.10 – practically all Jackson CVEs for past 2.5 years were for polymorphic deserialization and are not applicable to 2.10 or beyond. While these CVEs were already not applicable to Cassandra usage (as per [https://cowtowncoder.medium.com/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062),] vuln tracking tools are very simplistic and cannot really express something that is only applicable to specific usage scenarios, and will happily indicate Cassandra requiring update to latest Jackson 2.9 patch. Or, TL;DNR; moving out of 2.9 will stop any new jackson polymorphic deser CVEs. This would probably be nice for C* 3.x as well as 4.x. Choice of Jackson dependency to use can also be different between 3.x and 4.x, although with relatively simple usage it is probably simpler from support perspective to update both to Jackson 2.12. > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.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] [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: Status: Review In Progress (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] [Commented] (CASSANDRA-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401293#comment-17401293 ] Ekaterina Dimitrova commented on CASSANDRA-16851: - The CI run looks good to me, I didn't see any new failures. I didn't see any changed behavior in the newer versions that might affect some of our usages of Jackson. I am wondering whether to update the previous Cassandra versions at least to a supported minor version? I see security and other important issues were addressed. WDYT? [~mck], I am also interested into your opinion for older versions. Plus we need second committer if you have the time :) > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.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-16663) Request-Based Native Transport Rate-Limiting
[ https://issues.apache.org/jira/browse/CASSANDRA-16663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401292#comment-17401292 ] Josh McKenzie commented on CASSANDRA-16663: --- Nothing further here. Those #'s from the ccm stress run look good. > Request-Based Native Transport Rate-Limiting > > > Key: CASSANDRA-16663 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16663 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.x > > Time Spent: 14h 40m > Remaining Estimate: 0h > > Together, CASSANDRA-14855, CASSANDRA-15013, and CASSANDRA-15519 added support > for a runtime-configurable, per-coordinator limit on the number of bytes > allocated for concurrent requests over the native protocol. It supports > channel back-pressure by default, and optionally supports throwing > OverloadedException if that is requested in the relevant connection’s STARTUP > message. > This can be an effective tool to prevent the coordinator from running out of > memory, but it may not correspond to how expensive a queries are or provide a > direct conceptual mapping to how users think about request capacity. I > propose adding the option of request-based (or perhaps more correctly > message-based) back-pressure, coexisting with (and reusing the logic that > supports) the current bytes-based back-pressure. > _We can roll this forward in phases_, where the server’s cost accounting > becomes more accurate, we segment limits by operation type/keyspace/etc., and > the client/driver reacts more intelligently to (especially non-back-pressure) > overload, _but something minimally viable could look like this_: > 1.) Reuse most of the existing logic in Limits, et al. to support a simple > per-coordinator limit only on native transport requests per second. Under > this limit will be CQL reads and writes, but also auth requests, prepare > requests, and batches. This is obviously simplistic, and it does not account > for the variation in cost between individual queries, but even a fixed cost > model should be useful in aggregate. > * If the client specifies THROW_ON_OVERLOAD in its STARTUP message at > connection time, a breach of the per-node limit will result in an > OverloadedException being propagated to the client, and the server will > discard the request. > * If THROW_ON_OVERLOAD is not specified, the server will stop consuming > messages from the channel/socket, which should back-pressure the client, > while the message continues to be processed. > 2.) This limit is infinite by default (or simply disabled), and can be > enabled via the YAML config or JMX at runtime. (It might be cleaner to have a > no-op rate limiter that's used when the feature is disabled entirely.) > 3.) The current value of the limit is available via JMX, and metrics around > coordinator operations/second are already available to compare against it. > 4.) Any interaction with existing byte-based limits will intersect. (i.e. A > breach of any limit, bytes or request-based, will actuate back-pressure or > OverloadedExceptions.) > In this first pass, explicitly out of scope would be any work on the > client/driver side. > In terms of validation/testing, our biggest concern with anything that adds > overhead on a very hot path is performance. In particular, we want to fully > understand how the client and server perform along two axes constituting 4 > scenarios. Those are a.) whether or not we are breaching the request limit > and b.) whether the server is throwing on overload at the behest of the > client. Having said that, query execution should dwarf the cost of limit > accounting. -- 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-11418) Nodetool status should reflect hibernate/replacing states
[ https://issues.apache.org/jira/browse/CASSANDRA-11418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401281#comment-17401281 ] Brandon Williams commented on CASSANDRA-11418: -- [Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-11418], [circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-11418] and [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1042/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1042/pipeline]. > Nodetool status should reflect hibernate/replacing states > - > > Key: CASSANDRA-11418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11418 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability, Tool/nodetool >Reporter: Joel Knighton >Assignee: Brandon Williams >Priority: Low > Fix For: 4.x > > Attachments: cassandra-11418-trunk > > > Currently, the four options for state in nodetool status are > joining/leaving/moving/normal. > Joining nodes are determined based on bootstrap tokens, leaving nodes are > based on leaving endpoints in TokenMetadata, moving nodes are based on moving > endpoints in TokenMetadata. > This means that a node will appear in normal state when going through a > bootstrap with flag replace_address, which can be confusing to operators. > We should add another state for hibernation/replacing to make this visible. > This will require a way to get a list of all hibernating endpoints. -- 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&focusedCommentId=17401280#comment-17401280 ] Ekaterina Dimitrova commented on CASSANDRA-16725: - My only point was that I am with Mick on this - "_Ideally reviewers should remove themselves from the list if they see that they won't be returning to provide such a +1_" I have one question for you, are you going to add the person as a reviewer? To me both "yes" and "no" doesn't feel good. # in case of a "yes" - someone is merit without doing the job maybe or a critical bug appears and people think that this person approved the buggy code... (unfortunately, sometimes things happen, distributed systems are complex) # in case of a "no" - the person put some time and efforts and maybe they were even doing still something in the background but you didn't know and you just skipped them. It's not about being adult in this case I think. Also, please, consider that many of the engineers in the community come with different background and are experts in different areas of the codebase so it is possible to get the best of all worlds if you hear more people. :) As a wise man once said ([~mck] :)) - "The beauty of OSS is in the teamwork" One more time, thank you for all the great work! I think this work will be really appreciated by our users. > 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: 15h 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
[jira] [Comment Edited] (CASSANDRA-16663) Request-Based Native Transport Rate-Limiting
[ https://issues.apache.org/jira/browse/CASSANDRA-16663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401275#comment-17401275 ] Caleb Rackliffe edited comment on CASSANDRA-16663 at 8/18/21, 5:40 PM: --- [~benedict] [~jmckenzie] I think I'm ready to squash, rebase, check for clean tests, and commit here. Let me know if either of you has any remaining concerns. (Note that I've provided a brief documentation plan above.) was (Author: maedhroz): [~benedict] [~jmckenzie] I think I'm ready to squash, rebase, and commit here. Let me know if either of you has any remaining concerns. (Note that I've provided a brief documentation plan above.) > Request-Based Native Transport Rate-Limiting > > > Key: CASSANDRA-16663 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16663 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.x > > Time Spent: 14h 40m > Remaining Estimate: 0h > > Together, CASSANDRA-14855, CASSANDRA-15013, and CASSANDRA-15519 added support > for a runtime-configurable, per-coordinator limit on the number of bytes > allocated for concurrent requests over the native protocol. It supports > channel back-pressure by default, and optionally supports throwing > OverloadedException if that is requested in the relevant connection’s STARTUP > message. > This can be an effective tool to prevent the coordinator from running out of > memory, but it may not correspond to how expensive a queries are or provide a > direct conceptual mapping to how users think about request capacity. I > propose adding the option of request-based (or perhaps more correctly > message-based) back-pressure, coexisting with (and reusing the logic that > supports) the current bytes-based back-pressure. > _We can roll this forward in phases_, where the server’s cost accounting > becomes more accurate, we segment limits by operation type/keyspace/etc., and > the client/driver reacts more intelligently to (especially non-back-pressure) > overload, _but something minimally viable could look like this_: > 1.) Reuse most of the existing logic in Limits, et al. to support a simple > per-coordinator limit only on native transport requests per second. Under > this limit will be CQL reads and writes, but also auth requests, prepare > requests, and batches. This is obviously simplistic, and it does not account > for the variation in cost between individual queries, but even a fixed cost > model should be useful in aggregate. > * If the client specifies THROW_ON_OVERLOAD in its STARTUP message at > connection time, a breach of the per-node limit will result in an > OverloadedException being propagated to the client, and the server will > discard the request. > * If THROW_ON_OVERLOAD is not specified, the server will stop consuming > messages from the channel/socket, which should back-pressure the client, > while the message continues to be processed. > 2.) This limit is infinite by default (or simply disabled), and can be > enabled via the YAML config or JMX at runtime. (It might be cleaner to have a > no-op rate limiter that's used when the feature is disabled entirely.) > 3.) The current value of the limit is available via JMX, and metrics around > coordinator operations/second are already available to compare against it. > 4.) Any interaction with existing byte-based limits will intersect. (i.e. A > breach of any limit, bytes or request-based, will actuate back-pressure or > OverloadedExceptions.) > In this first pass, explicitly out of scope would be any work on the > client/driver side. > In terms of validation/testing, our biggest concern with anything that adds > overhead on a very hot path is performance. In particular, we want to fully > understand how the client and server perform along two axes constituting 4 > scenarios. Those are a.) whether or not we are breaching the request limit > and b.) whether the server is throwing on overload at the behest of the > client. Having said that, query execution should dwarf the cost of limit > accounting. -- 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-16663) Request-Based Native Transport Rate-Limiting
[ https://issues.apache.org/jira/browse/CASSANDRA-16663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401275#comment-17401275 ] Caleb Rackliffe commented on CASSANDRA-16663: - [~benedict] [~jmckenzie] I think I'm ready to squash, rebase, and commit here. Let me know if either of you has any remaining fears. (Note that I've provided a brief documentation plan above.) > Request-Based Native Transport Rate-Limiting > > > Key: CASSANDRA-16663 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16663 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.x > > Time Spent: 14h 40m > Remaining Estimate: 0h > > Together, CASSANDRA-14855, CASSANDRA-15013, and CASSANDRA-15519 added support > for a runtime-configurable, per-coordinator limit on the number of bytes > allocated for concurrent requests over the native protocol. It supports > channel back-pressure by default, and optionally supports throwing > OverloadedException if that is requested in the relevant connection’s STARTUP > message. > This can be an effective tool to prevent the coordinator from running out of > memory, but it may not correspond to how expensive a queries are or provide a > direct conceptual mapping to how users think about request capacity. I > propose adding the option of request-based (or perhaps more correctly > message-based) back-pressure, coexisting with (and reusing the logic that > supports) the current bytes-based back-pressure. > _We can roll this forward in phases_, where the server’s cost accounting > becomes more accurate, we segment limits by operation type/keyspace/etc., and > the client/driver reacts more intelligently to (especially non-back-pressure) > overload, _but something minimally viable could look like this_: > 1.) Reuse most of the existing logic in Limits, et al. to support a simple > per-coordinator limit only on native transport requests per second. Under > this limit will be CQL reads and writes, but also auth requests, prepare > requests, and batches. This is obviously simplistic, and it does not account > for the variation in cost between individual queries, but even a fixed cost > model should be useful in aggregate. > * If the client specifies THROW_ON_OVERLOAD in its STARTUP message at > connection time, a breach of the per-node limit will result in an > OverloadedException being propagated to the client, and the server will > discard the request. > * If THROW_ON_OVERLOAD is not specified, the server will stop consuming > messages from the channel/socket, which should back-pressure the client, > while the message continues to be processed. > 2.) This limit is infinite by default (or simply disabled), and can be > enabled via the YAML config or JMX at runtime. (It might be cleaner to have a > no-op rate limiter that's used when the feature is disabled entirely.) > 3.) The current value of the limit is available via JMX, and metrics around > coordinator operations/second are already available to compare against it. > 4.) Any interaction with existing byte-based limits will intersect. (i.e. A > breach of any limit, bytes or request-based, will actuate back-pressure or > OverloadedExceptions.) > In this first pass, explicitly out of scope would be any work on the > client/driver side. > In terms of validation/testing, our biggest concern with anything that adds > overhead on a very hot path is performance. In particular, we want to fully > understand how the client and server perform along two axes constituting 4 > scenarios. Those are a.) whether or not we are breaching the request limit > and b.) whether the server is throwing on overload at the behest of the > client. Having said that, query execution should dwarf the cost of limit > accounting. -- 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-16663) Request-Based Native Transport Rate-Limiting
[ https://issues.apache.org/jira/browse/CASSANDRA-16663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401275#comment-17401275 ] Caleb Rackliffe edited comment on CASSANDRA-16663 at 8/18/21, 5:38 PM: --- [~benedict] [~jmckenzie] I think I'm ready to squash, rebase, and commit here. Let me know if either of you has any remaining concerns. (Note that I've provided a brief documentation plan above.) was (Author: maedhroz): [~benedict] [~jmckenzie] I think I'm ready to squash, rebase, and commit here. Let me know if either of you has any remaining fears. (Note that I've provided a brief documentation plan above.) > Request-Based Native Transport Rate-Limiting > > > Key: CASSANDRA-16663 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16663 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.x > > Time Spent: 14h 40m > Remaining Estimate: 0h > > Together, CASSANDRA-14855, CASSANDRA-15013, and CASSANDRA-15519 added support > for a runtime-configurable, per-coordinator limit on the number of bytes > allocated for concurrent requests over the native protocol. It supports > channel back-pressure by default, and optionally supports throwing > OverloadedException if that is requested in the relevant connection’s STARTUP > message. > This can be an effective tool to prevent the coordinator from running out of > memory, but it may not correspond to how expensive a queries are or provide a > direct conceptual mapping to how users think about request capacity. I > propose adding the option of request-based (or perhaps more correctly > message-based) back-pressure, coexisting with (and reusing the logic that > supports) the current bytes-based back-pressure. > _We can roll this forward in phases_, where the server’s cost accounting > becomes more accurate, we segment limits by operation type/keyspace/etc., and > the client/driver reacts more intelligently to (especially non-back-pressure) > overload, _but something minimally viable could look like this_: > 1.) Reuse most of the existing logic in Limits, et al. to support a simple > per-coordinator limit only on native transport requests per second. Under > this limit will be CQL reads and writes, but also auth requests, prepare > requests, and batches. This is obviously simplistic, and it does not account > for the variation in cost between individual queries, but even a fixed cost > model should be useful in aggregate. > * If the client specifies THROW_ON_OVERLOAD in its STARTUP message at > connection time, a breach of the per-node limit will result in an > OverloadedException being propagated to the client, and the server will > discard the request. > * If THROW_ON_OVERLOAD is not specified, the server will stop consuming > messages from the channel/socket, which should back-pressure the client, > while the message continues to be processed. > 2.) This limit is infinite by default (or simply disabled), and can be > enabled via the YAML config or JMX at runtime. (It might be cleaner to have a > no-op rate limiter that's used when the feature is disabled entirely.) > 3.) The current value of the limit is available via JMX, and metrics around > coordinator operations/second are already available to compare against it. > 4.) Any interaction with existing byte-based limits will intersect. (i.e. A > breach of any limit, bytes or request-based, will actuate back-pressure or > OverloadedExceptions.) > In this first pass, explicitly out of scope would be any work on the > client/driver side. > In terms of validation/testing, our biggest concern with anything that adds > overhead on a very hot path is performance. In particular, we want to fully > understand how the client and server perform along two axes constituting 4 > scenarios. Those are a.) whether or not we are breaching the request limit > and b.) whether the server is throwing on overload at the behest of the > client. Having said that, query execution should dwarf the cost of limit > accounting. -- 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-16663) Request-Based Native Transport Rate-Limiting
[
https://issues.apache.org/jira/browse/CASSANDRA-16663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401274#comment-17401274
]
Caleb Rackliffe commented on CASSANDRA-16663:
-
Here are the latest {{tlp-stress}} results from a 3-node ccm cluster with RF=1,
in a format similar to the single-node tests above. The general pattern here is
that we look at three scenarios:
1.) A request rate that falls just short of the aggregate 3000 requests/second
that should overload the cluster (3 coordinators each with a limit of 1000).
2.) A request rate that just breaches the the aggregate 3000 requests/second.
3.) A request rate that wildly overruns (by a factor of two) the aggregate 3000
requests/second.
{noformat}
bin/tlp-stress run --compaction "{'class':
'org.apache.cassandra.db.compaction.LeveledCompactionStrategy',
'tombstone_compaction_interval': '864000', 'tombstone_threshold': '0.2'}"
--compression "{'sstable_compression': 'LZ4Compressor'}" --replication
"{'class': 'SimpleStrategy', 'replication_factor' : 1}" --cl LOCAL_ONE
--readrate 1.0 --partitions 1 --populate 1 --rate [2900|3300|6000]
--duration 5m --client-retry disable --protocol [4|5] KeyValue
{noformat}
*Native Protocol V4, Backpressure on Overload*
|Aggregate Rate Limit (requests/second)|Client-Requested Rate|Client p99
(millis)|Client-Observed Rate|
|3000|2900|0.38|2884.28|
|3000|3300| 103.33 |2970.01|
|3000|6000| 102.93 |2957.44|
*Native Protocol V4, Throw on Overload*
|Aggregate Rate Limit (requests/second)|Client-Requested Rate|Client p99
(millis)|Client-Observed Rate|Errors/Second|
|1000|2900|0.39|2884.31|0|
|1000|3300|0.3|3278.02|299.85|
|3000|6000|0.62|5882.59|2959|
*Native Protocol V5, Backpressure on Overload*
|Aggregate Rate Limit (requests/second)|Client-Requested Rate|Client p99
(millis)|Client-Observed Rate|
|3000|2900|0.3|2883.95|
|3000|3300|102.25|2948.42|
|3000|6000|102.31|2961.74|
*Native Protocol V5, Throw on Overload*
|Aggregate Rate Limit (requests/second)|Client-Requested Rate|Client p99
(millis)|Client-Observed Rate|Errors/Second|
|1000|2900|0.28|2884.29 |0|
|1000|3300|0.37|3278.02|299.72|
|3000|6000|11.83|5883.29|2958.85|
(Note: {{tlp-stress}} counts errors as completed requests, so the
"Client-Observed Rate" above includes them.)
tl;dr V4 and V5 are consistent with each other and consistent with expectations
for the two overload handling modes.
More specifically, in the throwing case, we nominally meet the requested
throughput from the client with minimal latency degradation _just above_ the
limit. The number of errors is almost exactly the limit subtracted from
client-observed rate, as errors do not consume permits.
In the backpressure case, as expected, our client-observed rate does adhere
very closely to the limit, with higher latencies representing higher queuing
times rather than errors.
> Request-Based Native Transport Rate-Limiting
>
>
> Key: CASSANDRA-16663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16663
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 14h 40m
> Remaining Estimate: 0h
>
> Together, CASSANDRA-14855, CASSANDRA-15013, and CASSANDRA-15519 added support
> for a runtime-configurable, per-coordinator limit on the number of bytes
> allocated for concurrent requests over the native protocol. It supports
> channel back-pressure by default, and optionally supports throwing
> OverloadedException if that is requested in the relevant connection’s STARTUP
> message.
> This can be an effective tool to prevent the coordinator from running out of
> memory, but it may not correspond to how expensive a queries are or provide a
> direct conceptual mapping to how users think about request capacity. I
> propose adding the option of request-based (or perhaps more correctly
> message-based) back-pressure, coexisting with (and reusing the logic that
> supports) the current bytes-based back-pressure.
> _We can roll this forward in phases_, where the server’s cost accounting
> becomes more accurate, we segment limits by operation type/keyspace/etc., and
> the client/driver reacts more intelligently to (especially non-back-pressure)
> overload, _but something minimally viable could look like this_:
> 1.) Reuse most of the existing logic in Limits, et al. to support a simple
> per-coordinator limit only on native transport requests per second. Under
> this limit will be CQL reads and writes, but also auth requests, prepare
> requests, and batches. This is obviously simplistic, and it does not account
> for the variation in cost between individual queries, but even a fixe
[jira] [Commented] (CASSANDRA-16621) Replace spinAsserts code with Awaitility code
[ https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401259#comment-17401259 ] Jogesh Anand commented on CASSANDRA-16621: -- [~bereng] & [~adelapena] +1. thanks so much and lgtm. (y) > Replace spinAsserts code with Awaitility code > - > > Key: CASSANDRA-16621 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16621 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Jogesh Anand >Priority: Normal > Labels: low-hanging-fruit > Fix For: 4.0.x > > > Currently spinAsserts does a similar thing to Awaitility which is being used > more and more. We have now 2 ways of doing the same thing so it would be good > to consolidate -- 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&focusedCommentId=17401256#comment-17401256 ] Stefan Miklosovic commented on CASSANDRA-16725: --- Thanks Mick. Ekaterina - I fully agree. On the other hand, I think we are all grown adults here and I would not be personally "shocked" or "offended" (not saying anybody is, just saying) if a commit happens without my explicit approval if it is just waived off by other competent people. I completely get that the review of others matter, I reiterate that I understand that, but waiting for that to happen is in a lot of cases just a formality if a versatile and experienced developer like you already says it is good to go ... In other words I just want to avoid bureacracy and saving time for people in general (even though I am not sure where I am rushing it awyway but that is my problem to work on). I ll merge tomorrow. Thanks everybody. > 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: 15h 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
[jira] [Updated] (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:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16721:
Fix Version/s: 4.x
> 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: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0.x, 4.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
[cassandra-website] 01/01: ninja-fix: hack in /Cassandra/ to /doc/ redirect
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
commit ad28197cb1791bb495c0bec186bc76f6deeb823d
Author: mck
AuthorDate: Wed Aug 18 18:30:45 2021 +0200
ninja-fix: hack in /Cassandra/ to /doc/ redirect
---
content/.htaccess | 5 +
1 file changed, 5 insertions(+)
diff --git a/content/.htaccess b/content/.htaccess
index d8b7945..d38e3f4 100755
--- a/content/.htaccess
+++ b/content/.htaccess
@@ -9,6 +9,11 @@ RewriteCond %{REQUEST_URI} !^/doc/.*
RewriteCond %{REQUEST_URI} ^(.*)/$
RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
+# temp – while in-tree antora are building to /Cassandra/
+RewriteCond %{REQUEST_URI} !^/doc/.*
+RewriteCond %{REQUEST_URI} ^/Cassandra/(.*)$
+RewriteRule ^/?Cassandra/(.*)$ /doc/$1 [R=301,L]
+
# development in-tree docs have been moved to cassandra-website
RewriteCond %{REQUEST_URI} ^/doc/latest/development/(.+).html [NC]
RewriteRule ^/?doc/latest/development/(.+).html$ /_/development/$1.html
[R=301,L]
-
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 (b1edee1 -> ad28197)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard b1edee1 ninja-fix: hack in /Cassandra/ to /doc/ redirect new ad28197 ninja-fix: hack in /Cassandra/ to /doc/ redirect This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (b1edee1) \ N -- N -- N refs/heads/asf-staging (ad28197) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. 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: content/.htaccess | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - 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: ninja-fix: hack in /Cassandra/ to /doc/ redirect
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 b1edee1 ninja-fix: hack in /Cassandra/ to /doc/ redirect
b1edee1 is described below
commit b1edee1513f395babf3a80b7f5c7ce81ba7d253a
Author: mck
AuthorDate: Wed Aug 18 18:30:45 2021 +0200
ninja-fix: hack in /Cassandra/ to /doc/ redirect
---
content/.htaccess | 5 +
1 file changed, 5 insertions(+)
diff --git a/content/.htaccess b/content/.htaccess
index d8b7945..f48b8be 100755
--- a/content/.htaccess
+++ b/content/.htaccess
@@ -9,6 +9,11 @@ RewriteCond %{REQUEST_URI} !^/doc/.*
RewriteCond %{REQUEST_URI} ^(.*)/$
RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
+# temp – while in-tree antora are building to /Cassandra/
+RewriteCond %{REQUEST_URI} !^/doc/.*
+RewriteCond %{REQUEST_URI} ^/Cassandra/(.*)$
+RewriteRule ^/Cassandra/(.*)$ /doc/$1 [R=301,L]
+
# development in-tree docs have been moved to cassandra-website
RewriteCond %{REQUEST_URI} ^/doc/latest/development/(.+).html [NC]
RewriteRule ^/?doc/latest/development/(.+).html$ /_/development/$1.html
[R=301,L]
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (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&focusedCommentId=17401177#comment-17401177
]
Sam Tunnicliffe commented on CASSANDRA-16721:
-
Your approach is a great improvement, makes a lot more sense for
{{ReadExecutionController}} to handle {{RepairedDataInfo}}. The only
non-obvious thing I noticed is that the sub-controllers for index reads should
probably not inherit the tracking flag, just always make it false. It should be
safe and not inefficient either way, but it just doesn't make sense for a read
of the index table to be set to track.
> 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: Caleb Rackliffe
>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] [Updated] (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:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16721:
Status: In Progress (was: Patch Available)
> 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: Caleb Rackliffe
>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] [Updated] (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:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16721:
Status: Patch Available (was: Review In Progress)
> 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: Caleb Rackliffe
>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] [Updated] (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:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16721:
Reviewers: Caleb Rackliffe, Sam Tunnicliffe (was: Caleb Rackliffe)
> 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] [Updated] (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:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16721:
Authors: Caleb Rackliffe, Sam Tunnicliffe (was: Sam Tunnicliffe)
> 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-16862) Fix flaky test DatabaseDescriptorRefTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401173#comment-17401173
]
Brandon Williams commented on CASSANDRA-16862:
--
bq. reproduce Brandon Williams's failure.
I think you misunderstood, I'm the one who doesn't run it in an IDE and it
doesn't fail for me. :)
> 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] [Assigned] (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:all-tabpanel
]
Caleb Rackliffe reassigned CASSANDRA-16721:
---
Assignee: Caleb Rackliffe (was: Sam Tunnicliffe)
> 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: Caleb Rackliffe
>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-16364) Joining nodes simultaneously with auto_bootstrap:false can cause token collision
[
https://issues.apache.org/jira/browse/CASSANDRA-16364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401171#comment-17401171
]
Brandon Williams commented on CASSANDRA-16364:
--
bq. I have double checked, nuked the cluster; removed `auto_bootstrap:true`
from cassandra.yaml (so that a default is used); redeployed - and I'm seeing
the same issue; i.e. I can reproduce it every time
auto_bootstrap is not in the yaml by default; it relies on the default true
behavior. In any case I don't think it's a surprise that removing it had no
effect and you can reproduce.
> Joining nodes simultaneously with auto_bootstrap:false can cause token
> collision
>
>
> Key: CASSANDRA-16364
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16364
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Paulo Motta
>Priority: Normal
> Fix For: 4.0.x
>
>
> While raising a 6-node ccm cluster to test 4.0-beta4, 2 nodes chosen the same
> tokens using the default {{allocate_tokens_for_local_rf}}. However they both
> succeeded bootstrap with colliding tokens.
> We were familiar with this issue from CASSANDRA-13701 and CASSANDRA-16079,
> and the workaround to fix this is to avoid parallel bootstrap when using
> {{allocate_tokens_for_local_rf}}.
> However, since this is the default behavior, we should try to detect and
> prevent this situation when possible, since it can break users relying on
> parallel bootstrap behavior.
> I think we could prevent this as following:
> 1. announce intent to bootstrap via gossip (ie. add node on gossip without
> token information)
> 2. wait for gossip to settle for a longer period (ie. ring delay)
> 3. allocate tokens (if multiple bootstrap attempts are detected, tie break
> via node-id)
> 4. broadcast tokens and move on with bootstrap
--
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-16364) Joining nodes simultaneously with auto_bootstrap:false can cause token collision
[
https://issues.apache.org/jira/browse/CASSANDRA-16364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401149#comment-17401149
]
Roman Chyla commented on CASSANDRA-16364:
-
Could this be playing any role?
[https://github.com/apache/cassandra/blob/8acbbe042b236c6948845ecd7af093c6f0fa3e4b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java#L2440]
I have double checked, nuked the cluster; removed `auto_bootstrap:true` from
cassandra.yaml (so that a default is used); redeployed - and I'm seeing the
same issue; i.e. I can reproduce it every time. I have a vanilla Docker
Cassandra 4.0.0 – they make almost no changes to cassandra dist; I grabbed
[https://github.com/apache/cassandra/blob/cassandra-4.0/conf/cassandra.yaml]
the only changes from stock config I have is:
num_tokens = 8
allocate_tokens_for_local_replication_factor: 2
#auto_bootstrap: true
# {{delete cassandra cluster (and removed all data from all nodes)}}
{{[rcluster] rchyla@tp1:/dvt/workspace/projects/it$ k delete sts cassandra}}
{{statefulset.apps "cassandra" deleted}}
# {{modify config (verify pods are gone)}}
{{[rcluster] rchyla@tp1:/dvt/workspace/projects/it$ k apply -f
deployments/cassandra/configmap.yaml }}
{{configmap/cassandra-config configured}}
{{[rcluster] rchyla@tp1:/dvt/workspace/projects/it$ k get po}}
{{NAME READY STATUS RESTARTS AGE}}
# {{ deploy again }}
{{[rcluster] rchyla@tp1:/dvt/workspace/projects/it$ k apply -f
deployments/cassandra/sts.yaml }}
{{statefulset.apps/cassandra created}}
# {{cassandra is initializing}}
{{[rcluster] rchyla@tp1:/dvt/workspace/projects/it$ k get po}}
{{NAME READY STATUS RESTARTS AGE}}
{{cassandra-0 1/1 Running 0 22s}}
{{cassandra-1 1/1 Running 0 21s}}
{{cassandra-2 1/1 Running 0 20s}}
{{cassandra-3 1/1 Running 0 18s}}
# {{the first failure comes 2m after startup; after 8m one of the nodes
restarted 4 times already (once I have observed it join the cluster overnight,
after maybe 1h - but that was once)}}
{{[rcluster] rchyla@tp1:/dvt/workspace/projects/it$ k get po -o wide}}
{{NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES}}
{{cassandra-0 1/1 Running 0 8m32s 10.96.59.213 rbox1 }}
{{cassandra-1 1/1 Running 0 8m31s 10.96.80.145 rbox2 }}
{{cassandra-2 1/1 Running 0 8m30s 10.96.70.86 rbox3 }}
{{cassandra-3 0/1 Error 4 8m28s 10.96.44.144 rbox4 }}
{{without auto_bootstrap:true}}
{{INFO [main] 2021-08-18 15:21:45,537 RangeStreamer.java:330 - Bootstrap:
range Full(/10.96.44.144:7000,(14089530831047523,784495759500208690]) exists on
Full(/10.96.70.86:7000,(14089530831047523,1554901988169369858]) for keyspace
system_authINFO [main] 2021-08-18 15:21:45,537 RangeStreamer.java:330 -
Bootstrap: range
Full(/10.96.44.144:7000,(14089530831047523,784495759500208690]) exists on
Full(/10.96.70.86:7000,(14089530831047523,1554901988169369858]) for keyspace
system_authException (java.lang.IllegalStateException) encountered during
startup: Multiple strict sources found for
Full(/10.96.44.144:7000,(9015306348701926784,-8983433729137907922]), sources:
[Full(/10.96.59.213:7000,(8567302352832209875,-8983433729137907922]),
Full(/10.96.70.86:7000,(8567302352832209875,-8983433729137907922])]java.lang.IllegalStateException:
Multiple strict sources found for
Full(/10.96.44.144:7000,(9015306348701926784,-8983433729137907922]), sources:
[Full(/10.96.59.213:7000,(8567302352832209875,-8983433729137907922]),
Full(/10.96.70.86:7000,(8567302352832209875,-8983433729137907922])] at
org.apache.cassandra.dht.RangeStreamer.calculateRangesToFetchWithPreferredEndpoints(RangeStreamer.java:542)
at
org.apache.cassandra.dht.RangeStreamer.calculateRangesToFetchWithPreferredEndpoints(RangeStreamer.java:408)
at org.apache.cassandra.dht.RangeStreamer.addRanges(RangeStreamer.java:327) at
org.apache.cassandra.dht.BootStrapper.bootstrap(BootStrapper.java:83) at
org.apache.cassandra.service.StorageService.startBootstrap(StorageService.java:1785)
at
org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1762)
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1056)
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1017)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:799)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:729)
at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:420)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:763)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:887)ERROR
[main] 2021-08-18 15:21:45,541 CassandraDaemon.java:909 - Exception
encountered during startup}}
> Joining nodes simultaneously with auto_bootstrap:false can cause token
> collision
> --
[jira] [Assigned] (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 reassigned CASSANDRA-16855: -- Assignee: Tatu Saloranta (was: Tatu Saloranta) > 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] [Assigned] (CASSANDRA-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tatu Saloranta reassigned CASSANDRA-16851: -- Assignee: Tatu Saloranta (was: Tatu Saloranta) > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.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] [Assigned] (CASSANDRA-16854) Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency
[ https://issues.apache.org/jira/browse/CASSANDRA-16854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tatu Saloranta reassigned CASSANDRA-16854: -- Assignee: Tatu Saloranta (was: Tatu Saloranta) > Exclude Jackson 1.x dependency that leaks via old hadoop-core dependency > > > Key: CASSANDRA-16854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16854 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.x > > Attachments: CASSANDRA-16854.patch > > > build.xml has a dependency for an old hadoop-core version (1.0.3). This is > likely needed for some Hadoop compatibility code under > `src/java/org/apache/cassandra/hadoop`. Since 1.0.3 was released in 2012, its > dependencies are very old; in particular it depends on "jackson-mapper-asl" > 1.0.1 (from 2009!). > An earlier issue CASSANDRA-15867 referenced this dependency as well (but did > not actually remove it for some reason, which marked as resolved). > Although `hadoop-core` dependency is marked as "provided" (and should then > not be included in distributed version) it seems best to avoid downloading it > during build to "build/lib/jars". This can be done by adding 2 exclusions for > "hadoop-core" and "hadoop-minicluster" dependencies in build.xml. > I will provide a patch. > I also tried updating "hadoop-core" to the latest public version (1.2.1), > which would have upgraded jackson-mapper-asl to 1.8.8, but that breaks the > build due to some other version incompatibility (asm, possibly). If anyone > wants to tackle that issue it could be a good follow-up task; "hadoop-core" > itself has been moved to "hadoop-client" it seems (and there's > "hadoop-commons" too... confusing). > -- 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&focusedCommentId=17401144#comment-17401144 ] Michael Semb Wever commented on CASSANDRA-16725: +1 > 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 50m > 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
[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&focusedCommentId=17401128#comment-17401128
]
Jon Meredith commented on CASSANDRA-16862:
--
It fails for me from inside IDEA
{noformat}
java.lang.AssertionError: thread started in clientInitialization
Expected :6
Actual :9
{noformat}
however this also passes for me
{code}
ant testsome -Dtest.name=org.apache.cassandra.config.DatabaseDescriptorRefTest
-Dtest.method=testDatabaseDescriptorRef
{code}
I suspect the issue is test runner setup for the fancy IDE. I wonder if it's
possible to detect running outside of the regular ant runner and just skip the
test in that case, though I'm interested if others can reproduce
[~brandon.williams]'s failure.
> 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&focusedCommentId=17401114#comment-17401114 ] Brandon Williams commented on CASSANDRA-16855: -- Looks good to me, no related failures. > 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] [Assigned] (CASSANDRA-11418) Nodetool status should reflect hibernate/replacing states
[ https://issues.apache.org/jira/browse/CASSANDRA-11418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-11418: Assignee: Brandon Williams (was: Shaurya Gupta) > Nodetool status should reflect hibernate/replacing states > - > > Key: CASSANDRA-11418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11418 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability, Tool/nodetool >Reporter: Joel Knighton >Assignee: Brandon Williams >Priority: Low > Fix For: 4.x > > Attachments: cassandra-11418-trunk > > > Currently, the four options for state in nodetool status are > joining/leaving/moving/normal. > Joining nodes are determined based on bootstrap tokens, leaving nodes are > based on leaving endpoints in TokenMetadata, moving nodes are based on moving > endpoints in TokenMetadata. > This means that a node will appear in normal state when going through a > bootstrap with flag replace_address, which can be confusing to operators. > We should add another state for hibernation/replacing to make this visible. > This will require a way to get a list of all hibernating endpoints. -- 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-16364) Joining nodes simultaneously with auto_bootstrap:false can cause token collision
[
https://issues.apache.org/jira/browse/CASSANDRA-16364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401095#comment-17401095
]
Brandon Williams commented on CASSANDRA-16364:
--
bq. It seems that `auto_bootstrap: true` is not a default
It is.
https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/config/Config.java#L72
> Joining nodes simultaneously with auto_bootstrap:false can cause token
> collision
>
>
> Key: CASSANDRA-16364
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16364
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Paulo Motta
>Priority: Normal
> Fix For: 4.0.x
>
>
> While raising a 6-node ccm cluster to test 4.0-beta4, 2 nodes chosen the same
> tokens using the default {{allocate_tokens_for_local_rf}}. However they both
> succeeded bootstrap with colliding tokens.
> We were familiar with this issue from CASSANDRA-13701 and CASSANDRA-16079,
> and the workaround to fix this is to avoid parallel bootstrap when using
> {{allocate_tokens_for_local_rf}}.
> However, since this is the default behavior, we should try to detect and
> prevent this situation when possible, since it can break users relying on
> parallel bootstrap behavior.
> I think we could prevent this as following:
> 1. announce intent to bootstrap via gossip (ie. add node on gossip without
> token information)
> 2. wait for gossip to settle for a longer period (ie. ring delay)
> 3. allocate tokens (if multiple bootstrap attempts are detected, tie break
> via node-id)
> 4. broadcast tokens and move on with bootstrap
--
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-12660) NIODataInputStreamTest - Function with an infinite loop
[ https://issues.apache.org/jira/browse/CASSANDRA-12660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-12660: --- Fix Version/s: (was: 3.11.x) (was: 4.x) (was: 3.0.x) (was: 2.2.x) 4.0.1 3.11.12 3.0.26 Source Control Link: https://github.com/apache/cassandra/commit/632790fd51ae9017fb0de16dbc25b739548ba54c Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed into 3.0 at 304deead2c4a6aa4576783120d12858459d69098 and merged into cassandra-3.11, cassandra-4.0 and trunk > NIODataInputStreamTest - Function with an infinite loop > --- > > Key: CASSANDRA-12660 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12660 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Testing >Reporter: Marianne Linhares Monteiro >Assignee: Arunkumar M >Priority: Low > Labels: easyfix, low-hanging-fruit > Fix For: 3.0.26, 3.11.12, 4.0.1 > > Attachments: 12660-3.9.txt, 12660-3.9.txt > > Original Estimate: 5m > Remaining Estimate: 5m > > Function with an infinite loop and not needed. > https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/io/util/NIODataInputStreamTest.java > - lines 97-101 > isOpen() -- 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-16364) Joining nodes simultaneously with auto_bootstrap:false can cause token collision
[
https://issues.apache.org/jira/browse/CASSANDRA-16364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401090#comment-17401090
]
Roman commented on CASSANDRA-16364:
---
I have hit the issue running 4.0 (inside k8s, therefore starting 4 instances in
parallel)
It seems that `auto_bootstrap: true` is not a default, as one of the comments
suggests. In my case, without the option, one machine has eventually (after 10
restarts) joined the cluster; but I also observed a situation when a cluster
was up for a day and one of the machines has restarted hundreds of times
(always with a token conflict)
With the `auto_boostrap: true` 4 instances are starting in parallel; and two of
them restart 1-2 times (due to a bootsrap conflict – but that seems to a
separate issue from the one above).
This was the error before `auto_bootsrap:true`
```
{{INFO [main] 2021-08-18 02:38:29,032 NetworkTopologyStrategy.java:88 -
Configured datacenter replicas are datacenter1:rf(2)}}{{INFO [main] 2021-08-18
02:38:29,034 TokenAllocatorFactory.java:44 - Using
ReplicationAwareTokenAllocator.}}{{INFO [main] 2021-08-18 02:38:29,122
TokenAllocation.java:106 - Selected tokens [-869047834665074658,
6571578339392131746, -5974523007943185192, -3644355145115701774,
3287046338630430582, -2401348872989035546, 1849708238101167874,
-4749797269495265510]}}{{INFO [main] 2021-08-18 02:38:29,129
StorageService.java:1619 - JOINING: sleeping 3 ms for pending range
setup}}{{INFO [main] 2021-08-18 02:38:59,130 StorageService.java:1619 -
JOINING: Starting to bootstrap...}}{{INFO [main] 2021-08-18 02:38:59,147
RangeStreamer.java:330 - Bootstrap: range
Full(/10.96.70.81:7000,(5801172110722970579,6571578339392131746]) exists on
Full(/10.96.44.142:7000,(5801172110722970579,7341984568061292914]) for keyspace
system_auth}}{{INFO [main] 2021-08-18 02:38:59,148 RangeStreamer.java:330 -
Bootstrap: range
Full(/10.96.70.81:7000,(-4092359140985418682,-3644355145115701774]) exists on
Full(/10.96.59.211:7000,(-4092359140985418682,-3196351149245984865]) for
keyspace system_auth}}{{INFO [main] 2021-08-18 02:38:59,148
RangeStreamer.java:330 - Bootstrap: range
Full(/10.96.70.81:7000,(-3196351149245984865,-2401348872989035546]) exists on
Full(/10.96.59.211:7000,(-3196351149245984865,-1606346596732086227]) for
keyspace system_auth}}{{INFO [main] 2021-08-18 02:38:59,148
RangeStreamer.java:330 - Bootstrap: range
Full(/10.96.70.81:7000,(990822151481071145,1849708238101167874]) exists on
Full(/10.96.44.142:7000,(990822151481071145,2708594324721264603]) for keyspace
system_auth}}{{INFO [main] 2021-08-18 02:38:59,148 RangeStreamer.java:330 -
Bootstrap: range
Full(/10.96.70.81:7000,(-1606346596732086227,-869047834665074658]) exists on
Full(/10.96.44.142:7000,(-1606346596732086227,-131749072598063088]) for
keyspace system_auth}}{{INFO [main] 2021-08-18 02:38:59,148
RangeStreamer.java:330 - Bootstrap: range
Full(/10.96.70.81:7000,(-6541810617881258046,-5974523007943185192]) exists on
Full(/10.96.59.211:7000,(-6541810617881258046,-5407235398005112337]) for
keyspace system_auth}}{{INFO [main] 2021-08-18 02:38:59,148
RangeStreamer.java:330 - Bootstrap: range
Full(/10.96.70.81:7000,(2708594324721264603,3287046338630430582]) exists on
Full(/10.96.59.211:7000,(2708594324721264603,3865498352539596562]) for keyspace
system_auth}}{{INFO [main] 2021-08-18 02:38:59,148 RangeStreamer.java:330 -
Bootstrap: range
Full(/10.96.70.81:7000,(-5407235398005112337,-4749797269495265510]) exists on
Full(/10.96.44.142:7000,(-5407235398005112337,-4092359140985418682]) for
keyspace system_auth}}{{java.lang.IllegalStateException: Multiple strict
sources found for
Full(/10.96.70.81:7000,(8312940956965586630,-9117317883097463910]), sources:
[Full(/10.96.44.142:7000,(8312940956965586630,-9117317883097463910]),
Full(/10.96.59.211:7000,(8312940956965586630,-9117317883097463910])]}}{{at
org.apache.cassandra.dht.RangeStreamer.calculateRangesToFetchWithPreferredEndpoints(RangeStreamer.java:542)}}{{at
org.apache.cassandra.dht.RangeStreamer.calculateRangesToFetchWithPreferredEndpoints(RangeStreamer.java:408)}}{{at
org.apache.cassandra.dht.RangeStreamer.addRanges(RangeStreamer.java:327)}}{{at
org.apache.cassandra.dht.BootStrapper.bootstrap(BootStrapper.java:83)}}{{at
org.apache.cassandra.service.StorageService.startBootstrap(StorageService.java:1785)}}{{at
org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1762)}}{{at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1056)}}{{at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1017)}}{{at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:799)}}{{at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:729)}}{{at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:42
[jira] [Updated] (CASSANDRA-12660) NIODataInputStreamTest - Function with an infinite loop
[ https://issues.apache.org/jira/browse/CASSANDRA-12660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-12660: --- Status: Ready to Commit (was: Review In Progress) > NIODataInputStreamTest - Function with an infinite loop > --- > > Key: CASSANDRA-12660 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12660 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Testing >Reporter: Marianne Linhares Monteiro >Assignee: Arunkumar M >Priority: Low > Labels: easyfix, low-hanging-fruit > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x > > Attachments: 12660-3.9.txt, 12660-3.9.txt > > Original Estimate: 5m > Remaining Estimate: 5m > > Function with an infinite loop and not needed. > https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/io/util/NIODataInputStreamTest.java > - lines 97-101 > isOpen() -- 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 (cb19b39 -> 433274b)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from cb19b39 Merge branch 'cassandra-3.11' into cassandra-4.0 add 632790f Remove possible infinite loop in NIODataInputStreamTest add 6eb02a2 Merge branch cassandra-3.0 into cassandra-3.11 add 433274b Merge branch cassandra-3.11 into cassandra-4.0 No new revisions were added by this update. Summary of changes: test/unit/org/apache/cassandra/io/util/NIODataInputStreamTest.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (fd3eb4f -> 304deea)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from fd3eb4f Clean up repair code patch by Simon Zhou; reviewed by Ekaterina Dimitrova and Andrés de la Peña for CASSANDRA-13720 add 632790f Remove possible infinite loop in NIODataInputStreamTest add 6eb02a2 Merge branch cassandra-3.0 into cassandra-3.11 add 433274b Merge branch cassandra-3.11 into cassandra-4.0 new 304deea 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: test/unit/org/apache/cassandra/io/util/NIODataInputStreamTest.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - 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. blerer pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 304deead2c4a6aa4576783120d12858459d69098 Merge: fd3eb4f 433274b Author: Benjamin Lerer AuthorDate: Wed Aug 18 16:09:44 2021 +0200 Merge branch cassandra-4.0 into trunk test/unit/org/apache/cassandra/io/util/NIODataInputStreamTest.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - 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 (0770666 -> 632790f)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 0770666 Build tests in CircleCI build job add 632790f Remove possible infinite loop in NIODataInputStreamTest No new revisions were added by this update. Summary of changes: test/unit/org/apache/cassandra/io/util/NIODataInputStreamTest.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - 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 (e581a85 -> 6eb02a2)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 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 632790f Remove possible infinite loop in NIODataInputStreamTest add 6eb02a2 Merge branch cassandra-3.0 into cassandra-3.11 No new revisions were added by this update. Summary of changes: test/unit/org/apache/cassandra/io/util/NIODataInputStreamTest.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16864) WEBSITE - Case studies hyperlink for Coursera leads to a 404 page
[
https://issues.apache.org/jira/browse/CASSANDRA-16864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401084#comment-17401084
]
Erick Ramirez commented on CASSANDRA-16864:
---
We are currently sourcing the page. It appears the content was taken down on or
before February 2021. I will post a PR once we have the content back online.
Cheers! 🍻
> WEBSITE - Case studies hyperlink for Coursera leads to a 404 page
> -
>
> Key: CASSANDRA-16864
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16864
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Madhavan
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.x
>
> Attachments: image.png
>
>
> At [https://cassandra.apache.org/_/case-studies.html] when I click on {{READ
> MORE}} button/link for Coursera, it is taking me to
> [https://www.datastax.com/enterprise-success/coursera] which ends up being a
> 404 page. Please address the same.
--
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-16864) WEBSITE - Case studies hyperlink for Coursera leads to a 404 page
[
https://issues.apache.org/jira/browse/CASSANDRA-16864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-16864:
--
Summary: WEBSITE - Case studies hyperlink for Coursera leads to a 404 page
(was: Case studies hyperlink for Coursera leads to a 404 page)
> WEBSITE - Case studies hyperlink for Coursera leads to a 404 page
> -
>
> Key: CASSANDRA-16864
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16864
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Madhavan
>Assignee: Erick Ramirez
>Priority: Normal
> Attachments: image.png
>
>
> At [https://cassandra.apache.org/_/case-studies.html] when I click on {{READ
> MORE}} button/link for Coursera, it is taking me to
> [https://www.datastax.com/enterprise-success/coursera] which ends up being a
> 404 page. Please address the same.
--
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-16864) WEBSITE - Case studies hyperlink for Coursera leads to a 404 page
[
https://issues.apache.org/jira/browse/CASSANDRA-16864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-16864:
--
Change Category: Semantic
Complexity: Normal
Fix Version/s: 4.x
Status: Open (was: Triage Needed)
> WEBSITE - Case studies hyperlink for Coursera leads to a 404 page
> -
>
> Key: CASSANDRA-16864
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16864
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Madhavan
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.x
>
> Attachments: image.png
>
>
> At [https://cassandra.apache.org/_/case-studies.html] when I click on {{READ
> MORE}} button/link for Coursera, it is taking me to
> [https://www.datastax.com/enterprise-success/coursera] which ends up being a
> 404 page. Please address the same.
--
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-16864) Case studies hyperlink for Coursera leads to a 404 page
[
https://issues.apache.org/jira/browse/CASSANDRA-16864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-16864:
--
Workflow: Copy of Cassandra Default Workflow (was: Copy of Cassandra Bug
Workflow)
Issue Type: Task (was: Bug)
> Case studies hyperlink for Coursera leads to a 404 page
> ---
>
> Key: CASSANDRA-16864
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16864
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Madhavan
>Assignee: Erick Ramirez
>Priority: Normal
> Attachments: image.png
>
>
> At [https://cassandra.apache.org/_/case-studies.html] when I click on {{READ
> MORE}} button/link for Coursera, it is taking me to
> [https://www.datastax.com/enterprise-success/coursera] which ends up being a
> 404 page. Please address the same.
--
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-16621) Replace spinAsserts code with Awaitility code
[ https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401080#comment-17401080 ] Berenguer Blasi commented on CASSANDRA-16621: - Yep I included your latest suggestions. I will merge tomorrow in case he is around and wants to drop a comment or sthg. > Replace spinAsserts code with Awaitility code > - > > Key: CASSANDRA-16621 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16621 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Jogesh Anand >Priority: Normal > Labels: low-hanging-fruit > Fix For: 4.0.x > > > Currently spinAsserts does a similar thing to Awaitility which is being used > more and more. We have now 2 ways of doing the same thing so it would be good > to consolidate -- 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-16725) Implement nodetool getauditlog command
[
https://issues.apache.org/jira/browse/CASSANDRA-16725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401077#comment-17401077
]
Ekaterina Dimitrova edited comment on CASSANDRA-16725 at 8/18/21, 2:02 PM:
---
{quote}If reviewers have become involved, always try to keep them included and
take some patience for them to wrap up with a formal +1 on the ticket. This is
important to create a warm and inclusive culture here. Ideally reviewers should
remove themselves from the list if they see that they won't be returning to
provide such a +1.
{quote}
+1 to the patch. I think of the rule for two committers +1 as a minimum
requirement for a commit to happen. BUT if there are more people who were
trying to help with a review, it is a respect to their time and effort to wait
for them to either finish it or signal that they are fine the patch to be
committed without their final vote. Also, it doesn't matter whether it is
contributor, committer or PMC. Every review matters. How I see reviews is they
are the belief of a person that a work Is meaningful and he/she supports It
through dedicating time and efforts into helping to shape it/provide feedback.
{quote}I think they _are_ ironed out as of now after the very last round from
Ekaterina so you might indeed take a look too now.
{quote}
+1, just please add a comment (or maybe even better, java doc) on commit about
that method to make it easier to find and understand its goal by whoever needs
it/looks at it. Thank you for all your work!
was (Author: e.dimitrova):
{quote}If reviewers have become involved, always try to keep them included and
take some patience for them to wrap up with a formal +1 on the ticket. This is
important to create a warm and inclusive culture here. Ideally reviewers should
remove themselves from the list if they see that they won't be returning to
provide such a +1.
{quote}
+1. I think of the rule for two committers +1 as a minimum requirement for a
commit to happen. BUT if there are more people who were trying to help with a
review, it is a respect to their time and effort to wait for them to either
finish it or signal that they are fine the patch to be committed without their
final vote. Also, it doesn't matter whether it is contributor, committer or
PMC. Every review matters. How I see reviews is they are the belief of a person
that a work Is meaningful and he/she supports It through dedicating time and
efforts into helping to shape it/provide feedback.
{quote}I think they _are_ ironed out as of now after the very last round from
Ekaterina so you might indeed take a look too now.
{quote}
+1, just please add a comment (or maybe even better, java doc) on commit about
that method to make it easier to find and understand its goal by whoever needs
it/looks at it. Thank you for all your work!
> 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 50m
> 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
[jira] [Comment Edited] (CASSANDRA-16725) Implement nodetool getauditlog command
[
https://issues.apache.org/jira/browse/CASSANDRA-16725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401077#comment-17401077
]
Ekaterina Dimitrova edited comment on CASSANDRA-16725 at 8/18/21, 2:02 PM:
---
{quote}If reviewers have become involved, always try to keep them included and
take some patience for them to wrap up with a formal +1 on the ticket. This is
important to create a warm and inclusive culture here. Ideally reviewers should
remove themselves from the list if they see that they won't be returning to
provide such a +1.
{quote}
+1. I think of the rule for two committers +1 as a minimum requirement for a
commit to happen. BUT if there are more people who were trying to help with a
review, it is a respect to their time and effort to wait for them to either
finish it or signal that they are fine the patch to be committed without their
final vote. Also, it doesn't matter whether it is contributor, committer or
PMC. Every review matters. How I see reviews is they are the belief of a person
that a work Is meaningful and he/she supports It through dedicating time and
efforts into helping to shape it/provide feedback.
{quote}I think they _are_ ironed out as of now after the very last round from
Ekaterina so you might indeed take a look too now.
{quote}
+1 to the patch, just please add a comment (or maybe even better, java doc) on
commit about that method to make it easier to find and understand its goal by
whoever needs it/looks at it. Thank you for all your work!
was (Author: e.dimitrova):
{quote}If reviewers have become involved, always try to keep them included and
take some patience for them to wrap up with a formal +1 on the ticket. This is
important to create a warm and inclusive culture here. Ideally reviewers should
remove themselves from the list if they see that they won't be returning to
provide such a +1.
{quote}
+1 to the patch. I think of the rule for two committers +1 as a minimum
requirement for a commit to happen. BUT if there are more people who were
trying to help with a review, it is a respect to their time and effort to wait
for them to either finish it or signal that they are fine the patch to be
committed without their final vote. Also, it doesn't matter whether it is
contributor, committer or PMC. Every review matters. How I see reviews is they
are the belief of a person that a work Is meaningful and he/she supports It
through dedicating time and efforts into helping to shape it/provide feedback.
{quote}I think they _are_ ironed out as of now after the very last round from
Ekaterina so you might indeed take a look too now.
{quote}
+1, just please add a comment (or maybe even better, java doc) on commit about
that method to make it easier to find and understand its goal by whoever needs
it/looks at it. Thank you for all your work!
> 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 50m
> 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
[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&focusedCommentId=17401077#comment-17401077
]
Ekaterina Dimitrova commented on CASSANDRA-16725:
-
{quote}If reviewers have become involved, always try to keep them included and
take some patience for them to wrap up with a formal +1 on the ticket. This is
important to create a warm and inclusive culture here. Ideally reviewers should
remove themselves from the list if they see that they won't be returning to
provide such a +1.
{quote}
+1. I think of the rule for two committers +1 as a minimum requirement for a
commit to happen. BUT if there are more people who were trying to help with a
review, it is a respect to their time and effort to wait for them to either
finish it or signal that they are fine the patch to be committed without their
final vote. Also, it doesn't matter whether it is contributor, committer or
PMC. Every review matters. How I see reviews is they are the belief of a person
that a work Is meaningful and he/she supports It through dedicating time and
efforts into helping to shape it/provide feedback.
{quote}I think they _are_ ironed out as of now after the very last round from
Ekaterina so you might indeed take a look too now.
{quote}
+1, just please add a comment (or maybe even better, java doc) on commit about
that method to make it easier to find and understand its goal by whoever needs
it/looks at it. Thank you for all your work!
> 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 50m
> 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
[jira] [Created] (CASSANDRA-16864) Case studies hyperlink for Coursera leads to a 404 page
madhavan created CASSANDRA-16864:
Summary: Case studies hyperlink for Coursera leads to a 404 page
Key: CASSANDRA-16864
URL: https://issues.apache.org/jira/browse/CASSANDRA-16864
Project: Cassandra
Issue Type: Bug
Components: Documentation/Website
Reporter: madhavan
Assignee: Erick Ramirez
Attachments: image.png
At [https://cassandra.apache.org/_/case-studies.html] when I click on {{READ
MORE}} button/link for Coursera, it is taking me to
[https://www.datastax.com/enterprise-success/coursera] which ends up being a
404 page. Please address the same.
--
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-11418) Nodetool status should reflect hibernate/replacing states
[ https://issues.apache.org/jira/browse/CASSANDRA-11418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401059#comment-17401059 ] Brandon Williams edited comment on CASSANDRA-11418 at 8/18/21, 1:30 PM: After evaluating this further I'm not sure why it was considered low hanging fruit. I've removed the tag and updated the complexity. was (Author: brandon.williams): After evaluating this further I'm not sure it was considered low hanging fruit. I've removed the tag and updated the complexity. > Nodetool status should reflect hibernate/replacing states > - > > Key: CASSANDRA-11418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11418 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability, Tool/nodetool >Reporter: Joel Knighton >Assignee: Shaurya Gupta >Priority: Low > Fix For: 4.x > > Attachments: cassandra-11418-trunk > > > Currently, the four options for state in nodetool status are > joining/leaving/moving/normal. > Joining nodes are determined based on bootstrap tokens, leaving nodes are > based on leaving endpoints in TokenMetadata, moving nodes are based on moving > endpoints in TokenMetadata. > This means that a node will appear in normal state when going through a > bootstrap with flag replace_address, which can be confusing to operators. > We should add another state for hibernation/replacing to make this visible. > This will require a way to get a list of all hibernating endpoints. -- 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-11418) Nodetool status should reflect hibernate/replacing states
[ https://issues.apache.org/jira/browse/CASSANDRA-11418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401059#comment-17401059 ] Brandon Williams commented on CASSANDRA-11418: -- After evaluating this further I'm not sure it was considered low hanging fruit. I've removed the tag and updated the complexity. > Nodetool status should reflect hibernate/replacing states > - > > Key: CASSANDRA-11418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11418 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability, Tool/nodetool >Reporter: Joel Knighton >Assignee: Shaurya Gupta >Priority: Low > Fix For: 4.x > > Attachments: cassandra-11418-trunk > > > Currently, the four options for state in nodetool status are > joining/leaving/moving/normal. > Joining nodes are determined based on bootstrap tokens, leaving nodes are > based on leaving endpoints in TokenMetadata, moving nodes are based on moving > endpoints in TokenMetadata. > This means that a node will appear in normal state when going through a > bootstrap with flag replace_address, which can be confusing to operators. > We should add another state for hibernation/replacing to make this visible. > This will require a way to get a list of all hibernating endpoints. -- 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-11418) Nodetool status should reflect hibernate/replacing states
[ https://issues.apache.org/jira/browse/CASSANDRA-11418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-11418: - Labels: (was: lhf) > Nodetool status should reflect hibernate/replacing states > - > > Key: CASSANDRA-11418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11418 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability, Tool/nodetool >Reporter: Joel Knighton >Assignee: Shaurya Gupta >Priority: Low > Fix For: 4.x > > Attachments: cassandra-11418-trunk > > > Currently, the four options for state in nodetool status are > joining/leaving/moving/normal. > Joining nodes are determined based on bootstrap tokens, leaving nodes are > based on leaving endpoints in TokenMetadata, moving nodes are based on moving > endpoints in TokenMetadata. > This means that a node will appear in normal state when going through a > bootstrap with flag replace_address, which can be confusing to operators. > We should add another state for hibernation/replacing to make this visible. > This will require a way to get a list of all hibernating endpoints. -- 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-11418) Nodetool status should reflect hibernate/replacing states
[ https://issues.apache.org/jira/browse/CASSANDRA-11418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-11418: - Complexity: Normal (was: Low Hanging Fruit) > Nodetool status should reflect hibernate/replacing states > - > > Key: CASSANDRA-11418 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11418 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Observability, Tool/nodetool >Reporter: Joel Knighton >Assignee: Shaurya Gupta >Priority: Low > Fix For: 4.x > > Attachments: cassandra-11418-trunk > > > Currently, the four options for state in nodetool status are > joining/leaving/moving/normal. > Joining nodes are determined based on bootstrap tokens, leaving nodes are > based on leaving endpoints in TokenMetadata, moving nodes are based on moving > endpoints in TokenMetadata. > This means that a node will appear in normal state when going through a > bootstrap with flag replace_address, which can be confusing to operators. > We should add another state for hibernation/replacing to make this visible. > This will require a way to get a list of all hibernating endpoints. -- 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&focusedCommentId=17401041#comment-17401041 ] Sam Tunnicliffe commented on CASSANDRA-16404: - bq. I see 4 failures, but they do not seem to be related to these changes. Yep, LGTM too. Good stuff! bq. 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? Yes, you are correct there, so feel free to use this as an opportunity to get comfortable with dtests. Seeing as this isn't an urgent issue, I'd say it's fine to take our time adding new tests here rather than opening another Jira. If you create a dtest branch based off mine, just open a PR against trunk with it when you're ready and I'll review/merge there. If you have any questions, just ask. bq. It needs to be renamed to match the class name. d'oh, good catch. Fixed in my branch. > 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] [Updated] (CASSANDRA-16856) Prevent broken concurrent schema pulls
[ https://issues.apache.org/jira/browse/CASSANDRA-16856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16856: - Reviewers: Brandon Williams, Brandon Williams (was: Brandon Williams) Brandon Williams, Brandon Williams Status: Review In Progress (was: Patch Available) > Prevent broken concurrent schema pulls > -- > > Key: CASSANDRA-16856 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16856 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1, 3.11.x, 4.0.x > > > There's a race condition around pulling schema changes, that can occur in > case the schema changes push/propagation mechanism is not immediately > effective (e.g. because of network delay, or because of the pulling node > being down, etc.). > If schema changes happen on node 1, these changes do not reach node 2 > immediately through the SCHEMA.PUSH mechanism, and are first recognized > during gossiping, the corresponding SCHEMA.PULL request from node 2 can catch > the node 1 schema in the middle of it being modified by another schema change > request. This can easily lead to problems (e.g. if a new table is being > added, and the node 2 request reads the changes that need to be applied to > system_schema.tables, but not the ones that need to be applied to > system_schema.columns). > This PR addresses that by synchronizing the SCHEMA.PULL "RPC call" executed > in node 1 by a request from node 2 with the method for applying schema > changes in node 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-16856) Prevent broken concurrent schema pulls
[ https://issues.apache.org/jira/browse/CASSANDRA-16856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16856: - Status: Ready to Commit (was: Review In Progress) > Prevent broken concurrent schema pulls > -- > > Key: CASSANDRA-16856 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16856 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1, 3.11.x, 4.0.x > > > There's a race condition around pulling schema changes, that can occur in > case the schema changes push/propagation mechanism is not immediately > effective (e.g. because of network delay, or because of the pulling node > being down, etc.). > If schema changes happen on node 1, these changes do not reach node 2 > immediately through the SCHEMA.PUSH mechanism, and are first recognized > during gossiping, the corresponding SCHEMA.PULL request from node 2 can catch > the node 1 schema in the middle of it being modified by another schema change > request. This can easily lead to problems (e.g. if a new table is being > added, and the node 2 request reads the changes that need to be applied to > system_schema.tables, but not the ones that need to be applied to > system_schema.columns). > This PR addresses that by synchronizing the SCHEMA.PULL "RPC call" executed > in node 1 by a request from node 2 with the method for applying schema > changes in node 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-16856) Prevent broken concurrent schema pulls
[ https://issues.apache.org/jira/browse/CASSANDRA-16856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401020#comment-17401020 ] Brandon Williams commented on CASSANDRA-16856: -- +1 > Prevent broken concurrent schema pulls > -- > > Key: CASSANDRA-16856 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16856 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1, 3.11.x, 4.0.x > > > There's a race condition around pulling schema changes, that can occur in > case the schema changes push/propagation mechanism is not immediately > effective (e.g. because of network delay, or because of the pulling node > being down, etc.). > If schema changes happen on node 1, these changes do not reach node 2 > immediately through the SCHEMA.PUSH mechanism, and are first recognized > during gossiping, the corresponding SCHEMA.PULL request from node 2 can catch > the node 1 schema in the middle of it being modified by another schema change > request. This can easily lead to problems (e.g. if a new table is being > added, and the node 2 request reads the changes that need to be applied to > system_schema.tables, but not the ones that need to be applied to > system_schema.columns). > This PR addresses that by synchronizing the SCHEMA.PULL "RPC call" executed > in node 1 by a request from node 2 with the method for applying schema > changes in node 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-16621) Replace spinAsserts code with Awaitility code
[
https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401017#comment-17401017
]
Andres de la Peña commented on CASSANDRA-16621:
---
CI looks good to me.
[~bereng] the only changes from [~djanand]'s patch are the fixes in
{{ThreadPoolMetricsTest}} suggested
[here|https://github.com/adelapena/cassandra/commit/4a47cb2f3e6267cd307d5ac907e8a45b9d6b8468]
and the poll delay mentioned above, right? I think that's ready to commit.
> Replace spinAsserts code with Awaitility code
> -
>
> Key: CASSANDRA-16621
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16621
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Jogesh Anand
>Priority: Normal
> Labels: low-hanging-fruit
> Fix For: 4.0.x
>
>
> Currently spinAsserts does a similar thing to Awaitility which is being used
> more and more. We have now 2 ways of doing the same thing so it would be good
> to consolidate
--
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-16621) Replace spinAsserts code with Awaitility code
[ https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17400949#comment-17400949 ] Berenguer Blasi commented on CASSANDRA-16621: - Rebased and included latest suggestions [here|https://github.com/apache/cassandra/pull/1153]. CI is running but so far lgtm [j8|https://app.circleci.com/pipelines/github/bereng/cassandra/394/workflows/72850a48-4ba7-41ee-a08a-b21dbca0aa82] & [j11|https://app.circleci.com/pipelines/github/bereng/cassandra/394/workflows/b24e1126-767e-49c6-96a1-f283be90bd43] > Replace spinAsserts code with Awaitility code > - > > Key: CASSANDRA-16621 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16621 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Jogesh Anand >Priority: Normal > Labels: low-hanging-fruit > Fix For: 4.0.x > > > Currently spinAsserts does a similar thing to Awaitility which is being used > more and more. We have now 2 ways of doing the same thing so it would be good > to consolidate -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Issue Comment Deleted] (CASSANDRA-16841) Unexpectedly ignored dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-16841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruslan Fomkin updated CASSANDRA-16841:
--
Comment: was deleted
(was: I implemented the suggested solutions on public DataStax fork of
Cassandra in [this PR|https://github.com/datastax/cassandra-dtest/pull/44] and
I plan to port it to Apache Cassandra if no objections.
I did also an implementation where upgrade test is treated separately as before
the bug was introduced in [this
PR|https://github.com/datastax/cassandra-dtest/pull/38]. You can see the
difference in the complexity of the solutions and unit tests.)
> Unexpectedly ignored dtests
> ---
>
> Key: CASSANDRA-16841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> An issue, which I was hit:
> When one class in a dtest file is marked as resource intensive, then all
> tests in all classes are treated as resource intensive. For example,
> [repair_tests/repair_test.py|https://github.com/apache/cassandra-dtest/blob/trunk/repair_tests/repair_test.py]
> contains three classes and the last class is marked as resource intensive:
> {code:java}
> @pytest.mark.resource_intensive
> class TestRepairDataSystemTable(Tester):
> {code}
> So if I try to run an unmarked class:
> {code:java}
> pytest --cassandra-dir=../cassandra repair_tests/repair_test.py::TestRepair
> --collect-only --skip-resource-intensive-tests
> {code}
> then all tests are ignored
> {code:java}
> collected 36 items / 36 deselected
> {code}
> This is because a test is treated to be marked if any class in the same file
> has the mark. This bug was introduced in the fix of CASS-16399. Before only
> upgrade tests had such behaviour, i.e., if a class is marked as upgrade test,
> then all tests are upgrade test in the file.
>
> This bug, for example, means that if the same file contains one class marked
> with vnodes and another class with no_vnodes, then no tests will be executed
> in the file.
> I also noticed another issue that If a test run is executed with the argument
> {{-only-resource-intensive-tests}} and there is no sufficient resources for
> resource intensive tests, then no tests were executed. Thus it was necessary
> to provide {{-force-resource-intensive-tests}} in addition.
> Suggestions for the solutions:
> # Require to mark each class and remove the special case of upgrade tests.
> This will simplify the implementation and might be more obvious for new
> comers.
> # Treat {{-only-resource-intensive-tests}} in the same way as
> {{-force-resource-intensive-tests}}, so it will be enough to just specify it
> even with no sufficient resources.
>
>
--
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-16621) Replace spinAsserts code with Awaitility code
[ https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi reassigned CASSANDRA-16621: --- Assignee: Berenguer Blasi (was: Jogesh Anand) > Replace spinAsserts code with Awaitility code > - > > Key: CASSANDRA-16621 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16621 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Labels: low-hanging-fruit > Fix For: 4.0.x > > > Currently spinAsserts does a similar thing to Awaitility which is being used > more and more. We have now 2 ways of doing the same thing so it would be good > to consolidate -- 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-16621) Replace spinAsserts code with Awaitility code
[ https://issues.apache.org/jira/browse/CASSANDRA-16621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi reassigned CASSANDRA-16621: --- Assignee: Jogesh Anand (was: Berenguer Blasi) > Replace spinAsserts code with Awaitility code > - > > Key: CASSANDRA-16621 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16621 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Jogesh Anand >Priority: Normal > Labels: low-hanging-fruit > Fix For: 4.0.x > > > Currently spinAsserts does a similar thing to Awaitility which is being used > more and more. We have now 2 ways of doing the same thing so it would be good > to consolidate -- 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&focusedCommentId=17400908#comment-17400908 ] Stefan Miklosovic commented on CASSANDRA-16725: --- Thanks [~mck], I think they _are_ ironed out as of now after the very last round from Ekaterina so you might indeed take a look too now. > 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 50m > 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
