[jira] [Commented] (CASSANDRA-18049) Update Chronicle Queue
[
https://issues.apache.org/jira/browse/CASSANDRA-18049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17703008#comment-17703008
]
Ekaterina Dimitrova commented on CASSANDRA-18049:
-
I forgot to address the below note:
{quote} - introduced (but not used yet), the default sync to disk mode for
chronicle-bytes is async, ref
[MappedBytesStore.java|https://github.com/OpenHFT/Chronicle-Bytes/blob/chronicle-bytes-2.23.33/src/main/java/net/openhft/chronicle/bytes/MappedBytesStore.java#L49]
-- if the user configures audit or fql logging to be blocking should we then
set {{SyncMode.SYNC}} ?
-- alternatively, if the user wants blocking AND paranoid disk sync, they can
manually set `{{{}-DmappedFile.defaultSyncMode=SYNC{}}}` (and we should
document this in cassandra.yaml){quote}
I will take a look tomorrow morning
> Update Chronicle Queue
> --
>
> Key: CASSANDRA-18049
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18049
> Project: Cassandra
> Issue Type: Task
>Reporter: Ekaterina Dimitrova
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> According to [this|https://chronicle.software/chronicle-support-java-17]
> article:
> {code:java}
> Starting from chronicle-bom-2.22ea26, all new releases can be run under Java
> 17 when run on the class path (but not yet under the module path).{code}
> This BOM is newer than what we currently have in both 4.1 and trunk. 4.1
> points in comments to
> [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/1.16.23] which
> I believe was just forgotten to be updated/removed. The versions we see
> correspond to this BOM
> [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/2.20.226]
> It is still older than chronicle-bom-2.22ea26 so we need to upgrade. I
> suggest we also add a comment again which BOM is considered, this makes
> things easier.
> Further to running CI, review of the CHANGE logs needs to happen to ensure we
> do not miss anything that can impact us and it is not caught by our tests.
> For testing with JDK17, please, contact [~e.dimitrova] for latest branch and
> CI config (at this point feature branch in the cassandra repo does not exist)
>
--
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-18351) Add package-info files for each package
[ https://issues.apache.org/jira/browse/CASSANDRA-18351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ling Mao reassigned CASSANDRA-18351: Assignee: Ling Mao > Add package-info files for each package > --- > > Key: CASSANDRA-18351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18351 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Javadoc >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Normal > > - To make the whole codebase more readable(especially for C* beginner), add > package-info files for each package to describe what each package did may be > a good choice. > - Look at an example from Netty: > https://github.com/netty/netty/blob/4.1/codec-redis/src/main/java/io/netty/handler/codec/redis/package-info.java > https://github.com/netty/netty/blob/4.1/handler-proxy/src/main/java/io/netty/handler/proxy/package-info.java > https://github.com/netty/netty/blob/4.1/buffer/src/main/java/io/netty/buffer/package-info.java -- 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-18351) Add package-info files for each package
Ling Mao created CASSANDRA-18351: Summary: Add package-info files for each package Key: CASSANDRA-18351 URL: https://issues.apache.org/jira/browse/CASSANDRA-18351 Project: Cassandra Issue Type: Improvement Components: Documentation/Javadoc Reporter: Ling Mao - To make the whole codebase more readable(especially for C* beginner), add package-info files for each package to describe what each package did may be a good choice. - Look at an example from Netty: https://github.com/netty/netty/blob/4.1/codec-redis/src/main/java/io/netty/handler/codec/redis/package-info.java https://github.com/netty/netty/blob/4.1/handler-proxy/src/main/java/io/netty/handler/proxy/package-info.java https://github.com/netty/netty/blob/4.1/buffer/src/main/java/io/netty/buffer/package-info.java -- 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-18049) Update Chronicle Queue
[
https://issues.apache.org/jira/browse/CASSANDRA-18049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702990#comment-17702990
]
Ekaterina Dimitrova commented on CASSANDRA-18049:
-
The patch seems ready for another CI run.
Also CASSANDRA-18247 is already committed so we can verify easily all JDK
versions
> Update Chronicle Queue
> --
>
> Key: CASSANDRA-18049
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18049
> Project: Cassandra
> Issue Type: Task
>Reporter: Ekaterina Dimitrova
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 5.x
>
>
> According to [this|https://chronicle.software/chronicle-support-java-17]
> article:
> {code:java}
> Starting from chronicle-bom-2.22ea26, all new releases can be run under Java
> 17 when run on the class path (but not yet under the module path).{code}
> This BOM is newer than what we currently have in both 4.1 and trunk. 4.1
> points in comments to
> [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/1.16.23] which
> I believe was just forgotten to be updated/removed. The versions we see
> correspond to this BOM
> [https://mvnrepository.com/artifact/net.openhft/chronicle-bom/2.20.226]
> It is still older than chronicle-bom-2.22ea26 so we need to upgrade. I
> suggest we also add a comment again which BOM is considered, this makes
> things easier.
> Further to running CI, review of the CHANGE logs needs to happen to ensure we
> do not miss anything that can impact us and it is not caught by our tests.
> For testing with JDK17, please, contact [~e.dimitrova] for latest branch and
> CI config (at this point feature branch in the cassandra repo does not exist)
>
--
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-website] branch asf-staging updated (e9f2508eb -> dfe6a91e8)
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 e9f2508eb generate docs for c4206294 new dfe6a91e8 generate docs for c4206294 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 (e9f2508eb) \ N -- N -- N refs/heads/asf-staging (dfe6a91e8) 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 4796442 -> 4796442 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] [Commented] (CASSANDRA-18319) Cassandra in Kubernetes: IP switch decommission issue
[
https://issues.apache.org/jira/browse/CASSANDRA-18319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702960#comment-17702960
]
Raymond Huffman commented on CASSANDRA-18319:
-
Thanks for the response. I tested this a bit more and I don’t think it’s just
log noise. While the cluster is in this state, reads and writes with
consistency ALL will fail. Do you think Ines' suggestion above that purges fat
clients matching a decommissioning node could be reasonable way to avoid
getting into this state?
> Cassandra in Kubernetes: IP switch decommission issue
> -
>
> Key: CASSANDRA-18319
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18319
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ines Potier
>Priority: Normal
> Attachments: 3.11_gossipinfo.zip, node1_gossipinfo.txt,
> test_decommission_after_ip_change_logs.zip,
> v4.0_1678853171792_test_decommission_after_ip_change.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have recently encountered a recurring old IP reappearance issue while
> testing decommissions on some of our Kubernetes Cassandra staging clusters.
> *Issue Description*
> In Kubernetes, a Cassandra node can change IP at each pod bounce. We have
> noticed that this behavior, associated with a decommission operation, can get
> the cluster into an erroneous state.
> Consider the following situation: a Cassandra node {{node1}} , with
> {{{}hostId1{}}}, owning 20.5% of the token ring, bounces and switches IP
> ({{{}old_IP{}}} → {{{}new_IP{}}}). After a couple gossip iterations, all
> other nodes’ nodetool status output includes a {{new_IP}} UN entry owning
> 20.5% of the token ring and no {{old_IP}} entry.
> Shortly after the bounce, {{node1}} gets decommissioned. Our cluster does not
> have a lot of data, and the decommission operation completes pretty quickly.
> Logs on other nodes start showing acknowledgment that {{node1}} has left and
> soon, nodetool status’ {{new_IP}} UL entry disappears. {{node1}} ‘s pod is
> deleted.
> After a minute delay, the cluster enters the erroneous state. An {{old_IP}}
> DN entry reappears in nodetool status, owning 20.5% of the token ring. No
> node owns this IP anymore and according to logs, {{old_IP}} is still
> associated with {{{}hostId1{}}}.
> *Issue Root Cause*
> By digging through Cassandra logs, and re-testing this scenario over and over
> again, we have reached the following conclusion:
> * Other nodes will continue exchanging gossip about {{old_IP}} , even after
> it becomes a fatClient.
> * The fatClient timeout and subsequent quarantine does not stop {{old_IP}}
> from reappearing in a node’s Gossip state, once its quarantine is over. We
> believe that this is due to a misalignment on all nodes’ {{old_IP}}
> expiration time.
> * Once {{new_IP}} has left the cluster, and {{old_IP}} next gossip state
> message is received by a node, StorageService will no longer face collisions
> (or will, but with an even older IP) for {{hostId1}} and its corresponding
> tokens. As a result, {{old_IP}} will regain ownership of 20.5% of the token
> ring.
> *Proposed fix*
> Following the above investigation, we were thinking about implementing the
> following fix:
> When a node receives a gossip status change with {{STATE_LEFT}} for a leaving
> endpoint {{{}new_IP{}}}, before evicting {{{}new_IP from the token ring,
> purge from Gossip (ie evictFromMembership{}}}) all endpoints that meet the
> following criteria:
> * {{endpointStateMap}} contains this endpoint
> * The endpoint is not currently a token owner
> ({{{}!tokenMetadata.isMember(endpoint){}}})
> * The endpoint’s {{hostId}} matches the {{hostId}} of {{new_IP}}
> * The endpoint is older than {{leaving_IP}}
> ({{{}Gossiper.instance.compareEndpointStartup{}}})
> * The endpoint’s token range (from {{{}endpointStateMap{}}}) intersects with
> {{{}new_IP{}}}’s
> This modification’s intention is to force nodes to realign on {{old_IP}}
> expiration, and expunge it from Gossip so it does not reappear after
> {{new_IP}} leaves the ring.
> Another approach we have also been considering is expunging {{old_IP}} at the
> moment of the StorageService collision resolution.
--
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-18241) Invalid result when a non existent row is assigned to a variable
[
https://issues.apache.org/jira/browse/CASSANDRA-18241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702953#comment-17702953
]
Ariel Weisberg commented on CASSANDRA-18241:
Just a heads up this breaks CAS failure to apply for EXISTS. It shows up in
unit tests that I haven't landed yet. The code that processes a CAS result and
turns it into a result set interprets an empty result as success and all
non-empty results as failure. It's very finicky and I think the right solution
is probably to have the necessary result added in TxnQuery.CONDITION
specifically for this failure case where there is also no result row.
> Invalid result when a non existent row is assigned to a variable
>
>
> Key: CASSANDRA-18241
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18241
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: NA
>
>
> {noformat}
> cqlsh:ks> CREATE TABLE tbl3 (k INT, c INT, v INT, PRIMARY KEY (k, c));
> cqlsh:ks>
> BEGIN TRANSACTION
> LET row = (SELECT * FROM tbl3 WHERE k=1 LIMIT 1);
> SELECT row.k, row.c, row.v;
> IF row.c > 10 THEN
> INSERT INTO ks.tbl3 (k, c, v) VALUES (1, 10, 110);
> END IF
> COMMIT TRANSACTION;
> row.k | row.c | row.v
> ---+---+---
> 1 | null | null
> cqlsh:ks> SELECT * FROM tbl3;
> k | c | v
> ---+---+---
> (0 rows)
> {noformat}
> as discussed on Slack, the transaction should return:
> {noformat}
> row.k | row.c | row.v
> ---+---+---
> null | null | null
> {noformat}
--
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-18203) CEP-15: (C*) Improve Burn Tests to include thread scheduling
[ https://issues.apache.org/jira/browse/CASSANDRA-18203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18203: -- Fix Version/s: NA (was: 5.x) Source Control Link: https://github.com/apache/cassandra-accord/commit/eefc013a0a809c8f8e0952e215958c1e8f1b759a Resolution: Fixed Status: Resolved (was: Ready to Commit) > CEP-15: (C*) Improve Burn Tests to include thread scheduling > > > Key: CASSANDRA-18203 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18203 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > To improve burn test coverage, should have CommandStore actions run in a > interleaved manner with jitter -- 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-18203) CEP-15: (C*) Improve Burn Tests to include thread scheduling
[ https://issues.apache.org/jira/browse/CASSANDRA-18203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18203: -- Status: Ready to Commit (was: Review In Progress) > CEP-15: (C*) Improve Burn Tests to include thread scheduling > > > Key: CASSANDRA-18203 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18203 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > > To improve burn test coverage, should have CommandStore actions run in a > interleaved manner with jitter -- 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: CEP-15: (C*) Improve Burn Tests to include thread scheduling
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-accord.git
The following commit(s) were added to refs/heads/trunk by this push:
new eefc013a CEP-15: (C*) Improve Burn Tests to include thread scheduling
eefc013a is described below
commit eefc013a0a809c8f8e0952e215958c1e8f1b759a
Author: David Capwell
AuthorDate: Mon Mar 20 14:30:10 2023 -0700
CEP-15: (C*) Improve Burn Tests to include thread scheduling
patch by David Capwell; reviewed by Benedict Elliott Smith for
CASSANDRA-18203
---
accord-core/build.gradle | 2 +
.../java/accord/impl/InMemoryCommandStore.java | 16 ++-
.../src/main/java/accord/messages/ReadData.java| 2 +-
.../accord/utils/async/AsyncChainCombiner.java | 22
.../main/java/accord/utils/async/AsyncChains.java | 11 ++
.../src/test/java/accord/burn/BurnTest.java| 14 +--
.../src/test/java/accord/burn/TopologyUpdates.java | 87 ++-
.../src/test/java/accord/impl/basic/Cluster.java | 2 +-
.../accord/impl/basic/DelayedCommandStores.java| 43 +++
.../basic/SimulatedDelayedExecutorService.java | 123 +
.../src/main/groovy/accord.java-conventions.gradle | 1 +
11 files changed, 258 insertions(+), 65 deletions(-)
diff --git a/accord-core/build.gradle b/accord-core/build.gradle
index 3c1472bc..bb315b9b 100644
--- a/accord-core/build.gradle
+++ b/accord-core/build.gradle
@@ -34,6 +34,8 @@ dependencies {
// These act as runtimeOnly dependencies to users
implementation 'org.slf4j:slf4j-api:1.7.36'
implementation 'org.agrona:agrona:1.17.1'
+
+testImplementation group: 'org.assertj', name: 'assertj-core', version:
'3.24.2'
}
task burn(type: JavaExec) {
diff --git a/accord-core/src/main/java/accord/impl/InMemoryCommandStore.java
b/accord-core/src/main/java/accord/impl/InMemoryCommandStore.java
index e881b911..e81186cc 100644
--- a/accord-core/src/main/java/accord/impl/InMemoryCommandStore.java
+++ b/accord-core/src/main/java/accord/impl/InMemoryCommandStore.java
@@ -819,12 +819,22 @@ public abstract class InMemoryCommandStore implements
CommandStore
public SingleThread(int id, NodeTimeService time, Agent agent,
DataStore store, ProgressLog.Factory progressLogFactory, RangesForEpochHolder
rangesForEpochHolder)
{
-super(id, time, agent, store, progressLogFactory,
rangesForEpochHolder);
-this.executor = Executors.newSingleThreadExecutor(r -> {
+this(id, time, agent, store, progressLogFactory,
rangesForEpochHolder, Executors.newSingleThreadExecutor(r -> {
Thread thread = new Thread(r);
thread.setName(CommandStore.class.getSimpleName() + '[' +
time.id() + ']');
return thread;
-});
+}));
+}
+
+private SingleThread(int id, NodeTimeService time, Agent agent,
DataStore store, ProgressLog.Factory progressLogFactory, RangesForEpochHolder
rangesForEpochHolder, ExecutorService executor)
+{
+super(id, time, agent, store, progressLogFactory,
rangesForEpochHolder);
+this.executor = executor;
+}
+
+public static CommandStore.Factory factory(ExecutorService executor)
+{
+return (id, time, agent, store, progressLogFactory,
rangesForEpoch) -> new SingleThread(id, time, agent, store, progressLogFactory,
rangesForEpoch, executor);
}
void assertThread()
diff --git a/accord-core/src/main/java/accord/messages/ReadData.java
b/accord-core/src/main/java/accord/messages/ReadData.java
index 8d4e2752..a4ebb4f3 100644
--- a/accord-core/src/main/java/accord/messages/ReadData.java
+++ b/accord-core/src/main/java/accord/messages/ReadData.java
@@ -224,7 +224,7 @@ public class ReadData extends
AbstractEpochRequest implements
private synchronized void readComplete(CommandStore commandStore, Data
result)
{
-Invariants.checkState(waitingOn.get(commandStore.id()));
+Invariants.checkState(waitingOn.get(commandStore.id()), "Waiting on
does not contain store %d; waitingOn=%s", commandStore.id(), waitingOn);
logger.trace("{}: read completed on {}", txnId, commandStore);
if (result != null)
data = data == null ? result : data.merge(result);
diff --git
a/accord-core/src/main/java/accord/utils/async/AsyncChainCombiner.java
b/accord-core/src/main/java/accord/utils/async/AsyncChainCombiner.java
index f4a9e636..3d87c45c 100644
--- a/accord-core/src/main/java/accord/utils/async/AsyncChainCombiner.java
+++ b/accord-core/src/main/java/accord/utils/async/AsyncChainCombiner.java
@@ -165,4 +165,26 @@ abstract class AsyncChainCombiner extends
AsyncChains.Head
return reduce.reducer == reducer;
}
}
+
+static class ReduceWithIdentity extends AsyncCha
[jira] [Updated] (CASSANDRA-18203) CEP-15: (C*) Improve Burn Tests to include thread scheduling
[ https://issues.apache.org/jira/browse/CASSANDRA-18203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18203: -- Reviewers: Benedict Elliott Smith Status: Review In Progress (was: Patch Available) > CEP-15: (C*) Improve Burn Tests to include thread scheduling > > > Key: CASSANDRA-18203 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18203 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > > To improve burn test coverage, should have CommandStore actions run in a > interleaved manner with jitter -- 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-18203) CEP-15: (C*) Improve Burn Tests to include thread scheduling
[ https://issues.apache.org/jira/browse/CASSANDRA-18203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702936#comment-17702936 ] David Capwell commented on CASSANDRA-18203: --- [~benedict] +1ed in GH but asked that I revert the changes to SimpleProgressLog as they are not core to this patch and should be rethought > CEP-15: (C*) Improve Burn Tests to include thread scheduling > > > Key: CASSANDRA-18203 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18203 > Project: Cassandra > Issue Type: Improvement > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 5.x > > > To improve burn test coverage, should have CommandStore actions run in a > interleaved manner with jitter -- 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-17199) Provide summary of failed SessionInfo's in StreamResultFuture
[
https://issues.apache.org/jira/browse/CASSANDRA-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702927#comment-17702927
]
David Capwell commented on CASSANDRA-17199:
---
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-17199-trunk-89795FE7-3D38-4669-9B0E-7FB73D1CC852]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-17199-trunk-89795FE7-3D38-4669-9B0E-7FB73D1CC852]|[build|unknown]|
> Provide summary of failed SessionInfo's in StreamResultFuture
> -
>
> Key: CASSANDRA-17199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17199
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Brendan Cicchi
>Assignee: Natnael Adere
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
>
> Currently, we warn about the presence of one or more failed sessions existing
> in the final state and then an operator/user traces back through the logs to
> find any failed streams for troubleshooting.
> {code:java}
> private synchronized void maybeComplete()
> {
> if (finishedAllSessions())
> {
> StreamState finalState = getCurrentState();
> if (finalState.hasFailedSession())
> {
> logger.warn("[Stream #{}] Stream failed", planId);
> tryFailure(new StreamException(finalState, "Stream failed"));
> }
> else
> {
> logger.info("[Stream #{}] All sessions completed", planId);
> trySuccess(finalState);
> }
> }
> } {code}
> It would be helpful to log out a summary of the SessionInfo for each failed
> session since that should be accessible via the StreamState.
>
> This can be especially helpful for longer streaming operations like bootstrap
> where the failure could have been a long time back and all recent streams
> leading up to the warning actually are successful.
>
--
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-17199) Provide summary of failed SessionInfo's in StreamResultFuture
[
https://issues.apache.org/jira/browse/CASSANDRA-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702924#comment-17702924
]
David Capwell commented on CASSANDRA-17199:
---
new tests are flaky, aborting
> Provide summary of failed SessionInfo's in StreamResultFuture
> -
>
> Key: CASSANDRA-17199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17199
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Brendan Cicchi
>Assignee: Natnael Adere
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
>
> Currently, we warn about the presence of one or more failed sessions existing
> in the final state and then an operator/user traces back through the logs to
> find any failed streams for troubleshooting.
> {code:java}
> private synchronized void maybeComplete()
> {
> if (finishedAllSessions())
> {
> StreamState finalState = getCurrentState();
> if (finalState.hasFailedSession())
> {
> logger.warn("[Stream #{}] Stream failed", planId);
> tryFailure(new StreamException(finalState, "Stream failed"));
> }
> else
> {
> logger.info("[Stream #{}] All sessions completed", planId);
> trySuccess(finalState);
> }
> }
> } {code}
> It would be helpful to log out a summary of the SessionInfo for each failed
> session since that should be accessible via the StreamState.
>
> This can be especially helpful for longer streaming operations like bootstrap
> where the failure could have been a long time back and all recent streams
> leading up to the warning actually are successful.
>
--
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-18350) CEP-21: Multiple tests in DescribeStatementTest fail on committing SchemaChangeRequest
[
https://issues.apache.org/jira/browse/CASSANDRA-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18350:
Summary: CEP-21: Multiple tests in DescribeStatementTest fail on committing
SchemaChangeRequest (was: MTC - Jira - CEP-21: Multiple tests in
DescribeStatementTest fail on committing SchemaChangeRequest)
> CEP-21: Multiple tests in DescribeStatementTest fail on committing
> SchemaChangeRequest
> --
>
> Key: CASSANDRA-18350
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18350
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership, Cluster/Schema
>Reporter: Caleb Rackliffe
>Priority: Normal
> Fix For: NA
>
>
> See
> https://app.circleci.com/pipelines/github/beobal/cassandra/406/workflows/00cdb02e-4b3e-477a-b997-403121172249/jobs/4202/tests
> This reproduces locally.
> {noformat}
> ERROR [main] 2023-03-17 12:44:33,810 AbstractLocalProcessor.java:52 - Caught
> error while trying to perform a local commit
> java.lang.IllegalStateException: Escaping infinite loop after 10 tries.
> Current epoch: Epoch{epoch=25}. Next epoch: Epoch{epoch=26}.
> at
> org.apache.cassandra.tcm.AbstractLocalProcessor.commitLocally(AbstractLocalProcessor.java:114)
> at
> org.apache.cassandra.tcm.AbstractLocalProcessor.commit(AbstractLocalProcessor.java:48)
> at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:342)
> at org.apache.cassandra.schema.Schema.submit(Schema.java:289)
> at
> org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.execute(AlterSchemaStatement.java:132)
> at
> org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.executeLocally(AlterSchemaStatement.java:88)
> at
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:474)
> at
> org.apache.cassandra.cql3.CQLTester.executeFormattedQuery(CQLTester.java:1296)
> at org.apache.cassandra.cql3.CQLTester.execute(CQLTester.java:1275)
> {noformat}
> {noformat}
> java.lang.RuntimeException: Error setting schema for test (query was: CREATE
> KEYSPACE IF NOT EXISTS cql_test_keyspace WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': '1'})
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1173)
> at org.apache.cassandra.cql3.CQLTester.beforeTest(CQLTester.java:357)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> Caused by: java.lang.IllegalStateException: Couldn't commit the
> transformation SchemaChangeRequest{,
> schemaTransformation=CreateKeyspaceStatement (cql_test_keyspace)} after 10
> tries
> at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:385)
> at org.apache.cassandra.schema.Schema.submit(Schema.java:289)
> at
> org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.execute(AlterSchemaStatement.java:132)
> at
> org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.executeLocally(AlterSchemaStatement.java:88)
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1168)
> {noformat}
--
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-18350) MTC - Jira - CEP-21: Multiple tests in DescribeStatementTest fail on committing SchemaChangeRequest
[
https://issues.apache.org/jira/browse/CASSANDRA-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18350:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Cluster/Membership
Cluster/Schema
Discovered By: Unit Test
Fix Version/s: NA
Severity: Normal
Status: Open (was: Triage Needed)
> MTC - Jira - CEP-21: Multiple tests in DescribeStatementTest fail on
> committing SchemaChangeRequest
> ---
>
> Key: CASSANDRA-18350
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18350
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership, Cluster/Schema
>Reporter: Caleb Rackliffe
>Priority: Normal
> Fix For: NA
>
>
> See
> https://app.circleci.com/pipelines/github/beobal/cassandra/406/workflows/00cdb02e-4b3e-477a-b997-403121172249/jobs/4202/tests
> This reproduces locally.
> {noformat}
> ERROR [main] 2023-03-17 12:44:33,810 AbstractLocalProcessor.java:52 - Caught
> error while trying to perform a local commit
> java.lang.IllegalStateException: Escaping infinite loop after 10 tries.
> Current epoch: Epoch{epoch=25}. Next epoch: Epoch{epoch=26}.
> at
> org.apache.cassandra.tcm.AbstractLocalProcessor.commitLocally(AbstractLocalProcessor.java:114)
> at
> org.apache.cassandra.tcm.AbstractLocalProcessor.commit(AbstractLocalProcessor.java:48)
> at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:342)
> at org.apache.cassandra.schema.Schema.submit(Schema.java:289)
> at
> org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.execute(AlterSchemaStatement.java:132)
> at
> org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.executeLocally(AlterSchemaStatement.java:88)
> at
> org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:474)
> at
> org.apache.cassandra.cql3.CQLTester.executeFormattedQuery(CQLTester.java:1296)
> at org.apache.cassandra.cql3.CQLTester.execute(CQLTester.java:1275)
> {noformat}
> {noformat}
> java.lang.RuntimeException: Error setting schema for test (query was: CREATE
> KEYSPACE IF NOT EXISTS cql_test_keyspace WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': '1'})
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1173)
> at org.apache.cassandra.cql3.CQLTester.beforeTest(CQLTester.java:357)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> Caused by: java.lang.IllegalStateException: Couldn't commit the
> transformation SchemaChangeRequest{,
> schemaTransformation=CreateKeyspaceStatement (cql_test_keyspace)} after 10
> tries
> at
> org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:385)
> at org.apache.cassandra.schema.Schema.submit(Schema.java:289)
> at
> org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.execute(AlterSchemaStatement.java:132)
> at
> org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.executeLocally(AlterSchemaStatement.java:88)
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1168)
> {noformat}
--
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-18350) MTC - Jira - CEP-21: Multiple tests in DescribeStatementTest fail on committing SchemaChangeRequest
Caleb Rackliffe created CASSANDRA-18350:
---
Summary: MTC - Jira - CEP-21: Multiple tests in
DescribeStatementTest fail on committing SchemaChangeRequest
Key: CASSANDRA-18350
URL: https://issues.apache.org/jira/browse/CASSANDRA-18350
Project: Cassandra
Issue Type: Bug
Reporter: Caleb Rackliffe
See
https://app.circleci.com/pipelines/github/beobal/cassandra/406/workflows/00cdb02e-4b3e-477a-b997-403121172249/jobs/4202/tests
This reproduces locally.
{noformat}
ERROR [main] 2023-03-17 12:44:33,810 AbstractLocalProcessor.java:52 - Caught
error while trying to perform a local commit
java.lang.IllegalStateException: Escaping infinite loop after 10 tries. Current
epoch: Epoch{epoch=25}. Next epoch: Epoch{epoch=26}.
at
org.apache.cassandra.tcm.AbstractLocalProcessor.commitLocally(AbstractLocalProcessor.java:114)
at
org.apache.cassandra.tcm.AbstractLocalProcessor.commit(AbstractLocalProcessor.java:48)
at
org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:342)
at org.apache.cassandra.schema.Schema.submit(Schema.java:289)
at
org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.execute(AlterSchemaStatement.java:132)
at
org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.executeLocally(AlterSchemaStatement.java:88)
at
org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:474)
at
org.apache.cassandra.cql3.CQLTester.executeFormattedQuery(CQLTester.java:1296)
at org.apache.cassandra.cql3.CQLTester.execute(CQLTester.java:1275)
{noformat}
{noformat}
java.lang.RuntimeException: Error setting schema for test (query was: CREATE
KEYSPACE IF NOT EXISTS cql_test_keyspace WITH replication = {'class':
'SimpleStrategy', 'replication_factor': '1'})
at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1173)
at org.apache.cassandra.cql3.CQLTester.beforeTest(CQLTester.java:357)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Caused by: java.lang.IllegalStateException: Couldn't commit the transformation
SchemaChangeRequest{, schemaTransformation=CreateKeyspaceStatement
(cql_test_keyspace)} after 10 tries
at
org.apache.cassandra.tcm.ClusterMetadataService.commit(ClusterMetadataService.java:385)
at org.apache.cassandra.schema.Schema.submit(Schema.java:289)
at
org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.execute(AlterSchemaStatement.java:132)
at
org.apache.cassandra.cql3.statements.schema.AlterSchemaStatement.executeLocally(AlterSchemaStatement.java:88)
at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1168)
{noformat}
--
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-18349) CEP-21: o.a.c.d.t.MoveTest appears to call StorageService#getLocalTokens() before any saved tokens exist
[
https://issues.apache.org/jira/browse/CASSANDRA-18349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18349:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Cluster/Membership
Cluster/Schema
Discovered By: DTest
Fix Version/s: NA
Severity: Normal
Status: Open (was: Triage Needed)
> CEP-21: o.a.c.d.t.MoveTest appears to call StorageService#getLocalTokens()
> before any saved tokens exist
>
>
> Key: CASSANDRA-18349
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18349
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership, Cluster/Schema
>Reporter: Caleb Rackliffe
>Priority: Normal
> Fix For: NA
>
>
> See:
> https://app.circleci.com/pipelines/github/beobal/cassandra/406/workflows/00cdb02e-4b3e-477a-b997-403121172249/jobs/4201/tests
> {noformat}
> java.lang.AssertionError
> at
> org.apache.cassandra.service.StorageService.getLocalTokens(StorageService.java:2256)
> at
> org.apache.cassandra.distributed.test.MoveTest.lambda$move$e42fa1e3$1(MoveTest.java:67)
> ...
> {noformat}
--
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-18349) CEP-21: o.a.c.d.t.MoveTest appears to call StorageService#getLocalTokens() before any saved tokens exist
Caleb Rackliffe created CASSANDRA-18349:
---
Summary: CEP-21: o.a.c.d.t.MoveTest appears to call
StorageService#getLocalTokens() before any saved tokens exist
Key: CASSANDRA-18349
URL: https://issues.apache.org/jira/browse/CASSANDRA-18349
Project: Cassandra
Issue Type: Bug
Reporter: Caleb Rackliffe
See:
https://app.circleci.com/pipelines/github/beobal/cassandra/406/workflows/00cdb02e-4b3e-477a-b997-403121172249/jobs/4201/tests
{noformat}
java.lang.AssertionError
at
org.apache.cassandra.service.StorageService.getLocalTokens(StorageService.java:2256)
at
org.apache.cassandra.distributed.test.MoveTest.lambda$move$e42fa1e3$1(MoveTest.java:67)
...
{noformat}
--
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-18348) CEP-21: AlterTest#unknownMemtableConfigurationTest fails on possibly no longer valid assumptions around schema propagation
[
https://issues.apache.org/jira/browse/CASSANDRA-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18348:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Cluster/Membership
Cluster/Schema
Discovered By: Unit Test
Fix Version/s: NA
Severity: Normal
Status: Open (was: Triage Needed)
> CEP-21: AlterTest#unknownMemtableConfigurationTest fails on possibly no
> longer valid assumptions around schema propagation
> --
>
> Key: CASSANDRA-18348
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18348
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership, Cluster/Schema
>Reporter: Caleb Rackliffe
>Priority: Normal
> Fix For: NA
>
>
> See:
> [https://app.circleci.com/pipelines/github/beobal/cassandra/406/workflows/00cdb02e-4b3e-477a-b997-403121172249/jobs/4201/tests]
> The test hangs on L156, which the test assumes should succeed w/ node 1
> having correct local configuration:
> {noformat}
> cluster.schemaChange("ALTER TABLE " + KEYSPACE + ".tbl WITH memtable =
> 'testconfig'", false, node1);
> {noformat}
> In the logs...
> {noformat}
> ERROR [node2_isolatedExecutor:1] node2 2023-03-17 12:26:07,943
> JVMStabilityInspector.java:68 - Exception in thread
> Thread[node2_isolatedExecutor:1,5,isolatedExecutor]
> org.apache.cassandra.exceptions.ConfigurationException: Memtable
> configuration "testconfig" not found.
> at
> org.apache.cassandra.schema.MemtableParams.parseConfiguration(MemtableParams.java:155)
> at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1133)
> at
> org.apache.cassandra.schema.MemtableParams.get(MemtableParams.java:111)
> at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:129)
> at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.asNewTableParams(TableAttributes.java:65)
> at
> org.apache.cassandra.cql3.statements.schema.AlterTableStatement$AlterOptions.validate(AlterTableStatement.java:444)
> at
> org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:114)
> {noformat}
> {noformat}
> ERROR 17:26:12 Could not process the entry
> java.lang.AssertionError: null
> at
> org.apache.cassandra.tcm.log.LocalLog.processPendingInternal(LocalLog.java:272)
> at
> org.apache.cassandra.tcm.log.LocalLog$Async$AsyncRunnable.run(LocalLog.java:473)
> at
> org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
> {noformat}
> {noformat}
> java.lang.IllegalStateException: Schema agreement not reached. Schema
> versions of the instances: [----0009,
> ----0006]
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$ChangeMonitor.waitForCompletion(AbstractCluster.java:895)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster.lambda$schemaChange$8(AbstractCluster.java:824)
> at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
> {noformat}
--
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-18348) CEP-21: AlterTest#unknownMemtableConfigurationTest fails on possibly no longer valid assumptions around schema propagation
Caleb Rackliffe created CASSANDRA-18348:
---
Summary: CEP-21: AlterTest#unknownMemtableConfigurationTest fails
on possibly no longer valid assumptions around schema propagation
Key: CASSANDRA-18348
URL: https://issues.apache.org/jira/browse/CASSANDRA-18348
Project: Cassandra
Issue Type: Bug
Reporter: Caleb Rackliffe
See:
[https://app.circleci.com/pipelines/github/beobal/cassandra/406/workflows/00cdb02e-4b3e-477a-b997-403121172249/jobs/4201/tests]
The test hangs on L156, which the test assumes should succeed w/ node 1 having
correct local configuration:
{noformat}
cluster.schemaChange("ALTER TABLE " + KEYSPACE + ".tbl WITH memtable =
'testconfig'", false, node1);
{noformat}
In the logs...
{noformat}
ERROR [node2_isolatedExecutor:1] node2 2023-03-17 12:26:07,943
JVMStabilityInspector.java:68 - Exception in thread
Thread[node2_isolatedExecutor:1,5,isolatedExecutor]
org.apache.cassandra.exceptions.ConfigurationException: Memtable configuration
"testconfig" not found.
at
org.apache.cassandra.schema.MemtableParams.parseConfiguration(MemtableParams.java:155)
at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1133)
at
org.apache.cassandra.schema.MemtableParams.get(MemtableParams.java:111)
at
org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:129)
at
org.apache.cassandra.cql3.statements.schema.TableAttributes.asNewTableParams(TableAttributes.java:65)
at
org.apache.cassandra.cql3.statements.schema.AlterTableStatement$AlterOptions.validate(AlterTableStatement.java:444)
at
org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:114)
{noformat}
{noformat}
ERROR 17:26:12 Could not process the entry
java.lang.AssertionError: null
at
org.apache.cassandra.tcm.log.LocalLog.processPendingInternal(LocalLog.java:272)
at
org.apache.cassandra.tcm.log.LocalLog$Async$AsyncRunnable.run(LocalLog.java:473)
at
org.apache.cassandra.concurrent.InfiniteLoopExecutor.loop(InfiniteLoopExecutor.java:121)
{noformat}
{noformat}
java.lang.IllegalStateException: Schema agreement not reached. Schema versions
of the instances: [----0009,
----0006]
at
org.apache.cassandra.distributed.impl.AbstractCluster$ChangeMonitor.waitForCompletion(AbstractCluster.java:895)
at
org.apache.cassandra.distributed.impl.AbstractCluster.lambda$schemaChange$8(AbstractCluster.java:824)
at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
{noformat}
--
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-18318) Implement parsing schema provider for external SUT in Harry
[ https://issues.apache.org/jira/browse/CASSANDRA-18318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-18318: -- Fix Version/s: 5.0 (was: 4.2) > Implement parsing schema provider for external SUT in Harry > --- > > Key: CASSANDRA-18318 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18318 > Project: Cassandra > Issue Type: New Feature > Components: Test/fuzz >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Fix For: 5.0 > > -- 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-18315) Implement Concurrent Quiescent Checker
[ https://issues.apache.org/jira/browse/CASSANDRA-18315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-18315: -- Fix Version/s: 5.0 (was: 4.2) > Implement Concurrent Quiescent Checker > --- > > Key: CASSANDRA-18315 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18315 > Project: Cassandra > Issue Type: New Feature > Components: Test/fuzz >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: High > Fix For: 5.0 > > > It is possible to implement a concurrent quiescent checker, which allows for > a high degree of concurrency, while allowing to pinpoint partition state > precisely. > Additional minor improvements: > * formatting > * thread shutdown on failed run creation > * idempotent query execution > * retry delay -- 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-17603) Harry: improve column subset testing capabilities
[ https://issues.apache.org/jira/browse/CASSANDRA-17603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17603: -- Fix Version/s: 5.0 (was: 4.2) > Harry: improve column subset testing capabilities > - > > Key: CASSANDRA-17603 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17603 > Project: Cassandra > Issue Type: Improvement > Components: Test/fuzz >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Fix For: 5.0 > > > 1. Extend bitset to support > 64 bits > 2. Allow for wildcard queries > 3. Allow for validation of a subset of columns > 4. Open API for hand-crafting both mutation and read queries -- 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-18347) CEP-21: Startup failures in Python dtests around TCM_REPLAY_REQ
[
https://issues.apache.org/jira/browse/CASSANDRA-18347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18347:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Component/s: Cluster/Membership
Cluster/Schema
Discovered By: DTest
Fix Version/s: NA
Severity: Normal
Status: Open (was: Triage Needed)
> CEP-21: Startup failures in Python dtests around TCM_REPLAY_REQ
> ---
>
> Key: CASSANDRA-18347
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18347
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership, Cluster/Schema
>Reporter: Caleb Rackliffe
>Priority: Normal
> Fix For: NA
>
>
> There are currently widespread, locally reproducible failures in the Python
> dtests against the {{cep-21-tcm}} branch. For example...
>
> {noformat}pytest --cassandra-dir=/Users/maedhroz/Forks/cassandra
> topology_test.py::TestTopology::test_decommissioned_node_cant_rejoin{noformat}
> {noformat}pytest --cassandra-dir=/Users/maedhroz/Forks/cassandra
> materialized_views_test.py::TestMaterializedViews::test_query_new_column{noformat}
> {noformat}pytest --cassandra-dir=/Users/maedhroz/Forks/cassandra
> read_repair_test.py::TestSpeculativeReadRepair::test_normal_read_repair{noformat}
> https://app.circleci.com/pipelines/github/maedhroz/cassandra/701/workflows/44a5c7e0-0de0-4839-bbd0-80771fe23843/jobs/7251
> https://app.circleci.com/pipelines/github/beobal/cassandra/406/workflows/00cdb02e-4b3e-477a-b997-403121172249/jobs/4204/tests
> The death spiral in the node startup logs starts like this…
> {noformat}
> WARN [Messaging-EventLoop-3-1] 2023-03-17 11:55:34,037 NoSpamLogger.java:108
> - /127.0.0.2:7000->/127.0.0.1:7000-SMALL_MESSAGES-[no-channel] dropping
> message of type TCM_REPLAY_REQ whose timeout expired before reaching the
> network
> ERROR [InternalResponseStage:3] 2023-03-17 11:55:34,038
> RemoteProcessor.java:164 - Got error from /127.0.0.1:7000: TIMEOUT when
> sending TCM_REPLAY_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.2:7000, /127.0.0.1:7000],
> checkLive=false}
> INFO [Messaging-EventLoop-3-12] 2023-03-17 11:55:34,099
> InboundConnectionInitiator.java:567 -
> /127.0.0.2:7000(/127.0.0.2:49763)->/127.0.0.2:7000-SMALL_MESSAGES-1b9301b6
> messaging connection established, version = 13, framing = CRC, encryption =
> unencrypted
> INFO [Messaging-EventLoop-3-9] 2023-03-17 11:55:34,099
> OutboundConnection.java:1164 -
> /127.0.0.2:7000(/127.0.0.2:49763)->/127.0.0.2:7000-SMALL_MESSAGES-a9302b2e
> successfully connected, version = 13, framing = CRC, encryption = unencrypted
> WARN [InternalMetadataStage:5] 2023-03-17 11:55:34,100 NoSpamLogger.java:108
> - Not currently a member of the CMS
> INFO [Messaging-EventLoop-3-13] 2023-03-17 11:55:34,102
> InboundConnectionInitiator.java:567 -
> /127.0.0.2:7000(/127.0.0.2:49764)->/127.0.0.2:7000-URGENT_MESSAGES-f887f6fa
> messaging connection established, version = 13, framing = CRC, encryption =
> unencrypted
> INFO [Messaging-EventLoop-3-11] 2023-03-17 11:55:34,102
> OutboundConnection.java:1164 -
> /127.0.0.2:7000(/127.0.0.2:49764)->/127.0.0.2:7000-URGENT_MESSAGES-5cd0c637
> successfully connected, version = 13, framing = CRC, encryption = unencrypted
> ERROR [InternalResponseStage:4] 2023-03-17 11:55:49,237
> RemoteProcessor.java:164 - Got error from /127.0.0.1:7000: TIMEOUT when
> sending TCM_REPLAY_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.2:7000, /127.0.0.1:7000,
> /127.0.0.2:7000, /
> 127.0.0.3:7000, /127.0.0.1:7000], checkLive=false}
> WARN [InternalMetadataStage:8] 2023-03-17 11:55:49,394 NoSpamLogger.java:108
> - Not currently a member of the CMS
> WARN [Messaging-EventLoop-3-1] 2023-03-17 11:56:04,636 NoSpamLogger.java:108
> - /127.0.0.2:7000->/127.0.0.1:7000-SMALL_MESSAGES-[no-channel] dropping
> message of type TCM_REPLAY_REQ whose timeout expired before reaching the
> network
> ERROR [InternalResponseStage:5] 2023-03-17 11:56:04,637
> RemoteProcessor.java:164 - Got error from /127.0.0.1:7000: TIMEOUT when
> sending TCM_REPLAY_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.2:7000, /127.0.0.3:7000,
> /127.0.0.1:7000, /
> 127.0.0.2:7000, /127.0.0.1:7000, /127.0.0.2:7000, /127.0.0.3:7000,
> /127.0.0.1:7000], checkLive=false}
> WARN [InternalMetadataStage:11] 2023-03-17 11:56:04,892
> NoSpamLogger.java:108 - Not currently a member of the CMS
> ...
> ERROR [InternalResponseStage:6] 2023-03-17 11:56:20,335
> RemoteProcessor.java:164 - Got error from /127.0.0.1:7000: TIMEOUT when
> sending TCM_REPLAY_REQ, retrying on
> CandidateIterator{candidates=[/127.0.0.2:7000, /127.0.0.1:7000],
> check
[jira] [Created] (CASSANDRA-18347) CEP-21: Startup failures in Python dtests around TCM_REPLAY_REQ
Caleb Rackliffe created CASSANDRA-18347:
---
Summary: CEP-21: Startup failures in Python dtests around
TCM_REPLAY_REQ
Key: CASSANDRA-18347
URL: https://issues.apache.org/jira/browse/CASSANDRA-18347
Project: Cassandra
Issue Type: Bug
Reporter: Caleb Rackliffe
There are currently widespread, locally reproducible failures in the Python
dtests against the {{cep-21-tcm}} branch. For example...
{noformat}pytest --cassandra-dir=/Users/maedhroz/Forks/cassandra
topology_test.py::TestTopology::test_decommissioned_node_cant_rejoin{noformat}
{noformat}pytest --cassandra-dir=/Users/maedhroz/Forks/cassandra
materialized_views_test.py::TestMaterializedViews::test_query_new_column{noformat}
{noformat}pytest --cassandra-dir=/Users/maedhroz/Forks/cassandra
read_repair_test.py::TestSpeculativeReadRepair::test_normal_read_repair{noformat}
https://app.circleci.com/pipelines/github/maedhroz/cassandra/701/workflows/44a5c7e0-0de0-4839-bbd0-80771fe23843/jobs/7251
https://app.circleci.com/pipelines/github/beobal/cassandra/406/workflows/00cdb02e-4b3e-477a-b997-403121172249/jobs/4204/tests
The death spiral in the node startup logs starts like this…
{noformat}
WARN [Messaging-EventLoop-3-1] 2023-03-17 11:55:34,037 NoSpamLogger.java:108 -
/127.0.0.2:7000->/127.0.0.1:7000-SMALL_MESSAGES-[no-channel] dropping message
of type TCM_REPLAY_REQ whose timeout expired before reaching the network
ERROR [InternalResponseStage:3] 2023-03-17 11:55:34,038
RemoteProcessor.java:164 - Got error from /127.0.0.1:7000: TIMEOUT when sending
TCM_REPLAY_REQ, retrying on CandidateIterator{candidates=[/127.0.0.2:7000,
/127.0.0.1:7000], checkLive=false}
INFO [Messaging-EventLoop-3-12] 2023-03-17 11:55:34,099
InboundConnectionInitiator.java:567 -
/127.0.0.2:7000(/127.0.0.2:49763)->/127.0.0.2:7000-SMALL_MESSAGES-1b9301b6
messaging connection established, version = 13, framing = CRC, encryption =
unencrypted
INFO [Messaging-EventLoop-3-9] 2023-03-17 11:55:34,099
OutboundConnection.java:1164 -
/127.0.0.2:7000(/127.0.0.2:49763)->/127.0.0.2:7000-SMALL_MESSAGES-a9302b2e
successfully connected, version = 13, framing = CRC, encryption = unencrypted
WARN [InternalMetadataStage:5] 2023-03-17 11:55:34,100 NoSpamLogger.java:108 -
Not currently a member of the CMS
INFO [Messaging-EventLoop-3-13] 2023-03-17 11:55:34,102
InboundConnectionInitiator.java:567 -
/127.0.0.2:7000(/127.0.0.2:49764)->/127.0.0.2:7000-URGENT_MESSAGES-f887f6fa
messaging connection established, version = 13, framing = CRC, encryption =
unencrypted
INFO [Messaging-EventLoop-3-11] 2023-03-17 11:55:34,102
OutboundConnection.java:1164 -
/127.0.0.2:7000(/127.0.0.2:49764)->/127.0.0.2:7000-URGENT_MESSAGES-5cd0c637
successfully connected, version = 13, framing = CRC, encryption = unencrypted
ERROR [InternalResponseStage:4] 2023-03-17 11:55:49,237
RemoteProcessor.java:164 - Got error from /127.0.0.1:7000: TIMEOUT when sending
TCM_REPLAY_REQ, retrying on CandidateIterator{candidates=[/127.0.0.2:7000,
/127.0.0.1:7000, /127.0.0.2:7000, /
127.0.0.3:7000, /127.0.0.1:7000], checkLive=false}
WARN [InternalMetadataStage:8] 2023-03-17 11:55:49,394 NoSpamLogger.java:108 -
Not currently a member of the CMS
WARN [Messaging-EventLoop-3-1] 2023-03-17 11:56:04,636 NoSpamLogger.java:108 -
/127.0.0.2:7000->/127.0.0.1:7000-SMALL_MESSAGES-[no-channel] dropping message
of type TCM_REPLAY_REQ whose timeout expired before reaching the network
ERROR [InternalResponseStage:5] 2023-03-17 11:56:04,637
RemoteProcessor.java:164 - Got error from /127.0.0.1:7000: TIMEOUT when sending
TCM_REPLAY_REQ, retrying on CandidateIterator{candidates=[/127.0.0.2:7000,
/127.0.0.3:7000, /127.0.0.1:7000, /
127.0.0.2:7000, /127.0.0.1:7000, /127.0.0.2:7000, /127.0.0.3:7000,
/127.0.0.1:7000], checkLive=false}
WARN [InternalMetadataStage:11] 2023-03-17 11:56:04,892 NoSpamLogger.java:108
- Not currently a member of the CMS
...
ERROR [InternalResponseStage:6] 2023-03-17 11:56:20,335
RemoteProcessor.java:164 - Got error from /127.0.0.1:7000: TIMEOUT when sending
TCM_REPLAY_REQ, retrying on CandidateIterator{candidates=[/127.0.0.2:7000,
/127.0.0.1:7000], checkLive=false}
WARN [InternalMetadataStage:14] 2023-03-17 11:56:20,391 NoSpamLogger.java:108
- Not currently a member of the CMS
ERROR [InternalResponseStage:7] 2023-03-17 11:56:21,750
RemoteProcessor.java:164 - Got error from /127.0.0.3:7000: TIMEOUT when sending
TCM_REPLAY_REQ, retrying on CandidateIterator{candidates=[/127.0.0.1:7000,
/127.0.0.2:7000, /127.0.0.1:7000, /
127.0.0.2:7000, /127.0.0.3:7000, /127.0.0.1:7000, /127.0.0.2:7000,
/127.0.0.1:7000, /127.0.0.2:7000, /127.0.0.3:7000, /127.0.0.3:7000],
checkLive=false}
WARN [Messaging-EventLoop-3-1] 2023-03-17 11:56:35,535 NoSpamLogger.java:108 -
/127.0.0.2:7000->/127.0.0.1:7000-SMALL_MESSAGES-[no-channel] dropping message
of type TCM_REPLAY_REQ whose timeout expired befor
[jira] [Commented] (CASSANDRA-17199) Provide summary of failed SessionInfo's in StreamResultFuture
[
https://issues.apache.org/jira/browse/CASSANDRA-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702883#comment-17702883
]
David Capwell commented on CASSANDRA-17199:
---
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|trunk|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-17199-trunk-3F786B8E-529E-458A-ADB8-E9671D37A7A6]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-17199-trunk-3F786B8E-529E-458A-ADB8-E9671D37A7A6]|[build|unknown]|
> Provide summary of failed SessionInfo's in StreamResultFuture
> -
>
> Key: CASSANDRA-17199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17199
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Brendan Cicchi
>Assignee: Natnael Adere
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
>
> Currently, we warn about the presence of one or more failed sessions existing
> in the final state and then an operator/user traces back through the logs to
> find any failed streams for troubleshooting.
> {code:java}
> private synchronized void maybeComplete()
> {
> if (finishedAllSessions())
> {
> StreamState finalState = getCurrentState();
> if (finalState.hasFailedSession())
> {
> logger.warn("[Stream #{}] Stream failed", planId);
> tryFailure(new StreamException(finalState, "Stream failed"));
> }
> else
> {
> logger.info("[Stream #{}] All sessions completed", planId);
> trySuccess(finalState);
> }
> }
> } {code}
> It would be helpful to log out a summary of the SessionInfo for each failed
> session since that should be accessible via the StreamState.
>
> This can be especially helpful for longer streaming operations like bootstrap
> where the failure could have been a long time back and all recent streams
> leading up to the warning actually are successful.
>
--
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-8928) Add downgradesstables
[ https://issues.apache.org/jira/browse/CASSANDRA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-8928: - Epic Link: CASSANDRA-18300 > Add downgradesstables > - > > Key: CASSANDRA-8928 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8928 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Tools >Reporter: Jeremy Hanna >Assignee: Claude Warren >Priority: Low > Labels: remove-reopen > Fix For: 5.x > > > As mentioned in other places such as CASSANDRA-8047 and in the wild, > sometimes you need to go back. A downgrade sstables utility would be nice > for a lot of reasons and I don't know that supporting going back to the > previous major version format would be too much code since we already support > reading the previous version. -- 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-18346) Error Unknown column during deserialization missing keyspace and table name
Brad Schoening created CASSANDRA-18346:
--
Summary: Error Unknown column during deserialization missing
keyspace and table name
Key: CASSANDRA-18346
URL: https://issues.apache.org/jira/browse/CASSANDRA-18346
Project: Cassandra
Issue Type: Bug
Components: Observability/Logging
Reporter: Brad Schoening
The ERROR message generated in ColumnSubselection.java when a column name is
not found only prints the column name, not the keyspace and table. It can be
difficult to track down the source when more than one table uses the same name.
E.g., 'id'.
{quote}{{if (column == null)}}
{{{}}
{{ // If we don't find the definition, it could be we have data for a
dropped column, and we shouldn't}}
{{ // fail deserialization because of that. So we grab a "fake"
ColumnMetadata that ensure proper}}
{{ // deserialization. The column will be ignore later on anyway.}}
{{ column = metadata.getDroppedColumn(name);}}
{{ if (column == null)}}
{{ throw new UnknownColumnException("Unknown column " +
UTF8Type.instance.getString(name) + " during deserialization");}}
{{}}}
{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-17199) Provide summary of failed SessionInfo's in StreamResultFuture
[
https://issues.apache.org/jira/browse/CASSANDRA-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702866#comment-17702866
]
David Capwell commented on CASSANDRA-17199:
---
The author is on vacation and moving on, so will finish this work.
> Provide summary of failed SessionInfo's in StreamResultFuture
> -
>
> Key: CASSANDRA-17199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17199
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Brendan Cicchi
>Assignee: Natnael Adere
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
>
> Currently, we warn about the presence of one or more failed sessions existing
> in the final state and then an operator/user traces back through the logs to
> find any failed streams for troubleshooting.
> {code:java}
> private synchronized void maybeComplete()
> {
> if (finishedAllSessions())
> {
> StreamState finalState = getCurrentState();
> if (finalState.hasFailedSession())
> {
> logger.warn("[Stream #{}] Stream failed", planId);
> tryFailure(new StreamException(finalState, "Stream failed"));
> }
> else
> {
> logger.info("[Stream #{}] All sessions completed", planId);
> trySuccess(finalState);
> }
> }
> } {code}
> It would be helpful to log out a summary of the SessionInfo for each failed
> session since that should be accessible via the StreamState.
>
> This can be especially helpful for longer streaming operations like bootstrap
> where the failure could have been a long time back and all recent streams
> leading up to the warning actually are successful.
>
--
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-17199) Provide summary of failed SessionInfo's in StreamResultFuture
[
https://issues.apache.org/jira/browse/CASSANDRA-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702866#comment-17702866
]
David Capwell edited comment on CASSANDRA-17199 at 3/20/23 5:45 PM:
The author is on vacation and moving on, so i will finish this work.
was (Author: dcapwell):
The author is on vacation and moving on, so will finish this work.
> Provide summary of failed SessionInfo's in StreamResultFuture
> -
>
> Key: CASSANDRA-17199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17199
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Brendan Cicchi
>Assignee: Natnael Adere
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 5.x
>
>
> Currently, we warn about the presence of one or more failed sessions existing
> in the final state and then an operator/user traces back through the logs to
> find any failed streams for troubleshooting.
> {code:java}
> private synchronized void maybeComplete()
> {
> if (finishedAllSessions())
> {
> StreamState finalState = getCurrentState();
> if (finalState.hasFailedSession())
> {
> logger.warn("[Stream #{}] Stream failed", planId);
> tryFailure(new StreamException(finalState, "Stream failed"));
> }
> else
> {
> logger.info("[Stream #{}] All sessions completed", planId);
> trySuccess(finalState);
> }
> }
> } {code}
> It would be helpful to log out a summary of the SessionInfo for each failed
> session since that should be accessible via the StreamState.
>
> This can be especially helpful for longer streaming operations like bootstrap
> where the failure could have been a long time back and all recent streams
> leading up to the warning actually are successful.
>
--
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-18345) Enable streaming SAI components as part of repair
Mike Adamson created CASSANDRA-18345: Summary: 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 TBD -- 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 ] Mike Adamson updated CASSANDRA-18345: - Labels: SAI (was: ) > 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 > > TBD -- 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-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702752#comment-17702752
]
Paulo Motta edited comment on CASSANDRA-18304 at 3/20/23 5:33 PM:
--
CI failed due to unused imports
Resubmitted after fixing
* 4.1 CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2368/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2368/pipeline]
* trunk CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2369/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2369/pipeline]
was (Author: paulo):
CI failed due to unused imports
Resubmitted after fixing
* 4.1 CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2365/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2365/pipeline]
* trunk CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2366/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2366/pipeline]
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
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-18167) Bypass row-awareness for small partitions
[ https://issues.apache.org/jira/browse/CASSANDRA-18167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-18167: - Labels: SAI (was: ) > Bypass row-awareness for small partitions > - > > Key: CASSANDRA-18167 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18167 > Project: Cassandra > Issue Type: Improvement > Components: Feature/SAI >Reporter: Mike Adamson >Priority: Normal > Labels: SAI > > SAI supports row-awareness in that it indexes both the partition key and the > clustering key of a row. This improves query performance significantly for > wide partitions with many rows but it can impact performance for small > partitions where it could make sense to bypass row-awareness post-filter the > results (read the whole partition) or batch rows for a single partition. > However this is achieved it would be necessary for the index to have an idea > of the size of the partition being read and to be aware of whether reading > the whole partition is likely to improve read performance. > SAI is aware of partition sizes during indexing so one option would be feed > these sizes into a histogram in the index metadata and apply a set of rules > to this metadata to decide whether we should attempt any optimisation. -- 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-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 ] Mike Adamson updated CASSANDRA-18217: - Labels: SAI (was: ) > 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 >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-18165) Investigate removing PriorityQueue usage from KeyRangeConcatIterator
[
https://issues.apache.org/jira/browse/CASSANDRA-18165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Adamson updated CASSANDRA-18165:
-
Labels: SAI (was: )
> Investigate removing PriorityQueue usage from KeyRangeConcatIterator
>
>
> Key: CASSANDRA-18165
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18165
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
>Reporter: Mike Adamson
>Priority: Normal
> Labels: SAI
>
> It has been identified during the review of CASSANDRA-18058 that the
> KeyRangeConcatIterator could potentially stop using a PriorityQueue to
> maintain it's active list of sorted KeyRangeIterators.
> The code suggested by [~maedhroz] is as follows:
> {code:java}
> private int i = 0;
> ...
> protected void performSkipTo(PrimaryKey primaryKey)
> {
> while (i < toRelease.size())
> {
> RangeIterator currentIterator = toRelease.get(i);
> if (currentIterator.getCurrent().compareTo(primaryKey) >= 0)
> break;
> if (currentIterator.getMaximum().compareTo(primaryKey) >= 0)
> {
> currentIterator.skipTo(primaryKey);
> break;
> }
> i++;
> }
> }
> ...
> protected PrimaryKey computeNext()
> {
> while (i < toRelease.size())
> {
> RangeIterator currentIterator = toRelease.get(i);
>
> if (currentIterator.hasNext())
> return currentIterator.next();
>
> i++;
> }
> return endOfData();
> }
> {code}
> It was decided that this change would need performance and correctness
> testing in it's own right would not be included in the original SAI CEP
> ticket.
--
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-18058) In-memory index and query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-18058: - Labels: SAI (was: ) > In-memory index and query path > -- > > Key: CASSANDRA-18058 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18058 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Labels: SAI > Fix For: NA > > > An in-memory index using the in-memory trie structure introduced with > CASSANDRA-17240 along with a query path implementation to perform index > queries from the in-memory index. -- 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-18062) On-disk string index with index building and on-disk query path
[ https://issues.apache.org/jira/browse/CASSANDRA-18062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-18062: - Labels: SAI (was: ) > On-disk string index with index building and on-disk query path > --- > > Key: CASSANDRA-18062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18062 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Labels: SAI > Fix For: NA > > > An on-disk index for string (literal) datatypes. This index is used for the > following datatypes: > * UTF8Type > * AsciiType > * CompositeType > * Frozen types > This includes the ability to write the index to disk at index creation, by > specific index rebuild and during SSTable compaction. > Also the ability to query the on-disk index and combine the results with > those from the in-memory indexes created by CASSANDRA-18058. -- 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-18216) Allow sharding of the SAI in-memory index
[ https://issues.apache.org/jira/browse/CASSANDRA-18216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-18216: - Labels: SAI (was: ) > Allow sharding of the SAI in-memory index > -- > > Key: CASSANDRA-18216 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18216 > Project: Cassandra > Issue Type: Improvement > Components: Feature/SAI >Reporter: Mike Adamson >Priority: Normal > Labels: SAI > > The Memtable implementation allows it to be split into a number of shards. > This reduces contention during writes. > The MemtableIndex in SAI should follow this practice. It currently does not > support sharding so all writes hit the same synchronized write block. The > in-memory index search can also use the sharding to reduce the number of > indexes that it searches based on the key range passed to the search. -- 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-18067) On-disk numeric index
[ https://issues.apache.org/jira/browse/CASSANDRA-18067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-18067: - Labels: SAI (was: ) > On-disk numeric index > - > > Key: CASSANDRA-18067 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18067 > Project: Cassandra > Issue Type: New Feature > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Labels: SAI > Fix For: NA > > > An on-disk numeric index for all datatypes not supported by the on-disk > literal index (CASSANDRA-18062) -- 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-18166) Improve the code model around IndexContext
[ https://issues.apache.org/jira/browse/CASSANDRA-18166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Adamson updated CASSANDRA-18166: - Labels: SAI (was: ) > Improve the code model around IndexContext > -- > > Key: CASSANDRA-18166 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18166 > Project: Cassandra > Issue Type: Improvement > Components: Feature/SAI >Reporter: Mike Adamson >Priority: Normal > Labels: SAI > > We currently have a situation where we need to create an IndexContext that is > for a non-indexed column and therefore is never going to be used for indexing > or searching. This results in the IndexContext having to check for this at > points in the code with assertions. The reason for this that, even when the > column is non-indexed, we need to have information about the column for the > purpose of post-filtering. > It would make sense to split out the column / index information needed for > filtering from the indexing / searching requirements such that we could avoid > unnecessary assertions in the 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] [Updated] (CASSANDRA-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18247: Fix Version/s: 5.0 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/0dea9c268a023b0bb78784c815dec23575f9c30f Resolution: Fixed Status: Resolved (was: Ready to Commit) > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose CircleCI config files which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- 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-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702855#comment-17702855 ] Ekaterina Dimitrova commented on CASSANDRA-18247: - Obtained approval to commit from [~mck] offline. Committed to https://github.com/apache/cassandra [3eb605b4db..0dea9c268a|https://github.com/apache/cassandra/commit/0dea9c268a023b0bb78784c815dec23575f9c30f] trunk -> trunk > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose CircleCI config files which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- 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-18247) Add CircleCI config files for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18247: Status: Ready to Commit (was: Review In Progress) > Add CircleCI config files for J11+J17 > - > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose CircleCI config files which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- 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-17701) Failing test: TestRepair.test_failure_during_validation
[
https://issues.apache.org/jira/browse/CASSANDRA-17701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702754#comment-17702754
]
Jacek Lewandowski commented on CASSANDRA-17701:
---
thanks [~brandon.williams]
> Failing test: TestRepair.test_failure_during_validation
>
>
> Key: CASSANDRA-17701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17701
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-3.11/371/testReport/dtest.repair_tests.repair_test/TestRepair/test_failure_during_validation/
> {noformat}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [Repair#1:1] 2022-06-19 16:45:53,295 CassandraDaemon.java:237
> - Exception in thread Thread[Repair#1:1,5,RMI
> Runtime]\njava.util.concurrent.CancellationException: Task was
> cancelled.\n\tat
> com.google.common.util.concurrent.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:392)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)\n\tat
>
> com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)\n\tat
>
> com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)\n\tat
> org.apache.cassandra.repair.RepairJob.run(RepairJob.java:138)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)\n\tat
> java.lang.Thread.run(Thread.java:748)\nCaused by:
> java.util.concurrent.CancellationException: Future.cancel() was called.\n\tat
> com.google.common.util.concurrent.AbstractFuture$Sync.complete(AbstractFuture.java:378)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.cancel(AbstractFuture.java:355)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:131)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.setOneValue(Futures.java:1752)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.access$400(Futures.java:1608)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture$2.run(Futures.java:1686)\n\tat
>
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:134)\n\tat
>
> org.apache.cassandra.repair.RepairSession.forceShutdown(RepairSession.java:320)\n\tat
>
> org.apache.cassandra.repair.RepairSession.convict(RepairSession.java:359)\n\tat
>
> org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:297)\n\tat
> org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:891)\n\tat
> org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:239)\n\tat
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)\n\t...
> 4 common frames omitted']
> {noformat}
--
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-18156) Test Failure: repair_tests.deprecated_repair_test.TestDeprecatedRepairNotifications.test_deprecated_repair_error_notification
[ https://issues.apache.org/jira/browse/CASSANDRA-18156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18156: - Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > Test Failure: > repair_tests.deprecated_repair_test.TestDeprecatedRepairNotifications.test_deprecated_repair_error_notification > - > > Key: CASSANDRA-18156 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18156 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Michael Semb Wever >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Failing since > https://ci-cassandra.apache.org/job/Cassandra-3.0/313/testReport/dtest.repair_tests.deprecated_repair_test/TestDeprecatedRepairNotifications > which is > https://github.com/apache/cassandra/commit/13d495aa7d5b7a7c121fcc9e105f79107c5c2a1c > from CASSANDRA-17254 > but can be reproduced earlier in circleci, e.g. > https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/64/workflows/f99abc05-aa9b-42de-a424-44ab7c247e76/jobs/3175 > > Only two commits are in this time-range (10th to 30th November) in > cassandra-dtest > - > https://github.com/apache/cassandra-dtest/commit/7f2b8eda5c52fb6f637aa7166e2d48cd34a64eec > (CASSANDRA-17679) > - > https://github.com/apache/cassandra-dtest/commit/e0d3cc90558a17b63634d15ee6df339ceb87b225 > (CASSANDRA-15402) -- 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-18102) Add a virtual table to list snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702753#comment-17702753
]
Paulo Motta commented on CASSANDRA-18102:
-
bq. I was discussing with Andres that we might add CQL functions taking longs
and returning whatever size unit one wants. Like sizeof('true_size', 'MiB')
would return it in MiB.
This would be nice, is there a ticket for it yet?
bq. The build seems fairly OK.
+1, let's wait 24 hours to see if there's any feedback in the discuss thread
and we can merge this tomorrow
> Add a virtual table to list snapshots
> -
>
> Key: CASSANDRA-18102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18102
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Local/Snapshots
>Reporter: Paulo Motta
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 5.0
>
> Time Spent: 8h 40m
> Remaining Estimate: 0h
>
> It should be possible to query a node's snapshots via virtual tables.
> The table should expose the same fields/columns as the
> [TableSnapshot|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/snapshot/TableSnapshot.java]
> class.
> Something along these lines:
> {noformat}
> cqlsh> SELECT * FROM system_views.snapshots;
>
> tag | keyspace_name | table_name | table_id | is_ephemeral | created_at |
> expires_at | directories
> +---++---+--+---++
> 1670460346841 | system | compaction_info |
> 123e4567-e89b-12d3-a456-426614174000 | false | 2022-12-08T00:45:47.108Z |
> null |
> {'/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/snapshots/1670460346841'}
> {noformat}
--
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-17701) Failing test: TestRepair.test_failure_during_validation
[
https://issues.apache.org/jira/browse/CASSANDRA-17701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17701:
-
Status: Ready to Commit (was: Changes Suggested)
> Failing test: TestRepair.test_failure_during_validation
>
>
> Key: CASSANDRA-17701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17701
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-3.11/371/testReport/dtest.repair_tests.repair_test/TestRepair/test_failure_during_validation/
> {noformat}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [Repair#1:1] 2022-06-19 16:45:53,295 CassandraDaemon.java:237
> - Exception in thread Thread[Repair#1:1,5,RMI
> Runtime]\njava.util.concurrent.CancellationException: Task was
> cancelled.\n\tat
> com.google.common.util.concurrent.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:392)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)\n\tat
>
> com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)\n\tat
>
> com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)\n\tat
> org.apache.cassandra.repair.RepairJob.run(RepairJob.java:138)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)\n\tat
> java.lang.Thread.run(Thread.java:748)\nCaused by:
> java.util.concurrent.CancellationException: Future.cancel() was called.\n\tat
> com.google.common.util.concurrent.AbstractFuture$Sync.complete(AbstractFuture.java:378)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.cancel(AbstractFuture.java:355)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:131)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.setOneValue(Futures.java:1752)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.access$400(Futures.java:1608)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture$2.run(Futures.java:1686)\n\tat
>
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:134)\n\tat
>
> org.apache.cassandra.repair.RepairSession.forceShutdown(RepairSession.java:320)\n\tat
>
> org.apache.cassandra.repair.RepairSession.convict(RepairSession.java:359)\n\tat
>
> org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:297)\n\tat
> org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:891)\n\tat
> org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:239)\n\tat
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)\n\t...
> 4 common frames omitted']
> {noformat}
--
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-18304) hinted_handoff_enabled=false is not honored
[
https://issues.apache.org/jira/browse/CASSANDRA-18304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702752#comment-17702752
]
Paulo Motta commented on CASSANDRA-18304:
-
CI failed due to unused imports
Resubmitted after fixing
* 4.1 CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2365/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2365/pipeline]
* trunk CI:
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/2366/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/2366/pipeline]
> hinted_handoff_enabled=false is not honored
> ---
>
> Key: CASSANDRA-18304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18304
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Hints
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1.x, 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I've had some dtests with disabled hints failing.
> After investigation it seems that CASSANDRA-17164 moved hint submission on
> timeout from
> [RequestCallbacks.onExpired|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-b73c13ea8cae91a215495917fe5e90d55c9f4a283f9e053110992bc9a60004b8L176]
> to
> [AbstractWriteResponseHandler.onFailure|https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b#diff-3b202de0d077638bede7bf4076a15eb4d483b717f955f11e743efb8d27c6eb1dR285],
> but it no longer checks if {{CallbackInfo.shouldHint}} which checks for
> {{StorageProxy.shouldHint}} which ultimately checks if
> {{{}hinted_handoff_enabled=true{}}}.
> This could cause some tests which expect hints to be disabled to fail
> intermittently.
--
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-17701) Failing test: TestRepair.test_failure_during_validation
[
https://issues.apache.org/jira/browse/CASSANDRA-17701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702751#comment-17702751
]
Brandon Williams commented on CASSANDRA-17701:
--
Ah, indeed it looks like it has. Nevermind then, +1 from me.
> Failing test: TestRepair.test_failure_during_validation
>
>
> Key: CASSANDRA-17701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17701
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-3.11/371/testReport/dtest.repair_tests.repair_test/TestRepair/test_failure_during_validation/
> {noformat}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [Repair#1:1] 2022-06-19 16:45:53,295 CassandraDaemon.java:237
> - Exception in thread Thread[Repair#1:1,5,RMI
> Runtime]\njava.util.concurrent.CancellationException: Task was
> cancelled.\n\tat
> com.google.common.util.concurrent.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:392)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)\n\tat
>
> com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)\n\tat
>
> com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)\n\tat
> org.apache.cassandra.repair.RepairJob.run(RepairJob.java:138)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)\n\tat
> java.lang.Thread.run(Thread.java:748)\nCaused by:
> java.util.concurrent.CancellationException: Future.cancel() was called.\n\tat
> com.google.common.util.concurrent.AbstractFuture$Sync.complete(AbstractFuture.java:378)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.cancel(AbstractFuture.java:355)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:131)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.setOneValue(Futures.java:1752)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.access$400(Futures.java:1608)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture$2.run(Futures.java:1686)\n\tat
>
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:134)\n\tat
>
> org.apache.cassandra.repair.RepairSession.forceShutdown(RepairSession.java:320)\n\tat
>
> org.apache.cassandra.repair.RepairSession.convict(RepairSession.java:359)\n\tat
>
> org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:297)\n\tat
> org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:891)\n\tat
> org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:239)\n\tat
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)\n\t...
> 4 common frames omitted']
> {noformat}
--
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-17940) CEP-20: Dynamic Data Masking
[
https://issues.apache.org/jira/browse/CASSANDRA-17940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702693#comment-17702693
]
Andres de la Peña edited comment on CASSANDRA-17940 at 3/20/23 1:39 PM:
Thanks for the review.
I have been doing some profiling, as suggested by [~blerer]. It has shown that
[this call to
List#addAll|https://github.com/apache/cassandra/blob/641b906be5974776544a45b3f5ec3c81d7b11c53/src/java/org/apache/cassandra/cql3/functions/masking/ColumnMask.java#L123]
on {{ColumnMask#mask}} was taking a toll on performance:
!read_ddm_enabled_default_addall.png|width=627,height=687!
I have made [some
changes|https://github.com/apache/cassandra/pull/2193/commits/5495ec4de9c8139ba3ce163762ad66891901a985]
to store the partial arguments as an array, use {{System.arraycopy}} when
there are multiple arguments, and optimize for the case where there are no
partial arguments.
A [further
improvement|https://github.com/apache/cassandra/pull/2193/commits/85adba9ded965516f67e0b00b23bade5f00e1991],
at least for native functions, is exploiting the fact that all the partial
arguments in a column mask are fixed and can be either be memoized or ignored
if the function doesn't take such arguments. I have added a new
{{NativeFunction#Masker}} class to represent this. The {{ColumnMask}} caches
the {{{}Masker{}}}, so it only has to call {{Masker#mask(ByteBuffer)}} with the
value of the masked column. That allows us to avoid playing with collections on
every call to {{{}ColumnMask#mask{}}}. It also skips the unserializing of the
partial arguments on very function call.
After these two improvements, the flame graphs for running some queries look
like:
!select_query_with_ddm.jpg|width=816,height=365!
I don't see any noticable difference between unpatched trunk and the feature
branch with DDM disabled. Enabling DDM without masking any column doesn't seem
to make a difference either.
If we mask the queried columns with either {{mask_default}} or {{mask_replace}}
the query times seem to increase a little bit. That increase seems to be caused
not by the mask application, but by the use of {{SelectionWithProcessing}}
instead of {{SimpleSelection}}.
If we use {{mask_inner}} we see a more noticeable impact of masking. This is
due to the masking function unserializing the column value and serializing its
masked value,
[here|https://github.com/apache/cassandra/blob/641b906be5974776544a45b3f5ec3c81d7b11c53/src/java/org/apache/cassandra/cql3/functions/masking/PartialMaskingFunction.java#L119-L121].
I'd say this is acceptable, although perhaps we could try to optimize that
function by delegating its action to the type serializer. In any case, that
seems like something to do in a separate ticket.
was (Author: adelapena):
Thanks for the review.
I have been doing some profiling, as suggested by [~blerer]. It has shown that
[this call to
List#addAll|https://github.com/apache/cassandra/blob/641b906be5974776544a45b3f5ec3c81d7b11c53/src/java/org/apache/cassandra/cql3/functions/masking/ColumnMask.java#L123]
on {{ColumnMask#mask}} was taking a toll on performance:
!read_ddm_enabled_default_addall.png|width=627,height=687!
I have made some changes to store the partial arguments as an array, use
{{System.arraycopy}} when there are multiple arguments, and optimize for the
case where there are no partial arguments.
A further improvement, at least for native functions, is exploiting the fact
that all the partial arguments in a column mask are fixed and can be either be
memoized or ignored if the function doesn't take such arguments. I have added a
new {{NativeFunction#Masker}} class to represent this. The {{ColumnMask}}
caches the {{{}Masker{}}}, so it only has to call {{Masker#mask(ByteBuffer)}}
with the value of the masked column. That allows us to avoid playing with
collections on every call to {{{}ColumnMask#mask{}}}. It also skips the
unserializing of the partial arguments on very function call.
After these two improvements, the flame graphs for running some queries look
like:
!select_query_with_ddm.jpg|width=816,height=365!
I don't see any noticable difference between unpatched trunk and the feature
branch with DDM disabled. Enabling DDM without masking any column doesn't seem
to make a difference either.
If we mask the queried columns with either {{mask_default}} or {{mask_replace}}
the query times seem to increase a little bit. That increase seems to be caused
not by the mask application, but by the use of {{SelectionWithProcessing}}
instead of {{SimpleSelection}}.
If we use {{mask_inner}} we see a more noticeable impact of masking. This is
due to the masking function unserializing the column value and serializing its
masked value,
[here|https://github.com/apache/cassandra/blob/641b906be5974776544a45b3f5ec3c81d7b11c53/src/java/org/apache/cassa
[jira] [Comment Edited] (CASSANDRA-17940) CEP-20: Dynamic Data Masking
[
https://issues.apache.org/jira/browse/CASSANDRA-17940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702693#comment-17702693
]
Andres de la Peña edited comment on CASSANDRA-17940 at 3/20/23 1:37 PM:
Thanks for the review.
I have been doing some profiling, as suggested by [~blerer]. It has shown that
[this call to
List#addAll|https://github.com/apache/cassandra/blob/641b906be5974776544a45b3f5ec3c81d7b11c53/src/java/org/apache/cassandra/cql3/functions/masking/ColumnMask.java#L123]
on {{ColumnMask#mask}} was taking a toll on performance:
!read_ddm_enabled_default_addall.png|width=627,height=687!
I have made some changes to store the partial arguments as an array, use
{{System.arraycopy}} when there are multiple arguments, and optimize for the
case where there are no partial arguments.
A further improvement, at least for native functions, is exploiting the fact
that all the partial arguments in a column mask are fixed and can be either be
memoized or ignored if the function doesn't take such arguments. I have added a
new {{NativeFunction#Masker}} class to represent this. The {{ColumnMask}}
caches the {{{}Masker{}}}, so it only has to call {{Masker#mask(ByteBuffer)}}
with the value of the masked column. That allows us to avoid playing with
collections on every call to {{{}ColumnMask#mask{}}}. It also skips the
unserializing of the partial arguments on very function call.
After these two improvements, the flame graphs for running some queries look
like:
!select_query_with_ddm.jpg|width=816,height=365!
I don't see any noticable difference between unpatched trunk and the feature
branch with DDM disabled. Enabling DDM without masking any column doesn't seem
to make a difference either.
If we mask the queried columns with either {{mask_default}} or {{mask_replace}}
the query times seem to increase a little bit. That increase seems to be caused
not by the mask application, but by the use of {{SelectionWithProcessing}}
instead of {{SimpleSelection}}.
If we use {{mask_inner}} we see a more noticeable impact of masking. This is
due to the masking function unserializing the column value and serializing its
masked value,
[here|https://github.com/apache/cassandra/blob/641b906be5974776544a45b3f5ec3c81d7b11c53/src/java/org/apache/cassandra/cql3/functions/masking/PartialMaskingFunction.java#L119-L121].
I'd say this is acceptable, although perhaps we could try to optimize that
function by delegating its action to the type serializer. In any case, that
seems like something to do in a separate ticket.
was (Author: adelapena):
Thanks for the review.
I have been doing some profiling, as suggested by [~blerer]. It has shown that
[this call to
List#addAll|https://github.com/apache/cassandra/blob/641b906be5974776544a45b3f5ec3c81d7b11c53/src/java/org/apache/cassandra/cql3/functions/masking/ColumnMask.java#L123]
on {{ColumnMask#mask}} was taking a toll on performance:
!read_ddm_enabled_default_addall.png|width=627,height=687!
I have make some changes to store the partial arguments as an array, use
{{System.arraycopy}} when there are multiple arguments, and optimize for the
case where there are no partial arguments.
A further improvement, at least for native functions, is exploiting the fact
that all the partial arguments in a column mask are fixed and can be either be
memoized or ignored if the function doesn't take such arguments. I have added a
new {{NativeFunction#Masker}} class to represent this. The {{ColumnMask}}
caches the {{{}Masker{}}}, so it only has to call {{Masker#mask(ByteBuffer)}}
with the value of the masked column. That allows us to avoid playing with
collections on every call to {{{}ColumnMask#mask{}}}. It also skips the
unserializing of the partial arguments on very function call.
After these two improvements, the flame graphs for running some queries look
like:
!select_query_with_ddm.jpg|width=816,height=365!
I don't see any noticable difference between unpatched trunk and the feature
branch with DDM disabled. Enabling DDM without masking any column doesn't seem
to make a difference either.
If we mask the queried columns with either {{mask_default}} or {{mask_replace}}
the query times seem to increase a little bit. That increase seems to be caused
not for the mask application but from the use of {{SelectionWithProcessing}}
instead of {{{}SimpleSelection{}}}.
If we use {{mask_inner}} we see a more noticeable impact of masking. This is
due to the masking function unserializing the column value and serializing its
masked value,
[here|https://github.com/apache/cassandra/blob/641b906be5974776544a45b3f5ec3c81d7b11c53/src/java/org/apache/cassandra/cql3/functions/masking/PartialMaskingFunction.java#L119-L121].
I'd say this is acceptable, although perhaps we could try to optimize that
function by delegating its action to the type s
[jira] [Comment Edited] (CASSANDRA-17940) CEP-20: Dynamic Data Masking
[
https://issues.apache.org/jira/browse/CASSANDRA-17940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702693#comment-17702693
]
Andres de la Peña edited comment on CASSANDRA-17940 at 3/20/23 1:33 PM:
Thanks for the review.
I have been doing some profiling, as suggested by [~blerer]. It has shown that
[this call to
List#addAll|https://github.com/apache/cassandra/blob/641b906be5974776544a45b3f5ec3c81d7b11c53/src/java/org/apache/cassandra/cql3/functions/masking/ColumnMask.java#L123]
on {{ColumnMask#mask}} was taking a toll on performance:
!read_ddm_enabled_default_addall.png|width=627,height=687!
I have make some changes to store the partial arguments as an array, use
{{System.arraycopy}} when there are multiple arguments, and optimize for the
case where there are no partial arguments.
A further improvement, at least for native functions, is exploiting the fact
that all the partial arguments in a column mask are fixed and can be either be
memoized or ignored if the function doesn't take such arguments. I have added a
new {{NativeFunction#Masker}} class to represent this. The {{ColumnMask}}
caches the {{{}Masker{}}}, so it only has to call {{Masker#mask(ByteBuffer)}}
with the value of the masked column. That allows us to avoid playing with
collections on every call to {{{}ColumnMask#mask{}}}. It also skips the
unserializing of the partial arguments on very function call.
After these two improvements, the flame graphs for running some queries look
like:
!select_query_with_ddm.jpg|width=816,height=365!
I don't see any noticable difference between unpatched trunk and the feature
branch with DDM disabled. Enabling DDM without masking any column doesn't seem
to make a difference either.
If we mask the queried columns with either {{mask_default}} or {{mask_replace}}
the query times seem to increase a little bit. That increase seems to be caused
not for the mask application but from the use of {{SelectionWithProcessing}}
instead of {{{}SimpleSelection{}}}.
If we use {{mask_inner}} we see a more noticeable impact of masking. This is
due to the masking function unserializing the column value and serializing its
masked value,
[here|https://github.com/apache/cassandra/blob/641b906be5974776544a45b3f5ec3c81d7b11c53/src/java/org/apache/cassandra/cql3/functions/masking/PartialMaskingFunction.java#L119-L121].
I'd say this is acceptable, although perhaps we could try to optimize that
function by delegating its action to the type serializer. In any case, that
seems like something to do in a separate ticket.
was (Author: adelapena):
Thanks for the review.
I have been doing some profiling, as suggested by [~blerer]. It has shown that
[this call to
List#addAll|https://github.com/apache/cassandra/blob/641b906be5974776544a45b3f5ec3c81d7b11c53/src/java/org/apache/cassandra/cql3/functions/masking/ColumnMask.java#L123]
on {{ColumnMask#mask}} was taking a toll on performance:
!read_ddm_enabled_default_addall.png|width=627,height=687!
I have make some changes to store the partial arguments as an array, use
{{System.arraycopy}} when there are multiple arguments, and optimize for the
case where there are no partial arguments.
A further improvement, at least for native functions, is exploiting the fact
that all the partial arguments in a column mask are fixed and can be either be
memoized or ignored if the function doesn't take such arguments. I have added a
new {{NativeFunction#Masker}} class to represent this. The {{ColumnMask}}
caches the {{{}Masker{}}}, so it only has to call {{Masker#mask(ByteBuffer)}}
with the value of the masked column. That allows us to avoid playing with
collections on every call to {{{}ColumnMask#mask{}}}. It also skips the
unserializing of the partial arguments on very function call.
After these two improvements, the flame graphs for running some queries look
like:
!select_query_with_ddm.jpg|width=816,height=365!
Here with more detail on request processing:
!select_query_with_ddm_detail.jpg|width=816,height=365!
I don't see any noticable difference between unpatched trunk and the feature
branch with DDM disabled. Enabling DDM without masking any column doesn't seem
to make a difference either.
If we mask the queried columns with either {{mask_default}} or {{mask_replace}}
the query times seem to increase a little bit. That increase seems to be caused
not for the mask application but from the use of {{SelectionWithProcessing}}
instead of {{{}SimpleSelection{}}}.
If we use {{mask_inner}} we see a more noticeable impact of masking. This is
due to the masking function unserializing the column value and serializing its
masked value,
[here|https://github.com/apache/cassandra/blob/641b906be5974776544a45b3f5ec3c81d7b11c53/src/java/org/apache/cassandra/cql3/functions/masking/PartialMaskingFunction.java#L119-L121].
I'd say this
[jira] [Updated] (CASSANDRA-17940) CEP-20: Dynamic Data Masking
[ https://issues.apache.org/jira/browse/CASSANDRA-17940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17940: -- Attachment: (was: read_ddm_enabled_default_addall.jpg) > CEP-20: Dynamic Data Masking > > > Key: CASSANDRA-17940 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17940 > Project: Cassandra > Issue Type: Epic > Components: Feature/Dynamic Data Masking >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 5.x > > Attachments: read_ddm_enabled_default_addall.png, > select_query_with_ddm.jpg, select_query_with_ddm_detail.jpg > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Implementation of dynamic data masking as described in > [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking]. > Dynamic data masking (DDM) allows to obscure sensitive information while > still allowing access to the masked columns, and without changing the stored > data. The CEP aims to provide DDM for Apache Cassandra using both native and > user-defined CQL functions. These functions can be either be used on their > own or be attached to specific columns in the table definition. -- 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-17940) CEP-20: Dynamic Data Masking
[
https://issues.apache.org/jira/browse/CASSANDRA-17940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702693#comment-17702693
]
Andres de la Peña commented on CASSANDRA-17940:
---
Thanks for the review.
I have been doing some profiling, as suggested by [~blerer]. It has shown that
[this call to
List#addAll|https://github.com/apache/cassandra/blob/641b906be5974776544a45b3f5ec3c81d7b11c53/src/java/org/apache/cassandra/cql3/functions/masking/ColumnMask.java#L123]
on {{ColumnMask#mask}} was taking a toll on performance:
!read_ddm_enabled_default_addall.png|width=627,height=687!
I have make some changes to store the partial arguments as an array, use
{{System.arraycopy}} when there are multiple arguments, and optimize for the
case where there are no partial arguments.
A further improvement, at least for native functions, is exploiting the fact
that all the partial arguments in a column mask are fixed and can be either be
memoized or ignored if the function doesn't take such arguments. I have added a
new {{NativeFunction#Masker}} class to represent this. The {{ColumnMask}}
caches the {{{}Masker{}}}, so it only has to call {{Masker#mask(ByteBuffer)}}
with the value of the masked column. That allows us to avoid playing with
collections on every call to {{{}ColumnMask#mask{}}}. It also skips the
unserializing of the partial arguments on very function call.
After these two improvements, the flame graphs for running some queries look
like:
!select_query_with_ddm.jpg|width=816,height=365!
Here with more detail on request processing:
!select_query_with_ddm_detail.jpg|width=816,height=365!
I don't see any noticable difference between unpatched trunk and the feature
branch with DDM disabled. Enabling DDM without masking any column doesn't seem
to make a difference either.
If we mask the queried columns with either {{mask_default}} or {{mask_replace}}
the query times seem to increase a little bit. That increase seems to be caused
not for the mask application but from the use of {{SelectionWithProcessing}}
instead of {{{}SimpleSelection{}}}.
If we use {{mask_inner}} we see a more noticeable impact of masking. This is
due to the masking function unserializing the column value and serializing its
masked value,
[here|https://github.com/apache/cassandra/blob/641b906be5974776544a45b3f5ec3c81d7b11c53/src/java/org/apache/cassandra/cql3/functions/masking/PartialMaskingFunction.java#L119-L121].
I'd say this is acceptable, although perhaps we could try to optimize that
function by delegating its action to the type serializer. In any case, that
seems like something to do in a separate ticket.
> CEP-20: Dynamic Data Masking
>
>
> Key: CASSANDRA-17940
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17940
> Project: Cassandra
> Issue Type: Epic
> Components: Feature/Dynamic Data Masking
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 5.x
>
> Attachments: read_ddm_enabled_default_addall.jpg,
> read_ddm_enabled_default_addall.png, select_query_with_ddm.jpg,
> select_query_with_ddm_detail.jpg
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Implementation of dynamic data masking as described in
> [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].
> Dynamic data masking (DDM) allows to obscure sensitive information while
> still allowing access to the masked columns, and without changing the stored
> data. The CEP aims to provide DDM for Apache Cassandra using both native and
> user-defined CQL functions. These functions can be either be used on their
> own or be attached to specific columns in the table definition.
--
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-17940) CEP-20: Dynamic Data Masking
[ https://issues.apache.org/jira/browse/CASSANDRA-17940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17940: -- Attachment: read_ddm_enabled_default_addall.png > CEP-20: Dynamic Data Masking > > > Key: CASSANDRA-17940 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17940 > Project: Cassandra > Issue Type: Epic > Components: Feature/Dynamic Data Masking >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 5.x > > Attachments: read_ddm_enabled_default_addall.jpg, > read_ddm_enabled_default_addall.png, select_query_with_ddm.jpg, > select_query_with_ddm_detail.jpg > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Implementation of dynamic data masking as described in > [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking]. > Dynamic data masking (DDM) allows to obscure sensitive information while > still allowing access to the masked columns, and without changing the stored > data. The CEP aims to provide DDM for Apache Cassandra using both native and > user-defined CQL functions. These functions can be either be used on their > own or be attached to specific columns in the table definition. -- 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-17940) CEP-20: Dynamic Data Masking
[ https://issues.apache.org/jira/browse/CASSANDRA-17940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17940: -- Attachment: select_query_with_ddm_detail.jpg > CEP-20: Dynamic Data Masking > > > Key: CASSANDRA-17940 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17940 > Project: Cassandra > Issue Type: Epic > Components: Feature/Dynamic Data Masking >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 5.x > > Attachments: read_ddm_enabled_default_addall.jpg, > select_query_with_ddm.jpg, select_query_with_ddm_detail.jpg > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Implementation of dynamic data masking as described in > [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking]. > Dynamic data masking (DDM) allows to obscure sensitive information while > still allowing access to the masked columns, and without changing the stored > data. The CEP aims to provide DDM for Apache Cassandra using both native and > user-defined CQL functions. These functions can be either be used on their > own or be attached to specific columns in the table definition. -- 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-17940) CEP-20: Dynamic Data Masking
[ https://issues.apache.org/jira/browse/CASSANDRA-17940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17940: -- Attachment: select_query_with_ddm.jpg > CEP-20: Dynamic Data Masking > > > Key: CASSANDRA-17940 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17940 > Project: Cassandra > Issue Type: Epic > Components: Feature/Dynamic Data Masking >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 5.x > > Attachments: read_ddm_enabled_default_addall.jpg, > select_query_with_ddm.jpg, select_query_with_ddm_detail.jpg > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Implementation of dynamic data masking as described in > [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking]. > Dynamic data masking (DDM) allows to obscure sensitive information while > still allowing access to the masked columns, and without changing the stored > data. The CEP aims to provide DDM for Apache Cassandra using both native and > user-defined CQL functions. These functions can be either be used on their > own or be attached to specific columns in the table definition. -- 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-17940) CEP-20: Dynamic Data Masking
[ https://issues.apache.org/jira/browse/CASSANDRA-17940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17940: -- Attachment: read_ddm_enabled_default_addall.jpg > CEP-20: Dynamic Data Masking > > > Key: CASSANDRA-17940 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17940 > Project: Cassandra > Issue Type: Epic > Components: Feature/Dynamic Data Masking >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 5.x > > Attachments: read_ddm_enabled_default_addall.jpg > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Implementation of dynamic data masking as described in > [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking]. > Dynamic data masking (DDM) allows to obscure sensitive information while > still allowing access to the masked columns, and without changing the stored > data. The CEP aims to provide DDM for Apache Cassandra using both native and > user-defined CQL functions. These functions can be either be used on their > own or be attached to specific columns in the table definition. -- 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-17701) Failing test: TestRepair.test_failure_during_validation
[
https://issues.apache.org/jira/browse/CASSANDRA-17701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702672#comment-17702672
]
Jacek Lewandowski commented on CASSANDRA-17701:
---
hmmm... you talking about this:
https://issues.apache.org/jira/browse/CASSANDRA-18156 ?
> Failing test: TestRepair.test_failure_during_validation
>
>
> Key: CASSANDRA-17701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17701
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-3.11/371/testReport/dtest.repair_tests.repair_test/TestRepair/test_failure_during_validation/
> {noformat}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [Repair#1:1] 2022-06-19 16:45:53,295 CassandraDaemon.java:237
> - Exception in thread Thread[Repair#1:1,5,RMI
> Runtime]\njava.util.concurrent.CancellationException: Task was
> cancelled.\n\tat
> com.google.common.util.concurrent.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:392)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)\n\tat
>
> com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)\n\tat
>
> com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)\n\tat
> org.apache.cassandra.repair.RepairJob.run(RepairJob.java:138)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)\n\tat
> java.lang.Thread.run(Thread.java:748)\nCaused by:
> java.util.concurrent.CancellationException: Future.cancel() was called.\n\tat
> com.google.common.util.concurrent.AbstractFuture$Sync.complete(AbstractFuture.java:378)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.cancel(AbstractFuture.java:355)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:131)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.setOneValue(Futures.java:1752)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.access$400(Futures.java:1608)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture$2.run(Futures.java:1686)\n\tat
>
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:134)\n\tat
>
> org.apache.cassandra.repair.RepairSession.forceShutdown(RepairSession.java:320)\n\tat
>
> org.apache.cassandra.repair.RepairSession.convict(RepairSession.java:359)\n\tat
>
> org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:297)\n\tat
> org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:891)\n\tat
> org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:239)\n\tat
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)\n\t...
> 4 common frames omitted']
> {noformat}
--
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-17701) Failing test: TestRepair.test_failure_during_validation
[
https://issues.apache.org/jira/browse/CASSANDRA-17701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702673#comment-17702673
]
Jacek Lewandowski commented on CASSANDRA-17701:
---
it seems like it is failing for some time already
https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-3.0/cassandra-3.0
> Failing test: TestRepair.test_failure_during_validation
>
>
> Key: CASSANDRA-17701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17701
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-3.11/371/testReport/dtest.repair_tests.repair_test/TestRepair/test_failure_during_validation/
> {noformat}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [Repair#1:1] 2022-06-19 16:45:53,295 CassandraDaemon.java:237
> - Exception in thread Thread[Repair#1:1,5,RMI
> Runtime]\njava.util.concurrent.CancellationException: Task was
> cancelled.\n\tat
> com.google.common.util.concurrent.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:392)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)\n\tat
>
> com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)\n\tat
>
> com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)\n\tat
> org.apache.cassandra.repair.RepairJob.run(RepairJob.java:138)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)\n\tat
> java.lang.Thread.run(Thread.java:748)\nCaused by:
> java.util.concurrent.CancellationException: Future.cancel() was called.\n\tat
> com.google.common.util.concurrent.AbstractFuture$Sync.complete(AbstractFuture.java:378)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.cancel(AbstractFuture.java:355)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:131)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.setOneValue(Futures.java:1752)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.access$400(Futures.java:1608)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture$2.run(Futures.java:1686)\n\tat
>
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:134)\n\tat
>
> org.apache.cassandra.repair.RepairSession.forceShutdown(RepairSession.java:320)\n\tat
>
> org.apache.cassandra.repair.RepairSession.convict(RepairSession.java:359)\n\tat
>
> org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:297)\n\tat
> org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:891)\n\tat
> org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:239)\n\tat
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)\n\t...
> 4 common frames omitted']
> {noformat}
--
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-17701) Failing test: TestRepair.test_failure_during_validation
[
https://issues.apache.org/jira/browse/CASSANDRA-17701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702649#comment-17702649
]
Brandon Williams commented on CASSANDRA-17701:
--
I think as seen in your CI runs, this breaks the
TestDeprecatedRepairNotifications.test_deprecated_repair_error_notification
test.
> Failing test: TestRepair.test_failure_during_validation
>
>
> Key: CASSANDRA-17701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17701
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-3.11/371/testReport/dtest.repair_tests.repair_test/TestRepair/test_failure_during_validation/
> {noformat}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [Repair#1:1] 2022-06-19 16:45:53,295 CassandraDaemon.java:237
> - Exception in thread Thread[Repair#1:1,5,RMI
> Runtime]\njava.util.concurrent.CancellationException: Task was
> cancelled.\n\tat
> com.google.common.util.concurrent.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:392)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)\n\tat
>
> com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)\n\tat
>
> com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)\n\tat
> org.apache.cassandra.repair.RepairJob.run(RepairJob.java:138)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)\n\tat
> java.lang.Thread.run(Thread.java:748)\nCaused by:
> java.util.concurrent.CancellationException: Future.cancel() was called.\n\tat
> com.google.common.util.concurrent.AbstractFuture$Sync.complete(AbstractFuture.java:378)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.cancel(AbstractFuture.java:355)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:131)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.setOneValue(Futures.java:1752)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.access$400(Futures.java:1608)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture$2.run(Futures.java:1686)\n\tat
>
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:134)\n\tat
>
> org.apache.cassandra.repair.RepairSession.forceShutdown(RepairSession.java:320)\n\tat
>
> org.apache.cassandra.repair.RepairSession.convict(RepairSession.java:359)\n\tat
>
> org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:297)\n\tat
> org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:891)\n\tat
> org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:239)\n\tat
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)\n\t...
> 4 common frames omitted']
> {noformat}
--
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-17701) Failing test: TestRepair.test_failure_during_validation
[
https://issues.apache.org/jira/browse/CASSANDRA-17701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17701:
-
Status: Changes Suggested (was: Review In Progress)
> Failing test: TestRepair.test_failure_during_validation
>
>
> Key: CASSANDRA-17701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17701
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-3.11/371/testReport/dtest.repair_tests.repair_test/TestRepair/test_failure_during_validation/
> {noformat}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [Repair#1:1] 2022-06-19 16:45:53,295 CassandraDaemon.java:237
> - Exception in thread Thread[Repair#1:1,5,RMI
> Runtime]\njava.util.concurrent.CancellationException: Task was
> cancelled.\n\tat
> com.google.common.util.concurrent.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:392)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)\n\tat
>
> com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)\n\tat
>
> com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)\n\tat
> org.apache.cassandra.repair.RepairJob.run(RepairJob.java:138)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)\n\tat
> java.lang.Thread.run(Thread.java:748)\nCaused by:
> java.util.concurrent.CancellationException: Future.cancel() was called.\n\tat
> com.google.common.util.concurrent.AbstractFuture$Sync.complete(AbstractFuture.java:378)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.cancel(AbstractFuture.java:355)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:131)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.setOneValue(Futures.java:1752)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.access$400(Futures.java:1608)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture$2.run(Futures.java:1686)\n\tat
>
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:134)\n\tat
>
> org.apache.cassandra.repair.RepairSession.forceShutdown(RepairSession.java:320)\n\tat
>
> org.apache.cassandra.repair.RepairSession.convict(RepairSession.java:359)\n\tat
>
> org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:297)\n\tat
> org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:891)\n\tat
> org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:239)\n\tat
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)\n\t...
> 4 common frames omitted']
> {noformat}
--
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-18344) TBD
Aleksey Yeschenko created CASSANDRA-18344: - Summary: TBD Key: CASSANDRA-18344 URL: https://issues.apache.org/jira/browse/CASSANDRA-18344 Project: Cassandra Issue Type: New Feature Reporter: Aleksey Yeschenko Assignee: Aleksey Yeschenko TBD -- 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-17701) Failing test: TestRepair.test_failure_during_validation
[
https://issues.apache.org/jira/browse/CASSANDRA-17701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17701:
-
Reviewers: Brandon Williams, Brandon Williams
Brandon Williams, Brandon Williams (was: Brandon Williams)
Status: Review In Progress (was: Patch Available)
> Failing test: TestRepair.test_failure_during_validation
>
>
> Key: CASSANDRA-17701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17701
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-3.11/371/testReport/dtest.repair_tests.repair_test/TestRepair/test_failure_during_validation/
> {noformat}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [[node1] 'ERROR [Repair#1:1] 2022-06-19 16:45:53,295 CassandraDaemon.java:237
> - Exception in thread Thread[Repair#1:1,5,RMI
> Runtime]\njava.util.concurrent.CancellationException: Task was
> cancelled.\n\tat
> com.google.common.util.concurrent.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:392)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)\n\tat
>
> com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:137)\n\tat
>
> com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1509)\n\tat
> org.apache.cassandra.repair.RepairJob.run(RepairJob.java:138)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat
>
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:83)\n\tat
> java.lang.Thread.run(Thread.java:748)\nCaused by:
> java.util.concurrent.CancellationException: Future.cancel() was called.\n\tat
> com.google.common.util.concurrent.AbstractFuture$Sync.complete(AbstractFuture.java:378)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture$Sync.cancel(AbstractFuture.java:355)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:131)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.setOneValue(Futures.java:1752)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture.access$400(Futures.java:1608)\n\tat
>
> com.google.common.util.concurrent.Futures$CombinedFuture$2.run(Futures.java:1686)\n\tat
>
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)\n\tat
>
> com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145)\n\tat
>
> com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:134)\n\tat
>
> org.apache.cassandra.repair.RepairSession.forceShutdown(RepairSession.java:320)\n\tat
>
> org.apache.cassandra.repair.RepairSession.convict(RepairSession.java:359)\n\tat
>
> org.apache.cassandra.gms.FailureDetector.interpret(FailureDetector.java:297)\n\tat
> org.apache.cassandra.gms.Gossiper.doStatusCheck(Gossiper.java:891)\n\tat
> org.apache.cassandra.gms.Gossiper$GossipTask.run(Gossiper.java:239)\n\tat
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\n\tat
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)\n\t...
> 4 common frames omitted']
> {noformat}
--
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-17940) CEP-20: Dynamic Data Masking
[ https://issues.apache.org/jira/browse/CASSANDRA-17940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702607#comment-17702607 ] Berenguer Blasi commented on CASSANDRA-17940: - The only failure is a known offender. I have gone through the whole thing again. +1 > CEP-20: Dynamic Data Masking > > > Key: CASSANDRA-17940 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17940 > Project: Cassandra > Issue Type: Epic > Components: Feature/Dynamic Data Masking >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 5.x > > Time Spent: 50m > Remaining Estimate: 0h > > Implementation of dynamic data masking as described in > [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking]. > Dynamic data masking (DDM) allows to obscure sensitive information while > still allowing access to the masked columns, and without changing the stored > data. The CEP aims to provide DDM for Apache Cassandra using both native and > user-defined CQL functions. These functions can be either be used on their > own or be attached to specific columns in the table definition. -- 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-18153) Memtable being flushed without hostId in version "me" and newer during CommitLogReplay
[
https://issues.apache.org/jira/browse/CASSANDRA-18153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702463#comment-17702463
]
Jacek Lewandowski edited comment on CASSANDRA-18153 at 3/20/23 10:35 AM:
-
3.0 - [PR|https://github.com/apache/cassandra/pull/2234],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2363/]
3.11 - [PR|https://github.com/apache/cassandra/pull/2215],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2364/]
4.0 - [PR|https://github.com/apache/cassandra/pull/2231]
4.1 - [PR|https://github.com/apache/cassandra/pull/2232]
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
dtest - [PR|https://github.com/apache/cassandra-dtest/pull/216]
was (Author: jlewandowski):
3.0 - [PR|https://github.com/apache/cassandra/pull/2234],
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2363/]
3.11 - [PR|https://github.com/apache/cassandra/pull/2215]
4.0 - [PR|https://github.com/apache/cassandra/pull/2231]
4.1 - [PR|https://github.com/apache/cassandra/pull/2232]
5.0 - [PR|https://github.com/apache/cassandra/pull/2233]
dtest - [PR|https://github.com/apache/cassandra-dtest/pull/216]
> Memtable being flushed without hostId in version "me" and newer during
> CommitLogReplay
> --
>
> Key: CASSANDRA-18153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18153
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Adriano Bonacin
>Assignee: Adriano Bonacin
>Priority: Normal
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> On ticket CASSANDRA-16619 some files were changed to allow Cassandra to store
> HostID in the new "me" SSTable version.
> But SSTables flushed during CommitLogReplay miss this HostID info.
>
> In the next Cassandra startup, if these SSTables were still present,
> system.log will show:
> {{WARN Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored}}
> {{WARN }}{{{}Origin of 3 sstables is unknown or doesn't match the local node;
> commitLogIntervals for them were ignored{}}}{{{}{}}}{{ }}
>
> And debug.log will show a list of SSTables, witch can include "md" and "me"
> version (before upgradesstables):
>
> {{Ignored commitLogIntervals from the following sstables:
> [/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/me-3-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-1-big-Data.db,
>
> /var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/md-2-big-Data.db]}}
>
> https://issues.apache.org/jira/browse/CASSANDRA-16619
--
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-18102) Add a virtual table to list snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702474#comment-17702474
]
Stefan Miklosovic commented on CASSANDRA-18102:
---
The build seems fairly OK.
> Add a virtual table to list snapshots
> -
>
> Key: CASSANDRA-18102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18102
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Local/Snapshots
>Reporter: Paulo Motta
>Assignee: maxwellguo
>Priority: Normal
> Fix For: 5.0
>
> Time Spent: 8h 40m
> Remaining Estimate: 0h
>
> It should be possible to query a node's snapshots via virtual tables.
> The table should expose the same fields/columns as the
> [TableSnapshot|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/snapshot/TableSnapshot.java]
> class.
> Something along these lines:
> {noformat}
> cqlsh> SELECT * FROM system_views.snapshots;
>
> tag | keyspace_name | table_name | table_id | is_ephemeral | created_at |
> expires_at | directories
> +---++---+--+---++
> 1670460346841 | system | compaction_info |
> 123e4567-e89b-12d3-a456-426614174000 | false | 2022-12-08T00:45:47.108Z |
> null |
> {'/var/lib/cassandra/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/snapshots/1670460346841'}
> {noformat}
--
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
