[cassandra-website] branch asf-staging updated (24477a9f -> 25423057)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 24477a9f generate docs for 8b85ed85 new 25423057 generate docs for 8b85ed85 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 (24477a9f) \ N -- N -- N refs/heads/asf-staging (25423057) 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/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 2 files 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] [Updated] (CASSANDRA-18526) TupleType getString and fromString are not safe with string types
[
https://issues.apache.org/jira/browse/CASSANDRA-18526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-18526:
--
Bug Category: Parent values: Correctness(12982)Level 1 values:
Unrecoverable Corruption / Loss(13161)
Complexity: Low Hanging Fruit
Discovered By: Fuzz Test
Fix Version/s: 5.x
Severity: Normal
Status: Open (was: Triage Needed)
> TupleType getString and fromString are not safe with string types
> -
>
> Key: CASSANDRA-18526
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18526
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: David Capwell
>Priority: Normal
> Fix For: 5.x
>
>
> In adding property tests for our type system in CASSANDRA-18504, I found that
> tuples have issues with strings as its escaping doesn’t work in all cases…
> below is a simple example where it fails
> {code}
> package org.apache.cassandra.db.marshal;
> import java.nio.ByteBuffer;
> import java.util.Arrays;
> import java.util.List;
> import java.util.UUID;
> import org.junit.Test;
> import org.apache.cassandra.cql3.FieldIdentifier;
> import org.apache.cassandra.utils.ByteBufferUtil;
> import static org.assertj.core.api.Assertions.assertThat;
> public class UserTypeTest
> {
> @Test
> public void test()
> {
> // tuple parsing checks for : and looks to see if a \\ is before it
> (escaped :), so when the string ends with this escape... we fail to parse
> String str = "thiswillbreakthings\\";
> UUID uuid =
> UUIDType.instance.compose(UUIDType.instance.fromString("--4800-9100-"));
> List fieldNames = Arrays.asList(new
> FieldIdentifier(ByteBufferUtil.bytes("a")),
> new
> FieldIdentifier(ByteBufferUtil.bytes("b")));
> List> fieldTypes = Arrays.asList(UTF8Type.instance,
> UUIDType.instance);
> UserType type = new UserType("--dummy--",
> UTF8Type.instance.decompose("name"), fieldNames, fieldTypes, false);
> ByteBuffer original =
> TupleType.buildValue(UTF8Type.instance.decompose(str),
> UUIDType.instance.decompose(uuid));
> String source = type.getString(original);
> ByteBuffer bb = type.fromString(source);
> ByteBuffer[] split = type.split(ByteBufferAccessor.instance, bb);
> assertThat(split).hasSize(2);
> assertThat(split[1]).isEqualTo(uuid);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18526) TupleType getString and fromString are not safe with string types
David Capwell created CASSANDRA-18526:
-
Summary: TupleType getString and fromString are not safe with
string types
Key: CASSANDRA-18526
URL: https://issues.apache.org/jira/browse/CASSANDRA-18526
Project: Cassandra
Issue Type: Bug
Components: CQL/Interpreter
Reporter: David Capwell
In adding property tests for our type system in CASSANDRA-18504, I found that
tuples have issues with strings as its escaping doesn’t work in all cases…
below is a simple example where it fails
{code}
package org.apache.cassandra.db.marshal;
import java.nio.ByteBuffer;
import java.util.Arrays;
import java.util.List;
import java.util.UUID;
import org.junit.Test;
import org.apache.cassandra.cql3.FieldIdentifier;
import org.apache.cassandra.utils.ByteBufferUtil;
import static org.assertj.core.api.Assertions.assertThat;
public class UserTypeTest
{
@Test
public void test()
{
// tuple parsing checks for : and looks to see if a \\ is before it
(escaped :), so when the string ends with this escape... we fail to parse
String str = "thiswillbreakthings\\";
UUID uuid =
UUIDType.instance.compose(UUIDType.instance.fromString("--4800-9100-"));
List fieldNames = Arrays.asList(new
FieldIdentifier(ByteBufferUtil.bytes("a")),
new
FieldIdentifier(ByteBufferUtil.bytes("b")));
List> fieldTypes = Arrays.asList(UTF8Type.instance,
UUIDType.instance);
UserType type = new UserType("--dummy--",
UTF8Type.instance.decompose("name"), fieldNames, fieldTypes, false);
ByteBuffer original =
TupleType.buildValue(UTF8Type.instance.decompose(str),
UUIDType.instance.decompose(uuid));
String source = type.getString(original);
ByteBuffer bb = type.fromString(source);
ByteBuffer[] split = type.split(ByteBufferAccessor.instance, bb);
assertThat(split).hasSize(2);
assertThat(split[1]).isEqualTo(uuid);
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18521) Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
[
https://issues.apache.org/jira/browse/CASSANDRA-18521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722303#comment-17722303
]
Caleb Rackliffe commented on CASSANDRA-18521:
-
So I made my first pass, and this patch looks really nice.
The only mystery seems to be what's going on w/ the flake in
{{StorageAttachedIndexDDLTest}}. I have a couple thoughts in
https://github.com/apache/cassandra/pull/2329/files#r1192835455
> Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
>
>
> Key: CASSANDRA-18521
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18521
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: NA
>
>
> It has been
> [mentioned|https://github.com/maedhroz/cassandra/pull/11#discussion_r1190166765]
> in CASSANDRA-18217 that {{CQLTester#waitForIndex}} and
> {{SAITester#waitForIndexQueryable}} can be unified into a single method.
> The same discussion mentions that it's easy to forget to call those methods
> after calling {{CQLTester#createIndex}}. So that method can be renamed to
> {{createIndexAsync}}, and we can create a new method that creates the index
> and waits for it ({{createIndexSync}}, {{createIndexAndWaitForQueryable}}, or
> something like that).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14319) nodetool rebuild from DC lets you pass invalid datacenters
[
https://issues.apache.org/jira/browse/CASSANDRA-14319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722301#comment-17722301
]
Stefan Miklosovic commented on CASSANDRA-14319:
---
[~brandon.williams] [~blerer] could you please review? Thank you.
> nodetool rebuild from DC lets you pass invalid datacenters
> ---
>
> Key: CASSANDRA-14319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14319
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Attachments: CASSANDRA-14319-trunk.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you pass an invalid datacenter to nodetool rebuild, you'll get an error
> like this:
> {code}
> Unable to find sufficient sources for streaming range
> (3074457345618258602,-9223372036854775808] in keyspace system_distributed
> {code}
> Unfortunately, this is a rabbit hole of frustration if you are using caps for
> your DC names and you pass in a lowercase DC name, or you just typo the DC.
> Let's do the following:
> # Check the DC name that's passed in against the list of DCs we know about
> # If we don't find it, let's output a reasonable error, and list all the DCs
> someone could put in.
> # Ideally we indicate which keyspaces are set to replicate to this DC and
> which aren't
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18345) Enable streaming SAI components as part of repair
[ https://issues.apache.org/jira/browse/CASSANDRA-18345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-18345: Change Category: Operability Complexity: Normal Fix Version/s: NA Status: Open (was: Triage Needed) > Enable streaming SAI components as part of repair > - > > Key: CASSANDRA-18345 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18345 > Project: Cassandra > Issue Type: Improvement > Components: Feature/2i Index >Reporter: Mike Adamson >Priority: Normal > Labels: SAI > Fix For: NA > > > SAI registers it's components with the SSTable descriptor expecting them to > form part of the SSTable lifecycle, including streaming. This is not the case. > The current SSTable format in Cassandra uses a fixed set of components > (Components.STREAMING_COMPONENTS) when streaming SSTables. This needs to > change to use the set of components that are registered with a specific > SSTable by calls to SSTable.registerComponents. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18521) Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
[
https://issues.apache.org/jira/browse/CASSANDRA-18521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722286#comment-17722286
]
Caleb Rackliffe edited comment on CASSANDRA-18521 at 5/12/23 9:14 PM:
--
Failures in {{VirtualTableFromInternodeTest}} look unrelated to SAI and also
appear on the {{cep-7-sai}} branch at the moment.
was (Author: maedhroz):
Failure in {{VirtualTableFromInternodeTest}} looks unrelated to SAI...
> Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
>
>
> Key: CASSANDRA-18521
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18521
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: NA
>
>
> It has been
> [mentioned|https://github.com/maedhroz/cassandra/pull/11#discussion_r1190166765]
> in CASSANDRA-18217 that {{CQLTester#waitForIndex}} and
> {{SAITester#waitForIndexQueryable}} can be unified into a single method.
> The same discussion mentions that it's easy to forget to call those methods
> after calling {{CQLTester#createIndex}}. So that method can be renamed to
> {{createIndexAsync}}, and we can create a new method that creates the index
> and waits for it ({{createIndexSync}}, {{createIndexAndWaitForQueryable}}, or
> something like that).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18521) Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
[
https://issues.apache.org/jira/browse/CASSANDRA-18521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722295#comment-17722295
]
Caleb Rackliffe commented on CASSANDRA-18521:
-
The failures in {{StorageAttachedIndexDDLTest}} and
{{o.a.c.index.sai.functional.SnapshotTest}} I couldn't reproduce locally on a
first run...
> Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
>
>
> Key: CASSANDRA-18521
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18521
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: NA
>
>
> It has been
> [mentioned|https://github.com/maedhroz/cassandra/pull/11#discussion_r1190166765]
> in CASSANDRA-18217 that {{CQLTester#waitForIndex}} and
> {{SAITester#waitForIndexQueryable}} can be unified into a single method.
> The same discussion mentions that it's easy to forget to call those methods
> after calling {{CQLTester#createIndex}}. So that method can be renamed to
> {{createIndexAsync}}, and we can create a new method that creates the index
> and waits for it ({{createIndexSync}}, {{createIndexAndWaitForQueryable}}, or
> something like that).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18521) Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
[
https://issues.apache.org/jira/browse/CASSANDRA-18521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722286#comment-17722286
]
Caleb Rackliffe commented on CASSANDRA-18521:
-
Failure in {{VirtualTableFromInternodeTest}} looks unrelated to SAI...
> Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
>
>
> Key: CASSANDRA-18521
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18521
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: NA
>
>
> It has been
> [mentioned|https://github.com/maedhroz/cassandra/pull/11#discussion_r1190166765]
> in CASSANDRA-18217 that {{CQLTester#waitForIndex}} and
> {{SAITester#waitForIndexQueryable}} can be unified into a single method.
> The same discussion mentions that it's easy to forget to call those methods
> after calling {{CQLTester#createIndex}}. So that method can be renamed to
> {{createIndexAsync}}, and we can create a new method that creates the index
> and waits for it ({{createIndexSync}}, {{createIndexAndWaitForQueryable}}, or
> something like that).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18525) Add keyspace column to clients virtual table
[ https://issues.apache.org/jira/browse/CASSANDRA-18525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18525: -- Status: Review In Progress (was: Patch Available) > Add keyspace column to clients virtual table > > > Key: CASSANDRA-18525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18525 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > > Clients virtual table doesn’t have keyspace information. ‘clientstats' > nodetool has this information. Adding keyspace column to clients virtual > table helps not to fallback to nodetool command. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18525) Add keyspace column to clients virtual table
[ https://issues.apache.org/jira/browse/CASSANDRA-18525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18525: -- Status: Changes Suggested (was: Review In Progress) I suggested changes in comment in the PR. Thanks. > Add keyspace column to clients virtual table > > > Key: CASSANDRA-18525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18525 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > > Clients virtual table doesn’t have keyspace information. ‘clientstats' > nodetool has this information. Adding keyspace column to clients virtual > table helps not to fallback to nodetool command. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18525) Add keyspace column to clients virtual table
[ https://issues.apache.org/jira/browse/CASSANDRA-18525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18525: -- Test and Documentation Plan: CI Status: Patch Available (was: In Progress) > Add keyspace column to clients virtual table > > > Key: CASSANDRA-18525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18525 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > > Clients virtual table doesn’t have keyspace information. ‘clientstats' > nodetool has this information. Adding keyspace column to clients virtual > table helps not to fallback to nodetool command. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18525) Add keyspace column to clients virtual table
[ https://issues.apache.org/jira/browse/CASSANDRA-18525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18525: -- Change Category: Operability Complexity: Low Hanging Fruit Component/s: Feature/Virtual Tables Fix Version/s: 5.x Reviewers: Stefan Miklosovic Status: Open (was: Triage Needed) > Add keyspace column to clients virtual table > > > Key: CASSANDRA-18525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18525 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > Fix For: 5.x > > > Clients virtual table doesn’t have keyspace information. ‘clientstats' > nodetool has this information. Adding keyspace column to clients virtual > table helps not to fallback to nodetool command. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14319) nodetool rebuild from DC lets you pass invalid datacenters
[
https://issues.apache.org/jira/browse/CASSANDRA-14319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-14319:
--
Status: Patch Available (was: In Progress)
> nodetool rebuild from DC lets you pass invalid datacenters
> ---
>
> Key: CASSANDRA-14319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14319
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Attachments: CASSANDRA-14319-trunk.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you pass an invalid datacenter to nodetool rebuild, you'll get an error
> like this:
> {code}
> Unable to find sufficient sources for streaming range
> (3074457345618258602,-9223372036854775808] in keyspace system_distributed
> {code}
> Unfortunately, this is a rabbit hole of frustration if you are using caps for
> your DC names and you pass in a lowercase DC name, or you just typo the DC.
> Let's do the following:
> # Check the DC name that's passed in against the list of DCs we know about
> # If we don't find it, let's output a reasonable error, and list all the DCs
> someone could put in.
> # Ideally we indicate which keyspaces are set to replicate to this DC and
> which aren't
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14319) nodetool rebuild from DC lets you pass invalid datacenters
[
https://issues.apache.org/jira/browse/CASSANDRA-14319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-14319:
--
Status: Needs Committer (was: Patch Available)
> nodetool rebuild from DC lets you pass invalid datacenters
> ---
>
> Key: CASSANDRA-14319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14319
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Attachments: CASSANDRA-14319-trunk.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you pass an invalid datacenter to nodetool rebuild, you'll get an error
> like this:
> {code}
> Unable to find sufficient sources for streaming range
> (3074457345618258602,-9223372036854775808] in keyspace system_distributed
> {code}
> Unfortunately, this is a rabbit hole of frustration if you are using caps for
> your DC names and you pass in a lowercase DC name, or you just typo the DC.
> Let's do the following:
> # Check the DC name that's passed in against the list of DCs we know about
> # If we don't find it, let's output a reasonable error, and list all the DCs
> someone could put in.
> # Ideally we indicate which keyspaces are set to replicate to this DC and
> which aren't
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18521) Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
[
https://issues.apache.org/jira/browse/CASSANDRA-18521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722270#comment-17722270
]
Caleb Rackliffe commented on CASSANDRA-18521:
-
bq. That's why I prefer to make the sync method the default and not naming it
createIndexSync, createIndexWaitingForQueryable, or something like that. wdyt?
Agreed
> Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
>
>
> Key: CASSANDRA-18521
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18521
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: NA
>
>
> It has been
> [mentioned|https://github.com/maedhroz/cassandra/pull/11#discussion_r1190166765]
> in CASSANDRA-18217 that {{CQLTester#waitForIndex}} and
> {{SAITester#waitForIndexQueryable}} can be unified into a single method.
> The same discussion mentions that it's easy to forget to call those methods
> after calling {{CQLTester#createIndex}}. So that method can be renamed to
> {{createIndexAsync}}, and we can create a new method that creates the index
> and waits for it ({{createIndexSync}}, {{createIndexAndWaitForQueryable}}, or
> something like that).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14319) nodetool rebuild from DC lets you pass invalid datacenters
[
https://issues.apache.org/jira/browse/CASSANDRA-14319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720437#comment-17720437
]
Stefan Miklosovic edited comment on CASSANDRA-14319 at 5/12/23 8:07 PM:
trunk [https://github.com/apache/cassandra/pull/2309]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/c0b0e974-fdb1-4410-a180-fc8890c9a7e5]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/4fc8308c-3f07-4b41-9ad3-3a20a547c0e9]
4.1 [https://github.com/apache/cassandra/pull/2323]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2194/workflows/e6aee8b6-95e7-446f-879d-a66bb4275255]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2194/workflows/bae89aec-bbe4-4705-bcdf-fc4fdecbfe3a]
4.0 [https://github.com/apache/cassandra/pull/2324]
j11
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2195/workflows/4e9e290d-9ada-4aa7-a2a9-68d66b1961fe
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2195/workflows/87cb1f9a-b71e-414b-b270-81d934390ab0
3.11 [https://github.com/apache/cassandra/pull/2325]
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2196/workflows/7d692de2-3f73-4247-b4ec-fb8f6031c681
3.0 [https://github.com/apache/cassandra/pull/2332]
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2197/workflows/831b7247-b5aa-4402-b9e9-9748602240f5
was (Author: smiklosovic):
trunk [https://github.com/apache/cassandra/pull/2309]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/c0b0e974-fdb1-4410-a180-fc8890c9a7e5]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/4fc8308c-3f07-4b41-9ad3-3a20a547c0e9]
4.1 [https://github.com/apache/cassandra/pull/2323]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2194/workflows/e6aee8b6-95e7-446f-879d-a66bb4275255]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2194/workflows/bae89aec-bbe4-4705-bcdf-fc4fdecbfe3a]
4.0 [https://github.com/apache/cassandra/pull/2324]
j11
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2195/workflows/4e9e290d-9ada-4aa7-a2a9-68d66b1961fe
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2195/workflows/87cb1f9a-b71e-414b-b270-81d934390ab0
3.11 [https://github.com/apache/cassandra/pull/2325]
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2196/workflows/7d692de2-3f73-4247-b4ec-fb8f6031c681
> nodetool rebuild from DC lets you pass invalid datacenters
> ---
>
> Key: CASSANDRA-14319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14319
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Attachments: CASSANDRA-14319-trunk.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you pass an invalid datacenter to nodetool rebuild, you'll get an error
> like this:
> {code}
> Unable to find sufficient sources for streaming range
> (3074457345618258602,-9223372036854775808] in keyspace system_distributed
> {code}
> Unfortunately, this is a rabbit hole of frustration if you are using caps for
> your DC names and you pass in a lowercase DC name, or you just typo the DC.
> Let's do the following:
> # Check the DC name that's passed in against the list of DCs we know about
> # If we don't find it, let's output a reasonable error, and list all the DCs
> someone could put in.
> # Ideally we indicate which keyspaces are set to replicate to this DC and
> which aren't
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18521) Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
[
https://issues.apache.org/jira/browse/CASSANDRA-18521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18521:
Reviewers: Caleb Rackliffe
Status: Review In Progress (was: Patch Available)
> Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
>
>
> Key: CASSANDRA-18521
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18521
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: NA
>
>
> It has been
> [mentioned|https://github.com/maedhroz/cassandra/pull/11#discussion_r1190166765]
> in CASSANDRA-18217 that {{CQLTester#waitForIndex}} and
> {{SAITester#waitForIndexQueryable}} can be unified into a single method.
> The same discussion mentions that it's easy to forget to call those methods
> after calling {{CQLTester#createIndex}}. So that method can be renamed to
> {{createIndexAsync}}, and we can create a new method that creates the index
> and waits for it ({{createIndexSync}}, {{createIndexAndWaitForQueryable}}, or
> something like that).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14319) nodetool rebuild from DC lets you pass invalid datacenters
[
https://issues.apache.org/jira/browse/CASSANDRA-14319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720437#comment-17720437
]
Stefan Miklosovic edited comment on CASSANDRA-14319 at 5/12/23 8:01 PM:
trunk [https://github.com/apache/cassandra/pull/2309]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/c0b0e974-fdb1-4410-a180-fc8890c9a7e5]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/4fc8308c-3f07-4b41-9ad3-3a20a547c0e9]
4.1 [https://github.com/apache/cassandra/pull/2323]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2194/workflows/e6aee8b6-95e7-446f-879d-a66bb4275255]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2194/workflows/bae89aec-bbe4-4705-bcdf-fc4fdecbfe3a]
4.0 [https://github.com/apache/cassandra/pull/2324]
j11
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2195/workflows/4e9e290d-9ada-4aa7-a2a9-68d66b1961fe
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2195/workflows/87cb1f9a-b71e-414b-b270-81d934390ab0
3.11 [https://github.com/apache/cassandra/pull/2325]
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2196/workflows/7d692de2-3f73-4247-b4ec-fb8f6031c681
was (Author: smiklosovic):
trunk [https://github.com/apache/cassandra/pull/2309]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/c0b0e974-fdb1-4410-a180-fc8890c9a7e5]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/4fc8308c-3f07-4b41-9ad3-3a20a547c0e9]
4.1 [https://github.com/apache/cassandra/pull/2323]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2194/workflows/e6aee8b6-95e7-446f-879d-a66bb4275255]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2194/workflows/bae89aec-bbe4-4705-bcdf-fc4fdecbfe3a]
4.0 [https://github.com/apache/cassandra/pull/2324]
j11
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2195/workflows/4e9e290d-9ada-4aa7-a2a9-68d66b1961fe
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2195/workflows/87cb1f9a-b71e-414b-b270-81d934390ab0
> nodetool rebuild from DC lets you pass invalid datacenters
> ---
>
> Key: CASSANDRA-14319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14319
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Attachments: CASSANDRA-14319-trunk.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you pass an invalid datacenter to nodetool rebuild, you'll get an error
> like this:
> {code}
> Unable to find sufficient sources for streaming range
> (3074457345618258602,-9223372036854775808] in keyspace system_distributed
> {code}
> Unfortunately, this is a rabbit hole of frustration if you are using caps for
> your DC names and you pass in a lowercase DC name, or you just typo the DC.
> Let's do the following:
> # Check the DC name that's passed in against the list of DCs we know about
> # If we don't find it, let's output a reasonable error, and list all the DCs
> someone could put in.
> # Ideally we indicate which keyspaces are set to replicate to this DC and
> which aren't
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16895) Build with Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16895: Description: This ticket is intended to group all issues found to support Java 17 in the future. Upgrade steps: * [Dependencies |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to be updated (not all but at least those that require an update in order to work with Java 17) * More encapsulated JDK internal APIs. Some of the issues might be solved with the dependencies updates * Currently trunk compiles if we remove the Nashorn dependency (ant script tag, used for the test environment; UDFs) . The oracle recommendation to use Nashorn-core won't work for the project as it is under GPL 2.0. Most probably we will opt in for graal-sdk licensed under UPL * All tests to be cleaned * CI environment to be setup *NOTE:* GC tuning, performance testing were never agreed to be part of this ticket. Below is a snapshot of current CI failures with JDK17, it will be updated on a regular basis with a date of update *May 12th 2023* || ||Failing Test Classes||Ticket Numbers|| | |_Python DTests_| | |1|test_sjk|CASSANDRA-18343| | |_Java Ditributed Tests_| | |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all tests, org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests, org.apache.cassandra.distributed.test.IPMembershipTest - both tests, org.apache.cassandra.distributed.test.MixedModeFuzzTest, org.apache.cassandra.distributed.test.ReprepareFuzzTest, org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304| |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest - all tests org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all tests|Both tests suffer from CASSANDRA-18180 fwiw, using the CASSANDRA-18180 branch, only the negotiatedProtocolMustBeAcceptedProtocolTest fails in both these tests. EDIT: We will need a ticket for this one post CASSANDRA-18180. TLSv1.1 failed to negotiate (netty complains about certificate_unknown). Changes in JDK17 config to be checked | |9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest - 2 tests|CASSANDRA-18180| | |_Unit Tests_| | |1|org.apache.cassandra.repair.RepairJobTest - 1 test|CASSANDRA-17884| |2|org.apache.cassandra.security.SSLFactoryTest - all tests|CASSANDRA-17992| |3,4|org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest, org.apache.cassandra.utils.concurrent.RefCountedTest|CASSANDRA-18329| |5,6|org.apache.cassandra.cql3.validation.entities.UFJavaTest, org.apache.cassandra.cql3.validation.entities.UFSecurityTest|CASSANDRA-18190| |7|org.apache.cassandra.cql3.EmptyValuesTest|CASSANDRA-18436| |8|org.apache.cassandra.transport.MessagePayloadTest-.jdk17|CASSANDRA-18437| was: This ticket is intended to group all issues found to support Java 17 in the future. Upgrade steps: * [Dependencies |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to be updated (not all but at least those that require an update in order to work with Java 17) * More encapsulated JDK internal APIs. Some of the issues might be solved with the dependencies updates * Currently trunk compiles if we remove the Nashorn dependency (ant script tag, used for the test environment; UDFs) . The oracle recommendation to use Nashorn-core won't work for the project as it is under GPL 2.0. Most probably we will opt in for graal-sdk licensed under UPL * All tests to be cleaned * CI environment to be setup *NOTE:* GC tuning, performance testing were never agreed to be part of this ticket. Below is a snapshot of current CI failures with JDK17, it will be updated on a regular basis with a date of update *May 12th 2023* || ||Failing Test Classes||Ticket Numbers|| | |_Python DTests_| | |1|test_sjk|CASSANDRA-18343| | |_Java Ditributed Tests_| | |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all tests, org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests, org.apache.cassandra.distributed.test.IPMembershipTest - both tests, org.apache.cassandra.distributed.test.MixedModeFuzzTest, org.apache.cassandra.distributed.test.ReprepareFuzzTest, org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304| |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest - all tests org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all tests|Both tests suffer from CASSANDRA-18180 fwiw, using the CASSANDRA-18180 branch, only the negotiatedProtocolMustBeAcceptedProtocolTest fails in both these tests. | |9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest - 2 tests|CASSANDRA-18180| | |_Unit Tests_| | |1|org.apache.cassandra.repair.RepairJobTest
[jira] [Comment Edited] (CASSANDRA-14319) nodetool rebuild from DC lets you pass invalid datacenters
[
https://issues.apache.org/jira/browse/CASSANDRA-14319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720437#comment-17720437
]
Stefan Miklosovic edited comment on CASSANDRA-14319 at 5/12/23 5:44 PM:
trunk [https://github.com/apache/cassandra/pull/2309]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/c0b0e974-fdb1-4410-a180-fc8890c9a7e5]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/4fc8308c-3f07-4b41-9ad3-3a20a547c0e9]
4.1 [https://github.com/apache/cassandra/pull/2323]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2194/workflows/e6aee8b6-95e7-446f-879d-a66bb4275255]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2194/workflows/bae89aec-bbe4-4705-bcdf-fc4fdecbfe3a]
4.0 [https://github.com/apache/cassandra/pull/2324]
j11
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2195/workflows/4e9e290d-9ada-4aa7-a2a9-68d66b1961fe
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2195/workflows/87cb1f9a-b71e-414b-b270-81d934390ab0
was (Author: smiklosovic):
trunk [https://github.com/apache/cassandra/pull/2309]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/c0b0e974-fdb1-4410-a180-fc8890c9a7e5]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/4fc8308c-3f07-4b41-9ad3-3a20a547c0e9]
4.1 [https://github.com/apache/cassandra/pull/2323]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2194/workflows/e6aee8b6-95e7-446f-879d-a66bb4275255]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2194/workflows/bae89aec-bbe4-4705-bcdf-fc4fdecbfe3a]
> nodetool rebuild from DC lets you pass invalid datacenters
> ---
>
> Key: CASSANDRA-14319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14319
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Attachments: CASSANDRA-14319-trunk.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you pass an invalid datacenter to nodetool rebuild, you'll get an error
> like this:
> {code}
> Unable to find sufficient sources for streaming range
> (3074457345618258602,-9223372036854775808] in keyspace system_distributed
> {code}
> Unfortunately, this is a rabbit hole of frustration if you are using caps for
> your DC names and you pass in a lowercase DC name, or you just typo the DC.
> Let's do the following:
> # Check the DC name that's passed in against the list of DCs we know about
> # If we don't find it, let's output a reasonable error, and list all the DCs
> someone could put in.
> # Ideally we indicate which keyspaces are set to replicate to this DC and
> which aren't
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r61815 - /release/cassandra/KEYS
Author: djoshi Date: Fri May 12 17:43:17 2023 New Revision: 61815 Log: Add Dinesh A. Joshi's for releases Modified: release/cassandra/KEYS Modified: release/cassandra/KEYS == --- release/cassandra/KEYS (original) +++ release/cassandra/KEYS Fri May 12 17:43:17 2023 @@ -4384,3 +4384,61 @@ bX2jaUW6WAij4deNlOh5QIRgX/7F7GgIMr4BwdKR V2TrBZ7se6NT5IP/MpUv+x+N =+vFA -END PGP PUBLIC KEY BLOCK- +pub rsa4096 2023-05-12 [SC] + 53371F9B1B425A336988B6A03B6042413D323470 +uid [ultimate] Dinesh A. Joshi +sig 33B6042413D323470 2023-05-12 Dinesh A. Joshi +sub rsa4096 2023-05-12 [E] +sig 3B6042413D323470 2023-05-12 Dinesh A. Joshi + +-BEGIN PGP PUBLIC KEY BLOCK- + +mQINBGRedTkBEACvx+PEaC/IJg0LtIy4Ab157YJ9rJtvofXAwhWIhr2GvG/IDwaA +tP4pyMlXvVBcK7IGvohPeTWiDsEJmQKu8a7x2yyJA4HXaV/SFeXeDvzYBPHz3JQC +f+FLivTUrv6OTIXb0GaNX/bzBqwlCm6vyPsaPulxXQGQYC+ejhNJrZ5c5zXL/WsV +9gfV+zNKmFoLF3ccszx7ZC1rNwI1Kms/p/Btc/aw1WrL2mtMErmx1jIDo/EpYNjg +or4/2UYDY3g1JK+dAFDBEUh82E/US9ndLoYglMlVUgJ47nLDW/unt7VUqIfFJXTr +/rJFYGXl2rzAZFgo+BgjPwst0hh/Ds+bl0PMQw9b8+gndYBBT9OUaOKXfc/2C8Ae +YUxK74jsrIhm8IH0P5OUoz1tT0pAKnB546azjHm4TvH9RCLZC8zxZuPVduQt4osm +cjhLB7z+gq0hvB76jHVv19Kr2IVkpzV9Sx56i3pTlAZdj9n2uT+psbINTs0Ep8Fv +FWe1fI68VyHMtBXjCIz0zf5qvBBMTcY3va7QOYo7bjhn2eijBOEChl2j27AcAuMg +oJKT0PfeMD2FuKAqybrLAjYtQ1ixg0gkv50UgPg62Rb/MlqDICfMRuMQjruCGpvl +WpbClyVaBo9mzruYkUaxkMNgr74uhRjNq/0bc9jrJfLtwZui3dqwJzVc5QARAQAB +tCNEaW5lc2ggQS4gSm9zaGkgPGRqb3NoaUBhcGFjaGUub3JnPokCTgQTAQoAOBYh +BFM3H5sbQlozaYi2oDtgQkE9MjRwBQJkXnU5AhsDBQsJCAcCBhUKCQgLAgQWAgMB +Ah4BAheAAAoJEDtgQkE9MjRwsPwQAJh9YyugxWMuYilpAwgOF2m0dsBVyHkTXAe8 +gPH7/gcsw5Bs2jKHS4O9XXw18TcEoWQYVOiaFzuylUMjo6YKvGxkmceZ8xBypUhw +yKHivblIc6u98Oeq4JBO/70bgw4vqDIrWJgWi4ctuRJmqVSO1R5WDgLvHcUOfHV9 +2D7zbsloPspoVa2S4Wd1oH8tMo0KYVmM2dDaDn66NclSS5TmH5HfaavzhI3YjFAL +Hxd0oulH7AuBFrI6zzwQNs/e2ZSDffP3iKKiWmHL5SWT7L7qipSHaDIMuG14DOBK +Xczo+PrEk2YuEn4+R2oggrKNRk4mijQyqW6dpIHV6MgozWf7q28E1xMHCxTKtY94 +WvOaAiLcg3OCFPnjChio21+m06oKJ5d6+uaWI9bFNDWTb2/lLxWzlHtoB570bNMu +nM2LXMDhqeowxSnBoFepGRGs7r5llu5lNULSXkPd6dhZIjL31h0Wq84jHH6/pLqa +yovnVQRozGfu6na3dPLt2FAWBkget1SGUQ3ACaQS2Xcs2cUt8PBodqjZns45kBnr +/5P25lbNwWHhUkRq+/h2yQCSzzG4uB9Ahz57pka70wh1T4t0iL+iv36tCMB+z+xr +vxo6OsaIWvy55Z/mcYohb70brw4FL2s4dtAym9zoFnPelMwmUH1WVE5Iu3/HWEYo ++5cB/SMCuQINBGRedTkBEADgRe5cZXy0GZ6UmgGCmAw6wGjjZBvjfX4dIGUPE9Hx +9CBlgPMUxSf97TlXRXITTeb2Hov49QF3UqRpivm78dPp2CGXFbZZjEpjZz9MESvT +D+sCdRgL7k/hSn/a8jOTW7MuJ4e4bA396wAn2gV/jFupwxbgHdQsrtl2hiLiw/gJ +rTa11JFc3dja1qN+zCFcuu4s8UFFglT0l7i27LeUMtCa242jXmiW5BkvHabQbZfr +lTGn0X3QHI2csj0QVHjmkqDfYrivcJGHAgGBXigyP1lf8VsFjUM+gVyzWFyWTPVK +QwbAvgVKAeL9/XAJZY+ZXnQMrfKDZ+sQ3T2CMNQtD5LPWu4/7gWccP1GMMHeLtS0 +IGTzIqiNrylyBJ37D5EnDRW3yBJ5IO6ouzQ9Ftq3agfnolq88V6+HP/5GyWyT5TR +SBZjcvtvjRtSGVmXweW8s+jRf7HUmDzwGsoVgVdg8x88QB0dOy7B/R68kuuqK8la +z7SQWt2xeSNj8m3qZtBlDTlfQBBefWmMnjxdVILdfCRFRxySMveI7LbwKfL8fU88 +fQv7mmVHW2+aNyOngAkDDvEP1m0Bhgu18ONzhfe7Ky32vNgQEKJi3hCbq6pfqnuY +BvnWUJvRS1qBLXfMhyobp1XSTMn7vo9NZDjnrskP/C3/X8JSfdq4dA2wNRD5Qdda +6wARAQABiQI2BBgBCgAgFiEEUzcfmxtCWjNpiLagO2BCQT0yNHAFAmRedTkCGwwA +CgkQO2BCQT0yNHCWzRAAnaQD5E65kks8FwfoF5afbdcDVk80mNtwRzJuEmBbFUlf +/esDpoQHNBlYa/o9d2RE82+xh9YbD+RZVtn2uLbHLsjHY3IzD0yY/pCfFRPTCePo +73W6Tevr+1EzmR0Lew73LU7C2XPx2hiQJyjSV9NKgvr35PegOiOifP7D3i88YLda +/6xY9m1DsFemTzSSel5iae7412/JwLzOGrJVw9JV5QFSlGJxd+ea45eaT3NN40z1 +BVC347OLsN6DA61055w7JOfCKclnqX8dU7Q5oP6O8OZCl9gFIEE534Z5wo6SpapY +/qvYW8dsBvMwZ2YRCmrMWmjIs4ndukjphpsHvDekaEjUWCWA7jFJJCi+xDWQ1LDb +ucdtSG9YPa9pzFOz8NIsc+nyLM3VGG4i/S359DaQpMt7k5eUt3UF3YBxqkyEv5gX ++tFXb5yevg0sE/7McyxOpFUULmNckF1BvS7qGQH0dN5j7LOYRFBtijJyj/gsS2oC +BIWE3/h6a2RAvrDR39Q9gsAxxK38Sf4vtnGqMr8O50E9VbWmha+32X41oFFT+Vlk +fh64FBiZwqsFHm9u5THDx+OM599DTm+X2PPeHa3t5V8Ize+kvlOe9Z+T41qPXJ3L +jAwDyoNhv3vxHDh/uJewKp/DPZQDRDIxoXlNH8d3ZF9x1iJk7mZvLVh73vSIQ1g= +=PgXX +-END PGP PUBLIC KEY BLOCK- - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18525) Add keyspace column to clients virtual table
[ https://issues.apache.org/jira/browse/CASSANDRA-18525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722243#comment-17722243 ] n.v.harikrishna commented on CASSANDRA-18525: - PR for trunk is [here|https://github.com/apache/cassandra/pull/2331]. > Add keyspace column to clients virtual table > > > Key: CASSANDRA-18525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18525 > Project: Cassandra > Issue Type: Improvement >Reporter: n.v.harikrishna >Assignee: n.v.harikrishna >Priority: Normal > > Clients virtual table doesn’t have keyspace information. ‘clientstats' > nodetool has this information. Adding keyspace column to clients virtual > table helps not to fallback to nodetool command. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16222) CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-16222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero updated CASSANDRA-16222: --- Test and Documentation Plan: Added unit tests and integration tests. Status: Patch Available (was: In Progress) Sidecar Patch: PR: https://github.com/apache/cassandra-sidecar/pull/45 CI: https://app.circleci.com/pipelines/github/frankgh/cassandra-sidecar/135 Analytics Patch: https://github.com/frankgh/cassandra-analytics > CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics > > > Key: CASSANDRA-16222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16222 > Project: Cassandra > Issue Type: New Feature > Components: Tool/external >Reporter: James Berragan >Assignee: Francisco Guerrero >Priority: Normal > Fix For: NA > > Attachments: sparkbulkreader.patch > > > *Description:* > This ticket introduces the Spark-Cassandra Bulk Analytics library and > associated Cassandra Sidecar endpoints. > > Please see > [CEP-28|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-28%3A+Reading+and+Writing+Cassandra+Data+with+Spark+Bulk+Analytics] > for more details, motivation, and available source code links. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18511) Add support for JMX in the in-jvm dtest framework
[ https://issues.apache.org/jira/browse/CASSANDRA-18511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721359#comment-17721359 ] Doug Rohrer edited comment on CASSANDRA-18511 at 5/12/23 4:40 PM: -- in-jvm-dtest change: [https://github.com/apache/cassandra-in-jvm-dtest-api/pull/34] -Once we have a snapshot build of the API I'll post PRs for trunk/4.1/4.0/3.11- Trunk patch: [https://github.com/apache/cassandra/pull/2318] 4.1: [https://github.com/apache/cassandra/pull/2328] 4.0: [https://github.com/apache/cassandra/pull/2326] 3.11: [https://github.com/apache/cassandra/pull/2322] Circle CI builds (updated 2023/05/12 with new links after fixing some bugs): Trunk: [java8_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/69/workflows/a4387bfc-46ba-41ec-b688-db1bb7b88807] [java11_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/69/workflows/5012b08a-8c12-4a21-ae93-2a5b0c5e8c88] 4.1: [java8_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/66/workflows/040b9ae8-bf6b-481a-a49a-5e1eeaf1ad53] [java11_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/66/workflows/61fbcf8a-5333-4548-a857-328ef5725507] 4.0: - both jams seeing `[testFailingMessage[VALIDATION_REQ/parallel/true]|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/67/workflows/a21ac700-ec75-40ec-ad50-94c03af4f5f5/jobs/1711/tests#failed-test-0]` failing, but this is a known issue in 4.0 (see https://issues.apache.org/jira/browse/CASSANDRA-18366) [java8_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/67/workflows/a21ac700-ec75-40ec-ad50-94c03af4f5f5] [java11_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/67/workflows/a1bc4c2a-3fef-48c7-a387-6005e4c55676] 3.11 [java8_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/68/workflows/74205a42-1f5b-4813-9492-d71b0879675a] was (Author: drohrer): in-jvm-dtest change: [https://github.com/apache/cassandra-in-jvm-dtest-api/pull/34] -Once we have a snapshot build of the API I'll post PRs for trunk/4.1/4.0/3.11- Trunk patch: [https://github.com/apache/cassandra/pull/2318] 4.1: [https://github.com/apache/cassandra/pull/2328] 4.0: [https://github.com/apache/cassandra/pull/2326] 3.11: [https://github.com/apache/cassandra/pull/2322] Circle CI builds: Trunk: [java8_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/61/workflows/d66e58c2-e4b8-4be5-aab6-67dca04acda1] [java11_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/61/workflows/252cfa8b-8dd2-48ca-91e2-35a238bb9afb] 4.1: [java8_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/62/workflows/db90513b-b962-4068-97e1-3f86204213ca] [java11_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/62/workflows/fe854086-6762-4d1d-8a54-fe7f3bb85e5e] 4.0: [java8_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/60/workflows/fca92510-aa38-486a-9a65-600662817991] [java11_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/60/workflows/99ba34a6-f3df-4e4b-9dbe-cdd3a0b86a6c] 3.11 [java8_tests|https://app.circleci.com/pipelines/github/JeetKunDoug/cassandra/59/workflows/b3b5a8d7-a515-49cf-813e-2c2dd08aceb9] (One unrelated failed in-jvm-dtest that I've seen a few times so far: testReprepareMixedVersionWithoutReset) > Add support for JMX in the in-jvm dtest framework > - > > Key: CASSANDRA-18511 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18511 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Doug Rohrer >Assignee: Doug Rohrer >Priority: Normal > Labels: pull-request-available > Fix For: 3.11.x, 4.0.x, 4.1.x, 5.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > In many cases, it would be useful to be able to enable JMX endpoints within > the in-jvm dtest framework, including the existing JMX Getter test, which > used to simply spin up a JMX registry and then leave it running. There are > quite a few JMX-related functions that don’t have tests today, and some > external usages of the in-jvm dtest framework could also benefit from > exposing JMX like we did Native before. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16222) CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics
[ https://issues.apache.org/jira/browse/CASSANDRA-16222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francisco Guerrero reassigned CASSANDRA-16222: -- Assignee: Francisco Guerrero > CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics > > > Key: CASSANDRA-16222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16222 > Project: Cassandra > Issue Type: New Feature > Components: Tool/external >Reporter: James Berragan >Assignee: Francisco Guerrero >Priority: Normal > Fix For: NA > > Attachments: sparkbulkreader.patch > > > *Description:* > This ticket introduces the Spark-Cassandra Bulk Analytics library and > associated Cassandra Sidecar endpoints. > > Please see > [CEP-28|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-28%3A+Reading+and+Writing+Cassandra+Data+with+Spark+Bulk+Analytics] > for more details, motivation, and available source code links. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18434) yaml should explain behavior from CASSANDRA-13325
[ https://issues.apache.org/jira/browse/CASSANDRA-18434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722234#comment-17722234 ] Sudeep Rao commented on CASSANDRA-18434: Hi Brandon, thanks for letting me know. Will make the change. > yaml should explain behavior from CASSANDRA-13325 > - > > Key: CASSANDRA-18434 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18434 > Project: Cassandra > Issue Type: Bug > Components: Feature/Encryption >Reporter: Brandon Williams >Assignee: Sudeep Rao >Priority: Normal > Labels: lhf > Fix For: 4.0.x, 4.1.x, 5.x > > > After CASSANDRA-13325, it is possible in the yaml to set the 'protocol' > option in a given encryption_options to the csv list of acceptable protocols, > as we do in [this > test|https://github.com/apache/cassandra-dtest/blob/trunk/cqlsh_tests/test_cqlsh.py#L185] > to limit it to TLSv1.2. However, there is no way to know this from the yaml > today, so some comments/example would be helpful. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-11471) Add SASL mechanism negotiation to the native protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722232#comment-17722232
]
Derek Chen-Becker edited comment on CASSANDRA-11471 at 5/12/23 4:26 PM:
We had some discussion via Slack today and I wanted to summarize an alternative
proposal:
Instead of using a new message with AUTHENTICATE, we can leverage the OPTIONS
message that the client can send. The following changes would be required:
1. Make changes to the server so that it can be configured with more than one
supported mechanism. This will require some changes to the configuration
handling as well as some changes in the AuthN path to select the mechanism
provided by the customer in the AUTHENTICATE message
2. Make changes to the server so that it returns a new property in the
SUPPORTED message indicating a set (or list in order of preference?) of
supported AuthN mechanisms
3. Clients would need to be changed to recognize and utilize the new SUPPORTED
property
The primary benefit of leveraging OPTIONS/SUPPORTED to communicate supported
mechanisms is that it would be backwards compatible with existing clients and
would not require a change to the protocol messages. Additionally, change #1
would allow clients that don't use the OPTIONS message to still benefit from
being able to transition between AuthN mechanisms.
was (Author: dchenbecker):
We had some discussion via Slack today and I wanted to summarize an alternative
proposal:
Instead of using a new message with AUTHENTICATE, we can leverage the OPTIONS
message that the client can send. The following changes would be required:
1. Make changes to the server so that it can be configured with more than one
supported mechanism. This will require some changes to the configuration
handling as well as some changes in the AuthN path to select the mechanism
provided by the customer in the AUTHENTICATE message
2. Make changes to the server so that it returns a new property in the
SUPPORTED message indicating a set (or list in order of preference?) of
supported AuthN mechanisms
3. Clients would need to be changed to recognize and utilize the new SUPPORTED
property
The primary benefit of leveraging OPTIONS/SUPPORTED to communicate supported
mechanisms is that it would be backwards compatible with existing clients and
would not require a change to the protocol messages.
> Add SASL mechanism negotiation to the native protocol
> -
>
> Key: CASSANDRA-11471
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11471
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/CQL
>Reporter: Sam Tunnicliffe
>Assignee: Ben Bromhead
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-11471
>
>
> Introducing an additional message exchange into the authentication sequence
> would allow us to support multiple authentication schemes and [negotiation of
> SASL mechanisms|https://tools.ietf.org/html/rfc4422#section-3.2].
> The current {{AUTHENTICATE}} message sent from Client to Server includes the
> java classname of the configured {{IAuthenticator}}. This could be superceded
> by a new message which lists the SASL mechanisms supported by the server. The
> client would then respond with a new message which indicates it's choice of
> mechanism. This would allow the server to support multiple mechanisms, for
> example enabling both {{PLAIN}} for username/password authentication and
> {{EXTERNAL}} for a mechanism for extracting credentials from SSL
> certificates\* (see the example in
> [RFC-4422|https://tools.ietf.org/html/rfc4422#appendix-A]). Furthermore, the
> server could tailor the list of supported mechanisms on a per-connection
> basis, e.g. only offering certificate based auth to encrypted clients.
> The client's response should include the selected mechanism and any initial
> response data. This is mechanism-specific; the {{PLAIN}} mechanism consists
> of a single round in which the client sends encoded credentials as the
> initial response data and the server response indicates either success or
> failure with no futher challenges required.
> From a protocol perspective, after the mechanism negotiation the exchange
> would continue as in protocol v4, with one or more rounds of
> {{AUTH_CHALLENGE}} and {{AUTH_RESPONSE}} messages, terminated by an
> {{AUTH_SUCCESS}} sent from Server to Client upon successful authentication or
> an {{ERROR}} on auth failure.
> XMPP performs mechanism negotiation in this way,
> [RFC-3920|http://tools.ietf.org/html/rfc3920#section-6] includes a good
> overview.
> \* Note: this would require some a priori agreement between client and server
> over the implementation of the {{EXTERNAL}}
[jira] [Commented] (CASSANDRA-11471) Add SASL mechanism negotiation to the native protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722232#comment-17722232
]
Derek Chen-Becker commented on CASSANDRA-11471:
---
We had some discussion via Slack today and I wanted to summarize an alternative
proposal:
Instead of using a new message with AUTHENTICATE, we can leverage the OPTIONS
message that the client can send. The following changes would be required:
1. Make changes to the server so that it can be configured with more than one
supported mechanism. This will require some changes to the configuration
handling as well as some changes in the AuthN path to select the mechanism
provided by the customer in the AUTHENTICATE message
2. Make changes to the server so that it returns a new property in the
SUPPORTED message indicating a set (or list in order of preference?) of
supported AuthN mechanisms
3. Clients would need to be changed to recognize and utilize the new SUPPORTED
property
The primary benefit of leveraging OPTIONS/SUPPORTED to communicate supported
mechanisms is that it would be backwards compatible with existing clients and
would not require a change to the protocol messages.
> Add SASL mechanism negotiation to the native protocol
> -
>
> Key: CASSANDRA-11471
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11471
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/CQL
>Reporter: Sam Tunnicliffe
>Assignee: Ben Bromhead
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-11471
>
>
> Introducing an additional message exchange into the authentication sequence
> would allow us to support multiple authentication schemes and [negotiation of
> SASL mechanisms|https://tools.ietf.org/html/rfc4422#section-3.2].
> The current {{AUTHENTICATE}} message sent from Client to Server includes the
> java classname of the configured {{IAuthenticator}}. This could be superceded
> by a new message which lists the SASL mechanisms supported by the server. The
> client would then respond with a new message which indicates it's choice of
> mechanism. This would allow the server to support multiple mechanisms, for
> example enabling both {{PLAIN}} for username/password authentication and
> {{EXTERNAL}} for a mechanism for extracting credentials from SSL
> certificates\* (see the example in
> [RFC-4422|https://tools.ietf.org/html/rfc4422#appendix-A]). Furthermore, the
> server could tailor the list of supported mechanisms on a per-connection
> basis, e.g. only offering certificate based auth to encrypted clients.
> The client's response should include the selected mechanism and any initial
> response data. This is mechanism-specific; the {{PLAIN}} mechanism consists
> of a single round in which the client sends encoded credentials as the
> initial response data and the server response indicates either success or
> failure with no futher challenges required.
> From a protocol perspective, after the mechanism negotiation the exchange
> would continue as in protocol v4, with one or more rounds of
> {{AUTH_CHALLENGE}} and {{AUTH_RESPONSE}} messages, terminated by an
> {{AUTH_SUCCESS}} sent from Server to Client upon successful authentication or
> an {{ERROR}} on auth failure.
> XMPP performs mechanism negotiation in this way,
> [RFC-3920|http://tools.ietf.org/html/rfc3920#section-6] includes a good
> overview.
> \* Note: this would require some a priori agreement between client and server
> over the implementation of the {{EXTERNAL}} mechanism.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18521) Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
[
https://issues.apache.org/jira/browse/CASSANDRA-18521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722231#comment-17722231
]
Andres de la Peña commented on CASSANDRA-18521:
---
Here is a patch:
||PR||CI||
|[cep-7-sai|https://github.com/apache/cassandra/pull/2329]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2892/workflows/d6f09762-97f1-409f-90b7-aa69c7951668]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2892/workflows/837b186e-6cd9-442c-baaf-8bc067f56b21]|
[The first
commit|https://github.com/apache/cassandra/pull/2329/commits/9722461016ab0a4ee4a0a0e55b5ed6bdd9ba7023]
moves {{SAITester#waitForIndexQueryable}} to {{CQLTester}} and renames the
methods. So {{CQLTester}} has separate {{waitForIndexQueryable}} and
{{waitForTableIndexesQueryable}} methods.
[The second
commit|https://github.com/apache/cassandra/pull/2329/commits/fbf68d158f6d074dc1cc2330397d45f5f4b936d5]
addresses the addition of a version of {{CQLTester#createIndex}} that waits
for the index to become queryable.
There are hundred of calls to {{createIndex}} outside the index package. Most
of these calls don't use any of the utility methods to wait for the index.
Instead, the rely on the fact that [legacy indexes don't have an initialization
task when the indexed table is
empty|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L171].
This makes the creation of a legacy index on an empty table a blocking
operation. Most tests exploit this by creating the index before inserting data,
so they don't have to wait for the index build. I think this comes from a time
when the methods for waiting for the index build didn't exist.
I think that approach is risky because it depends on the particular
implementation of secondary indexes. The index API doesn't offer any guarantees
of synchronicity when creating indexes on empty tables. Indeed, SAI always does
an asynchronous index creation. So those hundred tests can become flaky if
someday we make SAI the default implementation. Thus, I think that those tests
should use the variant of {{createIndex}} that waits for the index.
I think most new tests would also want to use the synchronous
{{{}createIndex{}}}. Developers unaware of the asynchronous index creation
should probably be directed to the synchronous {{{}createIndex{}}}.
On the other hand, the asynchronous {{createIndex}} seems to be useful for
tests validating the asynchronous building itself, and anyone writing those
tests would probably be familiarized index building mechanism they are testing.
So I have made {{CQLTester#createIndex}} the synchronous method, which should
solve the problem of not properly waiting for the index on the many tests
outside the index package. The asynchronous index creation can be done with a
new {{CQLTester#createIndexAsync}} method, which is equivalent to the previous
old {{{}createIndex{}}}, and that is only used for tests related with the index
building process.
It's worth mentioning that using the sync method when one needs to use the sync
method usually leads to a consistent assertion error when the wait for the
index build expires. However, using the async method when one needs to use the
sync method produces flaky tests that are much harder to catch. That's why I
prefer to make the sync method the default and not naming it
{{{}createIndexSync{}}}, {{{}createIndexWaitingForQueryable{}}}, or something
like that. wdyt?
I have also included some fixes in {{{}CQLTester#getCreateIndexName{}}}, which
was producing wrong index names in some cases.
> Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
>
>
> Key: CASSANDRA-18521
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18521
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: NA
>
>
> It has been
> [mentioned|https://github.com/maedhroz/cassandra/pull/11#discussion_r1190166765]
> in CASSANDRA-18217 that {{CQLTester#waitForIndex}} and
> {{SAITester#waitForIndexQueryable}} can be unified into a single method.
> The same discussion mentions that it's easy to forget to call those methods
> after calling {{CQLTester#createIndex}}. So that method can be renamed to
> {{createIndexAsync}}, and we can create a new method that creates the index
> and waits for it ({{createIndexSync}}, {{createIndexAndWaitForQueryable}}, or
> something like that).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail:
[jira] [Updated] (CASSANDRA-18521) Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
[
https://issues.apache.org/jira/browse/CASSANDRA-18521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18521:
--
Test and Documentation Plan:
||PR||CI||
|[cep-7-sai|https://github.com/apache/cassandra/pull/2329]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2892/workflows/d6f09762-97f1-409f-90b7-aa69c7951668]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2892/workflows/837b186e-6cd9-442c-baaf-8bc067f56b21]|
Status: Patch Available (was: In Progress)
> Unify CQLTester#waitForIndex and SAITester#waitForIndexQueryable
>
>
> Key: CASSANDRA-18521
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18521
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: NA
>
>
> It has been
> [mentioned|https://github.com/maedhroz/cassandra/pull/11#discussion_r1190166765]
> in CASSANDRA-18217 that {{CQLTester#waitForIndex}} and
> {{SAITester#waitForIndexQueryable}} can be unified into a single method.
> The same discussion mentions that it's easy to forget to call those methods
> after calling {{CQLTester#createIndex}}. So that method can be renamed to
> {{createIndexAsync}}, and we can create a new method that creates the index
> and waits for it ({{createIndexSync}}, {{createIndexAndWaitForQueryable}}, or
> something like that).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18434) yaml should explain behavior from CASSANDRA-13325
[ https://issues.apache.org/jira/browse/CASSANDRA-18434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18434: - Status: Open (was: Patch Available) > yaml should explain behavior from CASSANDRA-13325 > - > > Key: CASSANDRA-18434 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18434 > Project: Cassandra > Issue Type: Bug > Components: Feature/Encryption >Reporter: Brandon Williams >Assignee: Sudeep Rao >Priority: Normal > Labels: lhf > Fix For: 4.0.x, 4.1.x, 5.x > > > After CASSANDRA-13325, it is possible in the yaml to set the 'protocol' > option in a given encryption_options to the csv list of acceptable protocols, > as we do in [this > test|https://github.com/apache/cassandra-dtest/blob/trunk/cqlsh_tests/test_cqlsh.py#L185] > to limit it to TLSv1.2. However, there is no way to know this from the yaml > today, so some comments/example would be helpful. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18434) yaml should explain behavior from CASSANDRA-13325
[ https://issues.apache.org/jira/browse/CASSANDRA-18434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722230#comment-17722230 ] Brandon Williams commented on CASSANDRA-18434: -- Hi Sudeep, welcome and thanks for the patch! Unfortunately, this isn't correct, there is no 'accepted_protocols' field, there is only the 'protocol' field. The proposal at the end of [this comment|https://issues.apache.org/jira/browse/CASSANDRA-13325?focusedCommentId=17205879=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17205879] from Jon Meredith is what has been implemented and needs to be expounded on in the yaml. > yaml should explain behavior from CASSANDRA-13325 > - > > Key: CASSANDRA-18434 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18434 > Project: Cassandra > Issue Type: Bug > Components: Feature/Encryption >Reporter: Brandon Williams >Assignee: Sudeep Rao >Priority: Normal > Labels: lhf > Fix For: 4.0.x, 4.1.x, 5.x > > > After CASSANDRA-13325, it is possible in the yaml to set the 'protocol' > option in a given encryption_options to the csv list of acceptable protocols, > as we do in [this > test|https://github.com/apache/cassandra-dtest/blob/trunk/cqlsh_tests/test_cqlsh.py#L185] > to limit it to TLSv1.2. However, there is no way to know this from the yaml > today, so some comments/example would be helpful. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18434) yaml should explain behavior from CASSANDRA-13325
[ https://issues.apache.org/jira/browse/CASSANDRA-18434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1777#comment-1777 ] Sudeep Rao commented on CASSANDRA-18434: Hi, I am a new contributor. Picked this bug from the Low Hanging Fruit Jira list. I have pushed up a branch for review. [Branch|https://github.com/sudeepraovm/cassandra/tree/CASSANDRA-18434] [PR|https://github.com/apache/cassandra/pull/2330] > yaml should explain behavior from CASSANDRA-13325 > - > > Key: CASSANDRA-18434 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18434 > Project: Cassandra > Issue Type: Bug > Components: Feature/Encryption >Reporter: Brandon Williams >Assignee: Sudeep Rao >Priority: Normal > Labels: lhf > Fix For: 4.0.x, 4.1.x, 5.x > > > After CASSANDRA-13325, it is possible in the yaml to set the 'protocol' > option in a given encryption_options to the csv list of acceptable protocols, > as we do in [this > test|https://github.com/apache/cassandra-dtest/blob/trunk/cqlsh_tests/test_cqlsh.py#L185] > to limit it to TLSv1.2. However, there is no way to know this from the yaml > today, so some comments/example would be helpful. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18434) yaml should explain behavior from CASSANDRA-13325
[ https://issues.apache.org/jira/browse/CASSANDRA-18434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudeep Rao updated CASSANDRA-18434: --- Test and Documentation Plan: NA Status: Patch Available (was: Open) > yaml should explain behavior from CASSANDRA-13325 > - > > Key: CASSANDRA-18434 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18434 > Project: Cassandra > Issue Type: Bug > Components: Feature/Encryption >Reporter: Brandon Williams >Assignee: Sudeep Rao >Priority: Normal > Labels: lhf > Fix For: 4.0.x, 4.1.x, 5.x > > > After CASSANDRA-13325, it is possible in the yaml to set the 'protocol' > option in a given encryption_options to the csv list of acceptable protocols, > as we do in [this > test|https://github.com/apache/cassandra-dtest/blob/trunk/cqlsh_tests/test_cqlsh.py#L185] > to limit it to TLSv1.2. However, there is no way to know this from the yaml > today, so some comments/example would be helpful. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16895) Build with Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16895: Description: This ticket is intended to group all issues found to support Java 17 in the future. Upgrade steps: * [Dependencies |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to be updated (not all but at least those that require an update in order to work with Java 17) * More encapsulated JDK internal APIs. Some of the issues might be solved with the dependencies updates * Currently trunk compiles if we remove the Nashorn dependency (ant script tag, used for the test environment; UDFs) . The oracle recommendation to use Nashorn-core won't work for the project as it is under GPL 2.0. Most probably we will opt in for graal-sdk licensed under UPL * All tests to be cleaned * CI environment to be setup *NOTE:* GC tuning, performance testing were never agreed to be part of this ticket. Below is a snapshot of current CI failures with JDK17, it will be updated on a regular basis with a date of update *May 12th 2023* || ||Failing Test Classes||Ticket Numbers|| | |_Python DTests_| | |1|test_sjk|CASSANDRA-18343| | |_Java Ditributed Tests_| | |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all tests, org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests, org.apache.cassandra.distributed.test.IPMembershipTest - both tests, org.apache.cassandra.distributed.test.MixedModeFuzzTest, org.apache.cassandra.distributed.test.ReprepareFuzzTest, org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304| |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest - all tests org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all tests|Both tests suffer from CASSANDRA-18180 fwiw, using the CASSANDRA-18180 branch, only the negotiatedProtocolMustBeAcceptedProtocolTest fails in both these tests. | |9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest - 2 tests|CASSANDRA-18180| | |_Unit Tests_| | |1|org.apache.cassandra.repair.RepairJobTest - 1 test|CASSANDRA-17884| |2|org.apache.cassandra.security.SSLFactoryTest - all tests|CASSANDRA-17992| |3,4|org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest, org.apache.cassandra.utils.concurrent.RefCountedTest|CASSANDRA-18329| |5,6|org.apache.cassandra.cql3.validation.entities.UFJavaTest, org.apache.cassandra.cql3.validation.entities.UFSecurityTest|CASSANDRA-18190| |7|org.apache.cassandra.cql3.EmptyValuesTest|CASSANDRA-18436| |8|org.apache.cassandra.transport.MessagePayloadTest-.jdk17|CASSANDRA-18437| was: This ticket is intended to group all issues found to support Java 17 in the future. Upgrade steps: * [Dependencies |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to be updated (not all but at least those that require an update in order to work with Java 17) * More encapsulated JDK internal APIs. Some of the issues might be solved with the dependencies updates * Currently trunk compiles if we remove the Nashorn dependency (ant script tag, used for the test environment; UDFs) . The oracle recommendation to use Nashorn-core won't work for the project as it is under GPL 2.0. Most probably we will opt in for graal-sdk licensed under UPL * All tests to be cleaned * CI environment to be setup *NOTE:* GC tuning, performance testing were never agreed to be part of this ticket. Below is a snapshot of current CI failures with JDK17, it will be updated on a regular basis with a date of update *April 7th 2023* || ||Failing Test Classes||Ticket Numbers|| | |_Python DTests_| | |1|test_sjk|CASSANDRA-18343| | |_Java Ditributed Tests_| | |1-6|org.apache.cassandra.distributed.test.ReprepareOldBehaviourTest - all tests, org.apache.cassandra.distributed.test.PrepareBatchStatementsTest - all tests, org.apache.cassandra.distributed.test.IPMembershipTest - both tests, org.apache.cassandra.distributed.test.MixedModeFuzzTest, org.apache.cassandra.distributed.test.ReprepareFuzzTest, org.apache.cassandra.distributed.test.ReprepareNewBehaviourTest|CASSANDRA-16304| |7,8|org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest - all tests org.apache.cassandra.distributed.test.InternodeEncryptionOptionsTest - all tests|Both tests suffer from CASSANDRA-18180 fwiw, using the CASSANDRA-18180 branch, only the negotiatedProtocolMustBeAcceptedProtocolTest fails in both these tests. | |9|org.apache.cassandra.distributed.test.SSTableLoaderEncryptionOptionsTest - 2 tests|CASSANDRA-18180| | |_Unit Tests_| | |1|org.apache.cassandra.repair.RepairJobTest - 1 test|CASSANDRA-17884| |2|org.apache.cassandra.security.SSLFactoryTest - all tests|CASSANDRA-17992| |3,4|org.apache.cassandra.db.memtable.MemtableSizeOffheapBuffersTest,
[jira] [Created] (CASSANDRA-18525) Add keyspace column to clients virtual table
n.v.harikrishna created CASSANDRA-18525: --- Summary: Add keyspace column to clients virtual table Key: CASSANDRA-18525 URL: https://issues.apache.org/jira/browse/CASSANDRA-18525 Project: Cassandra Issue Type: Improvement Reporter: n.v.harikrishna Assignee: n.v.harikrishna Clients virtual table doesn’t have keyspace information. ‘clientstats' nodetool has this information. Adding keyspace column to clients virtual table helps not to fallback to nodetool command. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18401) Investigate preloading ccm repositories in the docker image
[ https://issues.apache.org/jira/browse/CASSANDRA-18401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722213#comment-17722213 ] Brandon Williams commented on CASSANDRA-18401: -- Makes sense to me, thanks. I'll keep an eye out on Sunday too :) > Investigate preloading ccm repositories in the docker image > --- > > Key: CASSANDRA-18401 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18401 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > > In CASSANDRA-18391 it was discovered that to skip some upgrade tests, the ccm > repository first needed to be populated with older versions. While that case > was solved, it may still be beneficial to preload the ccm repositories in the > docker image so they don't need to be fetched at all. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18401) Investigate preloading ccm repositories in the docker image
[ https://issues.apache.org/jira/browse/CASSANDRA-18401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722211#comment-17722211 ] Ekaterina Dimitrova commented on CASSANDRA-18401: - The runs completed successfully but I will push the image on Sunday when there are less people working and I will be available to check on glitches post-push :) > Investigate preloading ccm repositories in the docker image > --- > > Key: CASSANDRA-18401 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18401 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x > > > In CASSANDRA-18391 it was discovered that to skip some upgrade tests, the ccm > repository first needed to be populated with older versions. While that case > was solved, it may still be beneficial to preload the ccm repositories in the > docker image so they don't need to be fetched at all. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18434) yaml should explain behavior from CASSANDRA-13325
[ https://issues.apache.org/jira/browse/CASSANDRA-18434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudeep Rao reassigned CASSANDRA-18434: -- Assignee: Sudeep Rao > yaml should explain behavior from CASSANDRA-13325 > - > > Key: CASSANDRA-18434 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18434 > Project: Cassandra > Issue Type: Bug > Components: Feature/Encryption >Reporter: Brandon Williams >Assignee: Sudeep Rao >Priority: Normal > Labels: lhf > Fix For: 4.0.x, 4.1.x, 5.x > > > After CASSANDRA-13325, it is possible in the yaml to set the 'protocol' > option in a given encryption_options to the csv list of acceptable protocols, > as we do in [this > test|https://github.com/apache/cassandra-dtest/blob/trunk/cqlsh_tests/test_cqlsh.py#L185] > to limit it to TLSv1.2. However, there is no way to know this from the yaml > today, so some comments/example would be helpful. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18436) Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally failing with JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18436:
Since Version: (was: 4.1.0)
> Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally
> failing with JDK17
> -
>
> Key: CASSANDRA-18436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18436
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.0
>
>
>
> All of them failed with the below stack trace for the same assertion failing:
> {code:java}
> junit.framework.AssertionFailedError: at
> org.apache.cassandra.cql3.EmptyValuesTest.verify(EmptyValuesTest.java:90) at
> org.apache.cassandra.cql3.EmptyValuesTest.verifyJsonInsert(EmptyValuesTest.java:112)
> at
> org.apache.cassandra.cql3.EmptyValuesTest.testEmptyDecimal(EmptyValuesTest.java:192)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
> Unfortunately I do not have a link to the CI run as this was seen last in
> private infra and not in CircleCI. Maybe we want to check with the
> multiplexer for flakiness.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18436) Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally failing with JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722205#comment-17722205
]
Ekaterina Dimitrova commented on CASSANDRA-18436:
-
Committed to https://github.com/apache/cassandra
[290bd0d337..5768e5ae41 trunk ->
trunk|https://github.com/apache/cassandra/commit/5768e5ae41879885e7e2aca79b38bed53df55711]
> Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally
> failing with JDK17
> -
>
> Key: CASSANDRA-18436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18436
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
>
>
> All of them failed with the below stack trace for the same assertion failing:
> {code:java}
> junit.framework.AssertionFailedError: at
> org.apache.cassandra.cql3.EmptyValuesTest.verify(EmptyValuesTest.java:90) at
> org.apache.cassandra.cql3.EmptyValuesTest.verifyJsonInsert(EmptyValuesTest.java:112)
> at
> org.apache.cassandra.cql3.EmptyValuesTest.testEmptyDecimal(EmptyValuesTest.java:192)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
> Unfortunately I do not have a link to the CI run as this was seen last in
> private infra and not in CircleCI. Maybe we want to check with the
> multiplexer for flakiness.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18436) Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally failing with JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18436:
Fix Version/s: 5.0
(was: 5.x)
Since Version: 4.1.0
Source Control Link:
https://github.com/apache/cassandra/commit/5768e5ae41879885e7e2aca79b38bed53df55711
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally
> failing with JDK17
> -
>
> Key: CASSANDRA-18436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18436
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.0
>
>
>
> All of them failed with the below stack trace for the same assertion failing:
> {code:java}
> junit.framework.AssertionFailedError: at
> org.apache.cassandra.cql3.EmptyValuesTest.verify(EmptyValuesTest.java:90) at
> org.apache.cassandra.cql3.EmptyValuesTest.verifyJsonInsert(EmptyValuesTest.java:112)
> at
> org.apache.cassandra.cql3.EmptyValuesTest.testEmptyDecimal(EmptyValuesTest.java:192)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
> Unfortunately I do not have a link to the CI run as this was seen last in
> private infra and not in CircleCI. Maybe we want to check with the
> multiplexer for flakiness.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Assert successful exit code from sstabledump in org.apache.cassandra.cql3.EmptyValuesTest patch by Daniel Jatnieks; reviewed by Ekaterina Dimitrova and Berenguer Blas
This is an automated email from the ASF dual-hosted git repository.
edimitrova pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 5768e5ae41 Assert successful exit code from sstabledump in
org.apache.cassandra.cql3.EmptyValuesTest patch by Daniel Jatnieks; reviewed by
Ekaterina Dimitrova and Berenguer Blasi for CASSANDRA-18436
5768e5ae41 is described below
commit 5768e5ae41879885e7e2aca79b38bed53df55711
Author: Daniel Jatnieks
AuthorDate: Thu May 4 12:39:46 2023 -0700
Assert successful exit code from sstabledump in
org.apache.cassandra.cql3.EmptyValuesTest
patch by Daniel Jatnieks; reviewed by Ekaterina Dimitrova and Berenguer
Blasi for CASSANDRA-18436
---
test/unit/org/apache/cassandra/cql3/EmptyValuesTest.java | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/test/unit/org/apache/cassandra/cql3/EmptyValuesTest.java
b/test/unit/org/apache/cassandra/cql3/EmptyValuesTest.java
index 3652ac8d14..ff7f861b5f 100644
--- a/test/unit/org/apache/cassandra/cql3/EmptyValuesTest.java
+++ b/test/unit/org/apache/cassandra/cql3/EmptyValuesTest.java
@@ -19,7 +19,6 @@
package org.apache.cassandra.cql3;
import java.io.ByteArrayOutputStream;
-import java.io.PrintStream;
import java.nio.charset.StandardCharsets;
import java.util.regex.Pattern;
@@ -73,17 +72,20 @@ public class EmptyValuesTest extends CQLTester
ByteArrayOutputStream buf = new ByteArrayOutputStream();
for (SSTableReader ssTable : cfs.getLiveSSTables())
{
-try (PrintStream out = new PrintStream(buf, true))
+int exitValue = 0;
+try
{
ProcessBuilder pb = new
ProcessBuilder("tools/bin/sstabledump", ssTable.getFilename());
+pb.redirectErrorStream(true);
Process process = pb.start();
-process.waitFor();
+exitValue = process.waitFor();
IOUtils.copy(process.getInputStream(), buf);
}
catch (Throwable t)
{
Assert.fail(t.getClass().getName());
}
+Assert.assertEquals(buf.toString(), 0, exitValue);
}
String outString = new String(buf.toByteArray(),
StandardCharsets.UTF_8);
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18329) Upgrade jamm
[ https://issues.apache.org/jira/browse/CASSANDRA-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722192#comment-17722192 ] Ekaterina Dimitrova commented on CASSANDRA-18329: - Correct > Upgrade jamm > > > Key: CASSANDRA-18329 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18329 > Project: Cassandra > Issue Type: Task > Components: Jamm >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > Jamm is currently under maintenance that will solve JDK11 issues and enable > it to work with post JDK11+ versions up to JDK17. > This ticket will serve as a placeholder for upgrading Jamm in Cassandra when > the new Jamm release is out. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18329) Upgrade jamm
[ https://issues.apache.org/jira/browse/CASSANDRA-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722192#comment-17722192 ] Ekaterina Dimitrova edited comment on CASSANDRA-18329 at 5/12/23 2:09 PM: -- Correct + new release after the pull request is closed was (Author: e.dimitrova): Correct > Upgrade jamm > > > Key: CASSANDRA-18329 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18329 > Project: Cassandra > Issue Type: Task > Components: Jamm >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > Jamm is currently under maintenance that will solve JDK11 issues and enable > it to work with post JDK11+ versions up to JDK17. > This ticket will serve as a placeholder for upgrading Jamm in Cassandra when > the new Jamm release is out. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18329) Upgrade jamm
[ https://issues.apache.org/jira/browse/CASSANDRA-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722189#comment-17722189 ] Matt Fleming commented on CASSANDRA-18329: -- This ticket is blocked on [https://github.com/jbellis/jamm/pull/50] right? > Upgrade jamm > > > Key: CASSANDRA-18329 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18329 > Project: Cassandra > Issue Type: Task > Components: Jamm >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > Jamm is currently under maintenance that will solve JDK11 issues and enable > it to work with post JDK11+ versions up to JDK17. > This ticket will serve as a placeholder for upgrading Jamm in Cassandra when > the new Jamm release is out. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18436) Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally failing with JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18436:
Reviewers: Berenguer Blasi, Ekaterina Dimitrova (was: Ekaterina Dimitrova)
> Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally
> failing with JDK17
> -
>
> Key: CASSANDRA-18436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18436
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
>
>
> All of them failed with the below stack trace for the same assertion failing:
> {code:java}
> junit.framework.AssertionFailedError: at
> org.apache.cassandra.cql3.EmptyValuesTest.verify(EmptyValuesTest.java:90) at
> org.apache.cassandra.cql3.EmptyValuesTest.verifyJsonInsert(EmptyValuesTest.java:112)
> at
> org.apache.cassandra.cql3.EmptyValuesTest.testEmptyDecimal(EmptyValuesTest.java:192)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
> Unfortunately I do not have a link to the CI run as this was seen last in
> private infra and not in CircleCI. Maybe we want to check with the
> multiplexer for flakiness.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18436) Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally failing with JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722175#comment-17722175
]
Ekaterina Dimitrova commented on CASSANDRA-18436:
-
Thanks [~bereng] , I will commit it soon
> Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally
> failing with JDK17
> -
>
> Key: CASSANDRA-18436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18436
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
>
>
> All of them failed with the below stack trace for the same assertion failing:
> {code:java}
> junit.framework.AssertionFailedError: at
> org.apache.cassandra.cql3.EmptyValuesTest.verify(EmptyValuesTest.java:90) at
> org.apache.cassandra.cql3.EmptyValuesTest.verifyJsonInsert(EmptyValuesTest.java:112)
> at
> org.apache.cassandra.cql3.EmptyValuesTest.testEmptyDecimal(EmptyValuesTest.java:192)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
> Unfortunately I do not have a link to the CI run as this was seen last in
> private infra and not in CircleCI. Maybe we want to check with the
> multiplexer for flakiness.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18436) Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally failing with JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-18436:
Status: Ready to Commit (was: Review In Progress)
> Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally
> failing with JDK17
> -
>
> Key: CASSANDRA-18436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18436
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
>
>
> All of them failed with the below stack trace for the same assertion failing:
> {code:java}
> junit.framework.AssertionFailedError: at
> org.apache.cassandra.cql3.EmptyValuesTest.verify(EmptyValuesTest.java:90) at
> org.apache.cassandra.cql3.EmptyValuesTest.verifyJsonInsert(EmptyValuesTest.java:112)
> at
> org.apache.cassandra.cql3.EmptyValuesTest.testEmptyDecimal(EmptyValuesTest.java:192)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
> Unfortunately I do not have a link to the CI run as this was seen last in
> private infra and not in CircleCI. Maybe we want to check with the
> multiplexer for flakiness.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] branch trunk updated: Updated setting newVersion to look up the current version
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git
The following commit(s) were added to refs/heads/trunk by this push:
new dadade5 Updated setting newVersion to look up the current version
dadade5 is described below
commit dadade5dd5b23156fa9aa90d90f5ecafd5453d8c
Author: dcapwell
AuthorDate: Wed Mar 30 08:57:44 2022 -0700
Updated setting newVersion to look up the current version
---
README.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/README.md b/README.md
index 236e137..eb0bde5 100644
--- a/README.md
+++ b/README.md
@@ -5,7 +5,7 @@ Shared API package for in-JVM distributed tests.
# Publishing snapshot
```
-mvn versions:set -DnewVersion=0.0.2-`git rev-parse --short HEAD`-SNAPSHOT
+mvn versions:set -DnewVersion=`xpath -n -q -e '/project/version/text()'
pom.xml | awk -F- '{print $1}'`-`git rev-parse --short HEAD`-SNAPSHOT
mvn deploy
```
@@ -56,4 +56,4 @@ gpg --verbose --recv-keys --keyserver
hkps://hkps.pool.sks-keyservers.net https://dist.apache.org/repos/dist/release/cassandra/
release
(gpg --list-sigs "" && gpg --armor --export "") >> KEYS
svn commit KEYS -m "Add 's key for releases" # or ask some PMC to
do this for you by opening CASSANDRA jira, like this one:
https://issues.apache.org/jira/browse/CASSANDRA-15534
-```
\ No newline at end of file
+```
-
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 (846508d8 -> 24477a9f)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 846508d8 generate docs for 8b85ed85 new 24477a9f generate docs for 8b85ed85 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 (846508d8) \ N -- N -- N refs/heads/asf-staging (24477a9f) 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/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4796900 -> 4796900 bytes 2 files 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] [Updated] (CASSANDRA-18217) Allow CQL queries on multiple indexes without ALLOW FILTERING
[ https://issues.apache.org/jira/browse/CASSANDRA-18217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-18217: -- Fix Version/s: NA Source Control Link: https://github.com/apache/cassandra/commit/fa85a191c5e0bd508da58441264830769cb9 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Allow CQL queries on multiple indexes without ALLOW FILTERING > - > > Key: CASSANDRA-18217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18217 > Project: Cassandra > Issue Type: Improvement > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Andres de la Peña >Priority: Normal > Labels: SAI > Fix For: NA > > > The Index Group index was added by > [CASSANDRA-16092|https://issues.apache.org/jira/browse/CASSANDRA-16092] to > allow indexes to be grouped and have more than one index expression in a > query. This did not make any changes to StatementRestrictions so CQL queries > using multiple index expression still need to add ALLOW FILTERING to the > query to be valid. > This restriction should be removed such that any number of index expressions > can be used on a CQL query without needing ALLOW FILTERING. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18217) Allow CQL queries on multiple indexes without ALLOW FILTERING
[ https://issues.apache.org/jira/browse/CASSANDRA-18217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722077#comment-17722077 ] Andres de la Peña commented on CASSANDRA-18217: --- Thanks for creating the branch. Committed to the new branch as [fa85a191c5e0bd508da58441264830769cb9|https://github.com/apache/cassandra/commit/fa85a191c5e0bd508da58441264830769cb9]. > Allow CQL queries on multiple indexes without ALLOW FILTERING > - > > Key: CASSANDRA-18217 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18217 > Project: Cassandra > Issue Type: Improvement > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Andres de la Peña >Priority: Normal > Labels: SAI > > The Index Group index was added by > [CASSANDRA-16092|https://issues.apache.org/jira/browse/CASSANDRA-16092] to > allow indexes to be grouped and have more than one index expression in a > query. This did not make any changes to StatementRestrictions so CQL queries > using multiple index expression still need to add ALLOW FILTERING to the > query to be valid. > This restriction should be removed such that any number of index expressions > can be used on a CQL query without needing ALLOW FILTERING. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18523) CEP-15: (Accord) Join cluster without full transaction log
[ https://issues.apache.org/jira/browse/CASSANDRA-18523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith updated CASSANDRA-18523: --- Resolution: Fixed Status: Resolved (was: Triage Needed) > CEP-15: (Accord) Join cluster without full transaction log > -- > > Key: CASSANDRA-18523 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18523 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > > Joining replicas should not require the full transaction history to > successfully start serving queries. This ticket introduces mechanisms for a > replica to join (or catch up) with a data snapshot and all transactions that > execute after that snapshot. This is a precursor for transaction state GC. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18523) CEP-15: (Accord) Join cluster without full transaction log
[ https://issues.apache.org/jira/browse/CASSANDRA-18523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith reassigned CASSANDRA-18523: -- Assignee: Benedict Elliott Smith > CEP-15: (Accord) Join cluster without full transaction log > -- > > Key: CASSANDRA-18523 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18523 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > > Joining replicas should not require the full transaction history to > successfully start serving queries. This ticket introduces mechanisms for a > replica to join (or catch up) with a data snapshot and all transactions that > execute after that snapshot. This is a precursor for transaction state GC. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18175) CEP-15: (Accord) Introduce ExclusiveSyncPoint transactions
[
https://issues.apache.org/jira/browse/CASSANDRA-18175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith reassigned CASSANDRA-18175:
--
Assignee: Benedict Elliott Smith
> CEP-15: (Accord) Introduce ExclusiveSyncPoint transactions
> --
>
> Key: CASSANDRA-18175
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18175
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
>
> Introduce a mechanism for invalidating older {{TxnId}}, so that a newly
> bootstrapped node may have a complete log as of a point in time {{TxnId}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18175) CEP-15: (Accord) Introduce ExclusiveSyncPoint transactions
[
https://issues.apache.org/jira/browse/CASSANDRA-18175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-18175:
---
Resolution: Fixed
Status: Resolved (was: Triage Needed)
> CEP-15: (Accord) Introduce ExclusiveSyncPoint transactions
> --
>
> Key: CASSANDRA-18175
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18175
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
>
> Introduce a mechanism for invalidating older {{TxnId}}, so that a newly
> bootstrapped node may have a complete log as of a point in time {{TxnId}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18524) CEP-15: (Accord) Separate durable and transient listeners
[ https://issues.apache.org/jira/browse/CASSANDRA-18524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith reassigned CASSANDRA-18524: -- Assignee: Benedict Elliott Smith > CEP-15: (Accord) Separate durable and transient listeners > - > > Key: CASSANDRA-18524 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18524 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > > Transient listeners should be handled differently and, ironically, should be > more "persistent" in that they should not disappear when we evict state from > cache. This patch separates listeners into `DurableAndIdempotent` and > `Transient` with the latter being saved in a shared global register that also > more easily permits us to ensure we do not invoke listeners redundantly (and > for listeners themselves to know if we have done so). This is also a stepping > stone to ensuring listeners survive cache eviction. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18524) CEP-15: (Accord) Separate durable and transient listeners
[ https://issues.apache.org/jira/browse/CASSANDRA-18524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith updated CASSANDRA-18524: --- Resolution: Fixed Status: Resolved (was: Triage Needed) > CEP-15: (Accord) Separate durable and transient listeners > - > > Key: CASSANDRA-18524 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18524 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict Elliott Smith >Priority: Normal > > Transient listeners should be handled differently and, ironically, should be > more "persistent" in that they should not disappear when we evict state from > cache. This patch separates listeners into `DurableAndIdempotent` and > `Transient` with the latter being saved in a shared global register that also > more easily permits us to ensure we do not invoke listeners redundantly (and > for listeners themselves to know if we have done so). This is also a stepping > stone to ensuring listeners survive cache eviction. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-accord] branch trunk updated (8226b2d7 -> f7fc6e18)
This is an automated email from the ASF dual-hosted git repository. benedict pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-accord.git from 8226b2d7 CEP-15: (C*) Accord message processing should avoid being passed on to a Stage and run directly in the messageing handler new c58d841f Separate durable and transient listeners new 06500978 Introduce ExclusiveSyncPoint transactions new f7fc6e18 Permit nodes to join a cluster without the full transaction history 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: .gitignore | 1 + accord-core/build.gradle | 4 +- accord-core/src/main/java/accord/api/Agent.java| 7 + .../main/java/accord/api/ConfigurationService.java | 69 ++- .../src/main/java/accord/api/DataStore.java| 94 +++- .../src/main/java/accord/api/ProgressLog.java | 9 +- accord-core/src/main/java/accord/api/Query.java| 3 +- .../src/main/java/accord/api/TopologySorter.java | 2 + accord-core/src/main/java/accord/api/Update.java | 3 +- .../src/main/java/accord/coordinate/CheckOn.java | 17 +- .../main/java/accord/coordinate/CollectDeps.java | 26 +- .../main/java/accord/coordinate/Coordinate.java| 198 --- .../java/accord/coordinate/CoordinateNoOp.java | 100 .../accord/coordinate/CoordinatePreAccept.java | 261 ++ .../accord/coordinate/CoordinateSyncPoint.java | 124 + .../accord/coordinate/CoordinateTransaction.java | 87 ...ordinateFailed.java => CoordinationFailed.java} | 10 +- .../src/main/java/accord/coordinate/Execute.java | 39 +- .../src/main/java/accord/coordinate/Exhausted.java | 7 +- .../java/accord/coordinate/FetchCoordinator.java | 334 .../main/java/accord/coordinate/Invalidated.java | 11 +- .../main/java/accord/coordinate/MaybeRecover.java | 1 + .../src/main/java/accord/coordinate/Persist.java | 22 +- .../src/main/java/accord/coordinate/Preempted.java | 2 +- .../src/main/java/accord/coordinate/Propose.java | 68 ++- .../java/accord/coordinate/ProposeAndExecute.java | 59 +++ .../java/accord/coordinate/ReadCoordinator.java| 32 +- .../src/main/java/accord/coordinate/Recover.java | 96 +++- .../java/accord/coordinate/RecoverWithRoute.java | 2 +- .../src/main/java/accord/coordinate/Timeout.java | 2 +- .../coordinate/tracking/AbstractTracker.java | 25 +- .../coordinate/tracking/FastPathTracker.java | 85 +-- .../coordinate/tracking/InvalidationTracker.java | 2 +- .../accord/coordinate/tracking/QuorumTracker.java | 2 +- .../accord/coordinate/tracking/ReadTracker.java| 49 +- .../coordinate/tracking/RecoveryTracker.java | 2 +- .../accord/coordinate/tracking/ShardOutcome.java | 2 +- .../java/accord/impl/AbstractSafeCommandStore.java | 37 +- .../src/main/java/accord/impl/CommandsForKey.java | 11 +- .../java/accord/impl/InMemoryCommandStore.java | 233 +++-- .../main/java/accord/impl/InMemorySafeCommand.java | 48 +- .../main/java/accord/impl/SafeCommandsForKey.java | 20 + .../main/java/accord/impl/SimpleProgressLog.java | 11 +- .../java/accord/impl/SizeOfIntersectionSorter.java | 1 + .../src/main/java/accord/local/Bootstrap.java | 481 + .../src/main/java/accord/local/Command.java| 160 +++--- .../src/main/java/accord/local/CommandStore.java | 320 +++- .../src/main/java/accord/local/CommandStores.java | 196 +-- .../src/main/java/accord/local/Commands.java | 489 +++-- .../main/java/accord/local/CommonAttributes.java | 10 +- .../src/main/java/accord/local/Listeners.java | 18 +- .../src/main/java/accord/local/LocalBarrier.java | 120 + accord-core/src/main/java/accord/local/Node.java | 102 ++-- .../src/main/java/accord/local/PreLoadContext.java | 100 +++- .../src/main/java/accord/local/SafeCommand.java| 9 +- .../main/java/accord/local/SafeCommandStore.java | 141 - .../src/main/java/accord/local/SaveStatus.java | 16 +- accord-core/src/main/java/accord/local/Status.java | 12 + .../java/accord/messages/AbstractEpochRequest.java | 14 +- .../src/main/java/accord/messages/Accept.java | 10 +- .../src/main/java/accord/messages/Apply.java | 22 +- .../java/accord/messages/BeginInvalidation.java| 11 +- .../main/java/accord/messages/BeginRecovery.java | 58 ++- .../src/main/java/accord/messages/CheckStatus.java | 14 +- .../src/main/java/accord/messages/Commit.java | 23 +- .../src/main/java/accord/messages/Defer.java | 19 +- .../src/main/java/accord/messages/GetDeps.java | 20 +-
[cassandra-accord] 01/03: Separate durable and transient listeners
This is an automated email from the ASF dual-hosted git repository.
benedict pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-accord.git
commit c58d841fbb26aa0f4ecaa782f2471003c4c58412
Author: Benedict Elliott Smith
AuthorDate: Tue Apr 25 13:12:57 2023 +0100
Separate durable and transient listeners
patch by Benedict; reviewed by Ariel Weisberg for CASSANDRA-18524
---
.gitignore | 1 +
accord-core/build.gradle | 4 +-
.../main/java/accord/coordinate/Coordinate.java| 2 +
.../src/main/java/accord/impl/CommandsForKey.java | 8 +-
.../java/accord/impl/InMemoryCommandStore.java | 22 +++-
.../main/java/accord/impl/InMemorySafeCommand.java | 20 +++
.../src/main/java/accord/local/Command.java| 137 -
.../src/main/java/accord/local/CommandStores.java | 4 +-
.../src/main/java/accord/local/Commands.java | 4 +-
.../main/java/accord/local/CommonAttributes.java | 10 +-
.../src/main/java/accord/local/Listeners.java | 18 +--
.../src/main/java/accord/local/SafeCommand.java| 9 +-
.../main/java/accord/local/SafeCommandStore.java | 65 +++---
.../src/main/java/accord/messages/Defer.java | 8 +-
.../src/main/java/accord/messages/ReadData.java| 17 +--
.../main/java/accord/messages/WaitOnCommit.java| 8 +-
.../src/main/java/accord/primitives/Timestamp.java | 10 +-
.../src/test/java/accord/burn/BurnTest.java| 1 +
build.gradle | 1 +
19 files changed, 214 insertions(+), 135 deletions(-)
diff --git a/.gitignore b/.gitignore
index 05fa172a..bd3d7a7f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@
build/
accord-core/build/
accord-maelstrom/build/
+.rat-excludes.txt
diff --git a/accord-core/build.gradle b/accord-core/build.gradle
index bb315b9b..df6203b9 100644
--- a/accord-core/build.gradle
+++ b/accord-core/build.gradle
@@ -39,7 +39,7 @@ dependencies {
}
task burn(type: JavaExec) {
-classpath sourceSets.main.runtimeClasspath, sourceSets.test.output
+classpath sourceSets.main.runtimeClasspath,
sourceSets.test.runtimeClasspath
mainClass = 'accord.burn.BurnTest'
jvmArgs '-Dlogback.configurationFile=burn-logback.xml'
args = ['-c', '1']
@@ -103,7 +103,7 @@ task burnforkloop {
task burnloop {
doLast {
javaexec {
-classpath sourceSets.main.runtimeClasspath, sourceSets.test.output
+classpath sourceSets.main.runtimeClasspath,
sourceSets.test.runtimeClasspath
mainClass = 'accord.burn.BurnTest'
jvmArgs '-Dlogback.configurationFile=burn-logback.xml'
args = ['-c', project.hasProperty('burnTimes') ?
project.getProperty('burnTimes') : '100']
diff --git a/accord-core/src/main/java/accord/coordinate/Coordinate.java
b/accord-core/src/main/java/accord/coordinate/Coordinate.java
index f08dd399..6934cfb9 100644
--- a/accord-core/src/main/java/accord/coordinate/Coordinate.java
+++ b/accord-core/src/main/java/accord/coordinate/Coordinate.java
@@ -117,7 +117,9 @@ public class Coordinate extends
AsyncResults.SettableResult implements C
if (!reply.isOk())
{
+// TODO (expected): reads should not be recovered, so should not
be preempted
// we've been preempted by a recovery coordinator; defer to it,
and wait to hear any result
+preAcceptIsDone = true;
tryFailure(new Preempted(txnId, route.homeKey()));
return;
}
diff --git a/accord-core/src/main/java/accord/impl/CommandsForKey.java
b/accord-core/src/main/java/accord/impl/CommandsForKey.java
index 9c1d20ae..51ceeb31 100644
--- a/accord-core/src/main/java/accord/impl/CommandsForKey.java
+++ b/accord-core/src/main/java/accord/impl/CommandsForKey.java
@@ -41,9 +41,9 @@ public class CommandsForKey
{
public static class SerializerSupport
{
-public static CommandsForKey.Listener listener(Key key)
+public static Listener listener(Key key)
{
-return new CommandsForKey.Listener(key);
+return new Listener(key);
}
public static CommandsForKey create(Key key, Timestamp max,
@@ -229,7 +229,7 @@ public class CommandsForKey
}
}
-public static class Listener implements CommandListener
+public static class Listener implements
Command.DurableAndIdempotentListener
{
protected final Key listenerKey;
@@ -354,7 +354,7 @@ public class CommandsForKey
throw new UnsupportedOperationException();
}
-public final CommandListener asListener()
+public final Command.DurableAndIdempotentListener asListener()
{
return new Listener(key());
}
diff --git a/accord-core/src/main/java/accord/impl/InMemoryCommandStore.java
b/accord-core/src/main/java/accord/impl/InMemoryCommandStore.java
[jira] [Created] (CASSANDRA-18524) CEP-15: (Accord) Separate durable and transient listeners
Benedict Elliott Smith created CASSANDRA-18524: -- Summary: CEP-15: (Accord) Separate durable and transient listeners Key: CASSANDRA-18524 URL: https://issues.apache.org/jira/browse/CASSANDRA-18524 Project: Cassandra Issue Type: Improvement Reporter: Benedict Elliott Smith Transient listeners should be handled differently and, ironically, should be more "persistent" in that they should not disappear when we evict state from cache. This patch separates listeners into `DurableAndIdempotent` and `Transient` with the latter being saved in a shared global register that also more easily permits us to ensure we do not invoke listeners redundantly (and for listeners themselves to know if we have done so). This is also a stepping stone to ensuring listeners survive cache eviction. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18523) CEP-15: (Accord) Join cluster without full transaction log
Benedict Elliott Smith created CASSANDRA-18523: -- Summary: CEP-15: (Accord) Join cluster without full transaction log Key: CASSANDRA-18523 URL: https://issues.apache.org/jira/browse/CASSANDRA-18523 Project: Cassandra Issue Type: Improvement Reporter: Benedict Elliott Smith Joining replicas should not require the full transaction history to successfully start serving queries. This ticket introduces mechanisms for a replica to join (or catch up) with a data snapshot and all transactions that execute after that snapshot. This is a precursor for transaction state GC. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18171) CEP-15: (Accord) Faster SimpleProgressLog and BurnTest
[ https://issues.apache.org/jira/browse/CASSANDRA-18171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith reassigned CASSANDRA-18171: -- Assignee: Benedict Elliott Smith > CEP-15: (Accord) Faster SimpleProgressLog and BurnTest > -- > > Key: CASSANDRA-18171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18171 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > > Some general efficiency improvements, most notably affecting > `SimpleProgressLog`, to manage the list of transactions we expect progress on > rather than polling all transactions. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18174) CEP-15: (Accord/C*) Introduce range transactions
[ https://issues.apache.org/jira/browse/CASSANDRA-18174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith reassigned CASSANDRA-18174: -- Assignee: Benedict Elliott Smith > CEP-15: (Accord/C*) Introduce range transactions > > > Key: CASSANDRA-18174 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18174 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > > Support range transactions in Accord, to facilitate bootstrap. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18172) CEP-15: (Accord/C*) Refactor Timestamp/TxnId
[ https://issues.apache.org/jira/browse/CASSANDRA-18172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith updated CASSANDRA-18172: --- Resolution: Fixed Status: Resolved (was: Triage Needed) > CEP-15: (Accord/C*) Refactor Timestamp/TxnId > > > Key: CASSANDRA-18172 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18172 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict Elliott Smith >Priority: Normal > > Reduce the amount of storage required for Timestamp and TxnId by compressing > epoch to 48 bits, and real/logical to a single 64-bit HLC, while also > supporting flag carrier bits for communicating protocol state information. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18172) CEP-15: (Accord/C*) Refactor Timestamp/TxnId
[ https://issues.apache.org/jira/browse/CASSANDRA-18172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith reassigned CASSANDRA-18172: -- Assignee: Benedict Elliott Smith > CEP-15: (Accord/C*) Refactor Timestamp/TxnId > > > Key: CASSANDRA-18172 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18172 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > > Reduce the amount of storage required for Timestamp and TxnId by compressing > epoch to 48 bits, and real/logical to a single 64-bit HLC, while also > supporting flag carrier bits for communicating protocol state information. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18171) CEP-15: (Accord) Faster SimpleProgressLog and BurnTest
[ https://issues.apache.org/jira/browse/CASSANDRA-18171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith updated CASSANDRA-18171: --- Resolution: Fixed Status: Resolved (was: Triage Needed) > CEP-15: (Accord) Faster SimpleProgressLog and BurnTest > -- > > Key: CASSANDRA-18171 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18171 > Project: Cassandra > Issue Type: Improvement >Reporter: Benedict Elliott Smith >Priority: Normal > > Some general efficiency improvements, most notably affecting > `SimpleProgressLog`, to manage the list of transactions we expect progress on > rather than polling all transactions. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18174) CEP-15: (Accord/C*) Introduce range transactions
[ https://issues.apache.org/jira/browse/CASSANDRA-18174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Elliott Smith updated CASSANDRA-18174: --- Resolution: Fixed Status: Resolved (was: Triage Needed) > CEP-15: (Accord/C*) Introduce range transactions > > > Key: CASSANDRA-18174 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18174 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: Benedict Elliott Smith >Priority: Normal > > Support range transactions in Accord, to facilitate bootstrap. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18173) CEP-15: (Accord/C*) Introduce RangeDeps
[
https://issues.apache.org/jira/browse/CASSANDRA-18173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-18173:
---
Resolution: Fixed
Status: Resolved (was: Triage Needed)
> CEP-15: (Accord/C*) Introduce RangeDeps
> ---
>
> Key: CASSANDRA-18173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18173
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Benedict Elliott Smith
>Priority: Normal
>
> In order to support range transactions, we must be able to separately manage
> dependencies that cover ranges rather than specific keys. This patch splits
> {{Deps}} into {{KeyDeps}} and {{RangeDeps}}, while introducing a new
> {{SearchableRangeList}} structure for efficiently looking up range
> intersections.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18173) CEP-15: (Accord/C*) Introduce RangeDeps
[
https://issues.apache.org/jira/browse/CASSANDRA-18173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith reassigned CASSANDRA-18173:
--
Assignee: Benedict Elliott Smith
> CEP-15: (Accord/C*) Introduce RangeDeps
> ---
>
> Key: CASSANDRA-18173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18173
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
>
> In order to support range transactions, we must be able to separately manage
> dependencies that cover ranges rather than specific keys. This patch splits
> {{Deps}} into {{KeyDeps}} and {{RangeDeps}}, while introducing a new
> {{SearchableRangeList}} structure for efficiently looking up range
> intersections.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722067#comment-17722067
]
Manish Ghildiyal edited comment on CASSANDRA-18305 at 5/12/23 8:24 AM:
---
I see that a call to NodeProbe:getCompactionThroughputMebibytesAsDouble
eventually reads Config.compaction_throughput.toMebibytesPerSecond(), ie what
is configured.
Is this expected behaviour?
I assume this NodeProbe must fetch me current compaction, not what is
configured.
Maybe I should ask it on slack dev channel too.
was (Author: manish.c.ghildi...@gmail.com):
I see that a call to NodeProbe:getCompactionThroughputMebibytesAsDouble
eventually reads Config.compaction_throughput.toMebibytesPerSecond(), ie what
is configured.
Is this expected behaviour?
I assume this NodeProbe must fetch me current compaction, not what is
configured.
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722067#comment-17722067
]
Manish Ghildiyal commented on CASSANDRA-18305:
--
I see that a call to NodeProbe:getCompactionThroughputMebibytesAsDouble
eventually reads Config.compaction_throughput.toMebibytesPerSecond(), ie what
is configured.
Is this expected behaviour?
I assume this NodeProbe must fetch me current compaction, not what is
configured.
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14319) nodetool rebuild from DC lets you pass invalid datacenters
[
https://issues.apache.org/jira/browse/CASSANDRA-14319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720437#comment-17720437
]
Stefan Miklosovic edited comment on CASSANDRA-14319 at 5/12/23 8:22 AM:
trunk [https://github.com/apache/cassandra/pull/2309]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/c0b0e974-fdb1-4410-a180-fc8890c9a7e5]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/4fc8308c-3f07-4b41-9ad3-3a20a547c0e9]
4.1 [https://github.com/apache/cassandra/pull/2323]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2194/workflows/e6aee8b6-95e7-446f-879d-a66bb4275255]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2194/workflows/bae89aec-bbe4-4705-bcdf-fc4fdecbfe3a]
was (Author: smiklosovic):
trunk [https://github.com/apache/cassandra/pull/2309]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/c0b0e974-fdb1-4410-a180-fc8890c9a7e5]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2185/workflows/4fc8308c-3f07-4b41-9ad3-3a20a547c0e9]
4.1 [https://github.com/apache/cassandra/pull/2323]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2191/workflows/47f1d14c-e781-46d5-b68e-ff74a20fd8d1]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2191/workflows/e9dd84d7-5958-4297-949d-e7a2c0de31a6]
4.0 [https://github.com/apache/cassandra/pull/2324]
j11
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2192/workflows/ef27fb13-21b2-4e3d-8bea-52dfa5fe9ab1]
j8
[https://app.circleci.com/pipelines/github/instaclustr/cassandra/2192/workflows/707a5302-fda0-41b8-8c9e-710897022562]
3.11 [https://github.com/apache/cassandra/pull/2325]
j8
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2193/workflows/126c4214-46f3-4dd0-8156-d2bf58f375e1
> nodetool rebuild from DC lets you pass invalid datacenters
> ---
>
> Key: CASSANDRA-14319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14319
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Jon Haddad
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Attachments: CASSANDRA-14319-trunk.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you pass an invalid datacenter to nodetool rebuild, you'll get an error
> like this:
> {code}
> Unable to find sufficient sources for streaming range
> (3074457345618258602,-9223372036854775808] in keyspace system_distributed
> {code}
> Unfortunately, this is a rabbit hole of frustration if you are using caps for
> your DC names and you pass in a lowercase DC name, or you just typo the DC.
> Let's do the following:
> # Check the DC name that's passed in against the list of DCs we know about
> # If we don't find it, let's output a reasonable error, and list all the DCs
> someone could put in.
> # Ideally we indicate which keyspaces are set to replicate to this DC and
> which aren't
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18075) Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4) nodes during upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-18075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722053#comment-17722053
]
Alaykumar Barochia commented on CASSANDRA-18075:
I already tried option: 1 by setting ssl_storage_port to 7001 on 4.0 node. It
didn't help.
Also, we have already firewall port open for both ports 7000 and 7001 in TAP so
option:2 is also ruled out.
Today, I tried the opposite, make 3.11 cluster to use 7000 for SSL/TLS and then
tried upgrade to 4.0. Still the same issue.
*3.11.4 cluster: (Have set ssl_storage_port: 7000)*
{noformat}
Datacenter: c3ssl_dev_tap_ttc
=
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- AddressLoad Tokens Owns (effective) Host ID
Rack
UN 10.109.44.76 128.32 KiB 16 63.1%
325e24b3-81b9-4d19-abaf-1bb61f662be5 rack1
UN 10.109.30.228 153.03 KiB 16 71.1%
4d1ff6ec-d781-474d-9862-4b31f1f583fe rack1
UN 10.109.44.177 152.91 KiB 16 65.8%
bb4000ce-8f87-4c8a-aefe-0bc26143c2d3 rack1
{noformat}
Upgraded node {{10.109.30.228}} first. New IP {{10.109.220.200}}.
*New node, stopped communicating with other nodes.*
*From node 10.109.44.76 :*
{noformat}
Datacenter: c3ssl_dev_tap_ttc
=
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- AddressLoad Tokens Owns (effective) Host ID
Rack
UN 10.109.44.76 128.32 KiB 16 63.1%
325e24b3-81b9-4d19-abaf-1bb61f662be5 rack1
DN 10.109.30.228 128.32 KiB 16 71.1%
4d1ff6ec-d781-474d-9862-4b31f1f583fe rack1
UN 10.109.44.177 128.22 KiB 16 65.8%
bb4000ce-8f87-4c8a-aefe-0bc26143c2d3 rack1
{noformat}
*From node 10.109.220.200 :*
{noformat}
dbaasstg-ca-c3ssl-dc-834204-v002-1s7rs:/usr/lib/cassandra/logs# nodetool status
Datacenter: DC1
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address LoadTokens Owns (effective) Host ID
Rack
DN 10.109.44.177 ? 16 65.8%
bb4000ce-8f87-4c8a-aefe-0bc26143c2d3 r1
DN 10.109.44.76? 16 63.1%
325e24b3-81b9-4d19-abaf-1bb61f662be5 r1
Datacenter: c3ssl_dev_tap_ttc
=
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address LoadTokens Owns (effective) Host ID
Rack
UN 10.109.220.200 212.45 KiB 16 71.1%
4d1ff6ec-d781-474d-9862-4b31f1f583fe rack1
{noformat}
> Upgraded (C* 4.0.4) node stops communicating with older version (3.11.4)
> nodes during upgrade
> -
>
> Key: CASSANDRA-18075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18075
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption
>Reporter: Alaykumar Barochia
>Priority: Normal
> Attachments: In-place-upgrade.zip, cassandra-env.sh_3114,
> cassandra-env.sh_404, cassandra.yaml_10.110.44.207_explicitely_set_port,
> cassandra.yaml_10.110.49.242_explicitely_set_port, cassandra.yaml_3114,
> cassandra.yaml_404, system.log_10.110.44.207,
> system.log_10.110.44.207_after_explicitely_set_port,
> system.log_10.110.49.242_after_explicitely_set_port
>
>
> We are testing upgrade from Cassandra 3.11.4 to 4.0.4 on our test cluster
> which is SSL enabled and facing an issue.
> Our cluster size is 3x3.
> {noformat}
> Datacenter: abssl_dev_tap_ttc
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.109.6.153 94.27 KiB 16 100.0%
> 130e59d2-2a9a-4039-a42f-deb20afcf288 rack1
> UN 10.109.45.8104.43 KiB 16 100.0%
> 35274a2c-f915-4308-9981-d207a4e2108f rack1
> UN 10.109.66.149 104.23 KiB 16 100.0%
> ea0151bc-fb6c-425d-af42-75c10e52f941 rack1
> Datacenter: abssl_dev_tap_tte
> =
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns (effective) Host ID
> Rack
> UN 10.110.4.110 104.44 KiB 16 100.0%
> fd4a9fa8-f2a9-494c-afb8-7cb8a08c7554 rack1
> UN 10.110.44.220 99.33 KiB 16 100.0%
> f1dc35c0-a1c2-45fe-9f65-b1cc3d7f6947 rack1
> UN 10.110.49.242 65.57 KiB 16 100.0%
> 72bc4ae5-876d-4d0a-91ac-6cf8b531b4dd rack1
> dbaasprod-ca-abssl-de-393671-v001-yqlvf:~# nodetool describecluster
> Cluster
[jira] [Commented] (CASSANDRA-18436) Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally failing with JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722049#comment-17722049
]
Berenguer Blasi commented on CASSANDRA-18436:
-
Failures indeed are on Ci resources, test passes and SHA's match. +1
> Unit tests in org.apache.cassandra.cql3.EmptyValuesTest class occasionally
> failing with JDK17
> -
>
> Key: CASSANDRA-18436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18436
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: dan jatnieks
>Priority: Normal
> Fix For: 5.x
>
>
>
> All of them failed with the below stack trace for the same assertion failing:
> {code:java}
> junit.framework.AssertionFailedError: at
> org.apache.cassandra.cql3.EmptyValuesTest.verify(EmptyValuesTest.java:90) at
> org.apache.cassandra.cql3.EmptyValuesTest.verifyJsonInsert(EmptyValuesTest.java:112)
> at
> org.apache.cassandra.cql3.EmptyValuesTest.testEmptyDecimal(EmptyValuesTest.java:192)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
> Unfortunately I do not have a link to the CI run as this was seen last in
> private infra and not in CircleCI. Maybe we want to check with the
> multiplexer for flakiness.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722047#comment-17722047
]
Brad Schoening commented on CASSANDRA-18305:
[~manish.c.ghildi...@gmail.com] yes, correct, current compaction rate /
compaction_throughput_mb_per_sec. It's also possible that
compaction_throughput_mb_per_sec = 0 in which case its unlimited.
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18305) Enhance nodetool compactionstats with existing MBean metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722002#comment-17722002
]
Manish Ghildiyal edited comment on CASSANDRA-18305 at 5/12/23 6:41 AM:
---
*compaction throughput 13.2 MBps / 16 MBps (82.5%)*
I guess 16 MBps here is the value configured in cassandra.yaml.
was (Author: manish.c.ghildi...@gmail.com):
*compaction throughput 13.2 MBps / 16 MBps (82.5%)*
I guess 16 MBps here is the value mentioned in cassandra.yaml.
> Enhance nodetool compactionstats with existing MBean metrics
>
>
> Key: CASSANDRA-18305
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18305
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Manish Ghildiyal
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0
>
>
> Nodetool compactionstats reports only on active compactions, if nothing is
> active, you see only:
> {quote}$nodetool compactionstats
> pending tasks: 0
> {quote}
> but in the MBean Compaction/TotalCompactionsCompleted there are recent
> statistic in events/second for:
> * Count
> * FifteenMinueRate
> * FiveMinueRate
> * MeanRate
> * OneMinuteRate
> 1) It would be useful to see in addition:
> {quote}pending tasks: 0
> compactions completed: 20
> 1 minute rate: 0/second
> 5 minute rate: 2.3/second
> 15 minute rate: 4.6/second
> {quote}
> 2) Since compaction_throughput_mb_per_sec is a throttling parameter in
> cassandra.yaml (default 64 MBps), it would be nice to show the actual
> compaction throughput and be able to observe if you're close to the limit.
> I.e.,
> {quote}compaction throughput 13.2 MBps / 16 MBps (82.5%)
> {quote}
> 3) for completness, compactionstats should list the number of concurrent
> compactors configured, perhaps simply add to existing 'pending tasks' line:
> {quote}4 concurrent compactors, 0 pending tasks
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
