[jira] [Updated] (CASSANDRA-16992) repair prepare message would produce a wrong error message if network timeout happened rather than reply wait timeout
[
https://issues.apache.org/jira/browse/CASSANDRA-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16992:
Reviewers: Berenguer Blasi, Berenguer Blasi
Berenguer Blasi, Berenguer Blasi (was: Berenguer Blasi)
Status: Review In Progress (was: Patch Available)
> repair prepare message would produce a wrong error message if network timeout
> happened rather than reply wait timeout
> -
>
> Key: CASSANDRA-16992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16992
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Test/dtest/java
>Reporter: Josh McKenzie
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> Showed up on CASSANDRA-12988 test runs; can't reproduce locally.
> {quote}
> junit.framework.AssertionFailedError: nodetool command [repair,
> distributed_test_keyspace, preparerpctimeout_full_parallel_false, --full]
> Error message 'Got negative replies from endpoints [/127.0.0.2:7012]' does
> not contain any of [Did not get replies from all endpoints.]
> stdout:
> [2021-09-22 17:37:02,187] After waiting for poll interval of 1 seconds
> queried for parent session status and discovered repair failed.
> [2021-09-22 17:37:02,187] Got negative replies from endpoints
> [/127.0.0.2:7012]
> [2021-09-22 17:37:02,187] Repair command #4 finished with error
> stderr:
> error: Got negative replies from endpoints [/127.0.0.2:7012]
> -- StackTrace --
> java.io.IOException: Got negative replies from endpoints [/127.0.0.2:7012]
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:461)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:363)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:348)
> at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:251)
> at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:895)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$39(Instance.java:805)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17072) DebuggableThreadPoolExecutor does not propagate client warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445709#comment-17445709
]
Berenguer Blasi commented on CASSANDRA-17072:
-
We usually make the circle config change in a separate commit in the same
branch. I think it keeps things a bit easier and it's also what _I think_
everybody else does.
> DebuggableThreadPoolExecutor does not propagate client warnings
> ---
>
> Key: CASSANDRA-17072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17072
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Extracted this as a separate ticket per discussion on CASSANDRA-17044
> The problem is in {{DebuggableThreadPoolExecutor}} - it does not propagate
> executor locals to the thread when tracing is disabled. It is probably
> expected that we propagate the state if at least one executor local is
> defined, but we only check for tracing and completely ignore client warnings.
> The attached PR fixes the problem, adds some tests and reverts a workaround
> for client warnings in some schema alteration statements implemented in
> CASSANDRA-16296 (described below).
>
> h4. Old description - still valid, but this is just a manifestation of the
> problem rather than the problem itself
> This seemed to be screwed a bit. In just two schema alteration statements we
> collect client warnings which are captured during the transformation into a
> local collection.
> I guess it is done that way because the transformation is being executed in a
> different stage (migration) and client warnings collected in that stage are
> not present in the stage where the query is executed.
> Then, the client warnings are retrieved using {{clientWarnings}} method and
> added to the captured client warnings in the stage which is executing the
> query.
> This mechanism was implemented only in two schema alteration statements. It
> is possible that for other ones the client warnings can simply get lost.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17072) DebuggableThreadPoolExecutor does not propagate client warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445706#comment-17445706
]
Jacek Lewandowski commented on CASSANDRA-17072:
---
:facepalm I must have confused something :(
> DebuggableThreadPoolExecutor does not propagate client warnings
> ---
>
> Key: CASSANDRA-17072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17072
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Extracted this as a separate ticket per discussion on CASSANDRA-17044
> The problem is in {{DebuggableThreadPoolExecutor}} - it does not propagate
> executor locals to the thread when tracing is disabled. It is probably
> expected that we propagate the state if at least one executor local is
> defined, but we only check for tracing and completely ignore client warnings.
> The attached PR fixes the problem, adds some tests and reverts a workaround
> for client warnings in some schema alteration statements implemented in
> CASSANDRA-16296 (described below).
>
> h4. Old description - still valid, but this is just a manifestation of the
> problem rather than the problem itself
> This seemed to be screwed a bit. In just two schema alteration statements we
> collect client warnings which are captured during the transformation into a
> local collection.
> I guess it is done that way because the transformation is being executed in a
> different stage (migration) and client warnings collected in that stage are
> not present in the stage where the query is executed.
> Then, the client warnings are retrieved using {{clientWarnings}} method and
> added to the captured client warnings in the stage which is executing the
> query.
> This mechanism was implemented only in two schema alteration statements. It
> is possible that for other ones the client warnings can simply get lost.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17072) DebuggableThreadPoolExecutor does not propagate client warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445698#comment-17445698
]
Berenguer Blasi edited comment on CASSANDRA-17072 at 11/18/21, 7:43 AM:
The CI runs SHAs don't match the SHAs on the PRs?
Edit: Sorry for being a pain lol! just trying to connect all the dots
was (Author: bereng):
The CI runs SHAs don't match the SHAs on the PRs?
> DebuggableThreadPoolExecutor does not propagate client warnings
> ---
>
> Key: CASSANDRA-17072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17072
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Extracted this as a separate ticket per discussion on CASSANDRA-17044
> The problem is in {{DebuggableThreadPoolExecutor}} - it does not propagate
> executor locals to the thread when tracing is disabled. It is probably
> expected that we propagate the state if at least one executor local is
> defined, but we only check for tracing and completely ignore client warnings.
> The attached PR fixes the problem, adds some tests and reverts a workaround
> for client warnings in some schema alteration statements implemented in
> CASSANDRA-16296 (described below).
>
> h4. Old description - still valid, but this is just a manifestation of the
> problem rather than the problem itself
> This seemed to be screwed a bit. In just two schema alteration statements we
> collect client warnings which are captured during the transformation into a
> local collection.
> I guess it is done that way because the transformation is being executed in a
> different stage (migration) and client warnings collected in that stage are
> not present in the stage where the query is executed.
> Then, the client warnings are retrieved using {{clientWarnings}} method and
> added to the captured client warnings in the stage which is executing the
> query.
> This mechanism was implemented only in two schema alteration statements. It
> is possible that for other ones the client warnings can simply get lost.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17072) DebuggableThreadPoolExecutor does not propagate client warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445701#comment-17445701
]
Jacek Lewandowski commented on CASSANDRA-17072:
---
wait, i need to verify
> DebuggableThreadPoolExecutor does not propagate client warnings
> ---
>
> Key: CASSANDRA-17072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17072
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Extracted this as a separate ticket per discussion on CASSANDRA-17044
> The problem is in {{DebuggableThreadPoolExecutor}} - it does not propagate
> executor locals to the thread when tracing is disabled. It is probably
> expected that we propagate the state if at least one executor local is
> defined, but we only check for tracing and completely ignore client warnings.
> The attached PR fixes the problem, adds some tests and reverts a workaround
> for client warnings in some schema alteration statements implemented in
> CASSANDRA-16296 (described below).
>
> h4. Old description - still valid, but this is just a manifestation of the
> problem rather than the problem itself
> This seemed to be screwed a bit. In just two schema alteration statements we
> collect client warnings which are captured during the transformation into a
> local collection.
> I guess it is done that way because the transformation is being executed in a
> different stage (migration) and client warnings collected in that stage are
> not present in the stage where the query is executed.
> Then, the client warnings are retrieved using {{clientWarnings}} method and
> added to the captured client warnings in the stage which is executing the
> query.
> This mechanism was implemented only in two schema alteration statements. It
> is possible that for other ones the client warnings can simply get lost.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17072) DebuggableThreadPoolExecutor does not propagate client warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445699#comment-17445699
]
Jacek Lewandowski commented on CASSANDRA-17072:
---
Indeed, I created separate branches with that extra commit that changes circle
configuration
> DebuggableThreadPoolExecutor does not propagate client warnings
> ---
>
> Key: CASSANDRA-17072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17072
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Extracted this as a separate ticket per discussion on CASSANDRA-17044
> The problem is in {{DebuggableThreadPoolExecutor}} - it does not propagate
> executor locals to the thread when tracing is disabled. It is probably
> expected that we propagate the state if at least one executor local is
> defined, but we only check for tracing and completely ignore client warnings.
> The attached PR fixes the problem, adds some tests and reverts a workaround
> for client warnings in some schema alteration statements implemented in
> CASSANDRA-16296 (described below).
>
> h4. Old description - still valid, but this is just a manifestation of the
> problem rather than the problem itself
> This seemed to be screwed a bit. In just two schema alteration statements we
> collect client warnings which are captured during the transformation into a
> local collection.
> I guess it is done that way because the transformation is being executed in a
> different stage (migration) and client warnings collected in that stage are
> not present in the stage where the query is executed.
> Then, the client warnings are retrieved using {{clientWarnings}} method and
> added to the captured client warnings in the stage which is executing the
> query.
> This mechanism was implemented only in two schema alteration statements. It
> is possible that for other ones the client warnings can simply get lost.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17072) DebuggableThreadPoolExecutor does not propagate client warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445698#comment-17445698
]
Berenguer Blasi commented on CASSANDRA-17072:
-
The CI runs SHAs don't match the SHAs on the PRs?
> DebuggableThreadPoolExecutor does not propagate client warnings
> ---
>
> Key: CASSANDRA-17072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17072
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Extracted this as a separate ticket per discussion on CASSANDRA-17044
> The problem is in {{DebuggableThreadPoolExecutor}} - it does not propagate
> executor locals to the thread when tracing is disabled. It is probably
> expected that we propagate the state if at least one executor local is
> defined, but we only check for tracing and completely ignore client warnings.
> The attached PR fixes the problem, adds some tests and reverts a workaround
> for client warnings in some schema alteration statements implemented in
> CASSANDRA-16296 (described below).
>
> h4. Old description - still valid, but this is just a manifestation of the
> problem rather than the problem itself
> This seemed to be screwed a bit. In just two schema alteration statements we
> collect client warnings which are captured during the transformation into a
> local collection.
> I guess it is done that way because the transformation is being executed in a
> different stage (migration) and client warnings collected in that stage are
> not present in the stage where the query is executed.
> Then, the client warnings are retrieved using {{clientWarnings}} method and
> added to the captured client warnings in the stage which is executing the
> query.
> This mechanism was implemented only in two schema alteration statements. It
> is possible that for other ones the client warnings can simply get lost.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17072) DebuggableThreadPoolExecutor does not propagate client warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445697#comment-17445697
]
Jacek Lewandowski commented on CASSANDRA-17072:
---
||PR||j8||j11||
|[4.0|https://github.com/apache/cassandra/pull/1314]|[4.0|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/128/workflows/166706de-6847-4159-b177-664d11295f35]|[4.0|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/128/workflows/8e465b6f-c8fe-4031-88ab-e44021260914]
|[trunk|https://github.com/apache/cassandra/pull/1320]|[trunk|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/130/workflows/e79f362e-ca0a-4542-a117-5fb9223463d1]|[trunk|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/130/workflows/e2e5536d-01b8-4944-b3c8-70575b34068d]|
> DebuggableThreadPoolExecutor does not propagate client warnings
> ---
>
> Key: CASSANDRA-17072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17072
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Extracted this as a separate ticket per discussion on CASSANDRA-17044
> The problem is in {{DebuggableThreadPoolExecutor}} - it does not propagate
> executor locals to the thread when tracing is disabled. It is probably
> expected that we propagate the state if at least one executor local is
> defined, but we only check for tracing and completely ignore client warnings.
> The attached PR fixes the problem, adds some tests and reverts a workaround
> for client warnings in some schema alteration statements implemented in
> CASSANDRA-16296 (described below).
>
> h4. Old description - still valid, but this is just a manifestation of the
> problem rather than the problem itself
> This seemed to be screwed a bit. In just two schema alteration statements we
> collect client warnings which are captured during the transformation into a
> local collection.
> I guess it is done that way because the transformation is being executed in a
> different stage (migration) and client warnings collected in that stage are
> not present in the stage where the query is executed.
> Then, the client warnings are retrieved using {{clientWarnings}} method and
> added to the captured client warnings in the stage which is executing the
> query.
> This mechanism was implemented only in two schema alteration statements. It
> is possible that for other ones the client warnings can simply get lost.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17138) Fix circle MID and HIGH for j11_jvm_dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-17138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17138: Fix Version/s: 4.0.2 (was: 4.0.x) Source Control Link: https://github.com/apache/cassandra/commit/74b80154bc52847f1f923857a4d2557b393878bb Resolution: Fixed Status: Resolved (was: Ready to Commit) > Fix circle MID and HIGH for j11_jvm_dtests > --- > > Key: CASSANDRA-17138 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17138 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0.2, 4.1 > > > Currently these configs have wrong values for MID and HIGH making it take 2h > when it should take around 20m to run. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated (d6f7756 -> 58b29b0)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch asf-site in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. from d6f7756 generated for eaf8d66ccfe04673f087b14c3d27165eec2b7901 add 58b29b0 generated for e35418ad9542cc50f61e9bcb3610a5a457657bd3 No new revisions were added by this update. Summary of changes: content/_/blog.html| 25 + ...and-Verification-Tool-for-Apache-Cassandra.html | 923 + content/search-index.js| 2 +- content/sitemap-Cassandra.xml | 840 +-- content/sitemap-_.xml | 128 +-- 5 files changed, 1435 insertions(+), 483 deletions(-) create mode 100644 content/_/blog/Harry-an-Open-Source-Fuzz-Testing-and-Verification-Tool-for-Apache-Cassandra.html - 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: generated for e35418ad9542cc50f61e9bcb3610a5a457657bd3
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
The following commit(s) were added to refs/heads/asf-staging by this push:
new 58b29b0 generated for e35418ad9542cc50f61e9bcb3610a5a457657bd3
58b29b0 is described below
commit 58b29b03c1002d04d573659ccc0be1ffd3818b7b
Author: mck
AuthorDate: Thu Nov 18 08:09:55 2021 +0100
generated for e35418ad9542cc50f61e9bcb3610a5a457657bd3
---
content/_/blog.html| 25 +
...and-Verification-Tool-for-Apache-Cassandra.html | 923 +
content/search-index.js| 2 +-
content/sitemap-Cassandra.xml | 840 +--
content/sitemap-_.xml | 128 +--
5 files changed, 1435 insertions(+), 483 deletions(-)
diff --git a/content/_/blog.html b/content/_/blog.html
index 1a7629c..480afd1 100644
--- a/content/_/blog.html
+++ b/content/_/blog.html
@@ -185,6 +185,31 @@
+Harry, an Open Source Fuzz Testing and Verification Tool for
Apache Cassandra
+November 18, 2021
+
+
+
+
+
+Introducing Harry, an Open Source fuzz testing and verification tool for
Apache Cassandra that can combine properties of stress- and integration-testing
tools. Harry can generate data for an arbitrary schema, execute data
modification queries against the cluster, track the progress of operation
execution, and make sure that responses to read queries are correct\
+.
+
+
+
+
+Read More
+
+
+
+
+
+
+
+
+
+
+
Inside Cassandra: an interview with Marcel Birkner at
Instana
November 17, 2021
diff --git
a/content/_/blog/Harry-an-Open-Source-Fuzz-Testing-and-Verification-Tool-for-Apache-Cassandra.html
b/content/_/blog/Harry-an-Open-Source-Fuzz-Testing-and-Verification-Tool-for-Apache-Cassandra.html
new file mode 100644
index 000..c6db3ba
--- /dev/null
+++
b/content/_/blog/Harry-an-Open-Source-Fuzz-Testing-and-Verification-Tool-for-Apache-Cassandra.html
@@ -0,0 +1,923 @@
+
+
+
+
+
+Apache Cassandra | Apache Cassandra Documentation
+
+https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,400;0,700;1,400family=Red+Hat+Display:ital,wght@0,400;0,500;0,700;1,400;1,500display=swap;
rel="stylesheet">
+
+
+https://purl.org/dc/terms/;>
+
+
+
+
+
+ const script = document.createElement("script");
+ const domain = window.location.hostname;
+ script.type = "text/javascript";
+ script.src = "https://plausible.cassandra.apache.org/js/plausible.js";;
+ script.setAttribute("data-domain",domain);
+ script.setAttribute("defer",'true');
+ script.setAttribute("async",'true');
+ document.getElementsByTagName("head")[0].appendChild(script);
+
+
+
+https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js";>
+
+
+ https://cassandra.apache.org; />
+
+
+
+
+https://cassandra.apache.org;>
+
+
+
+
+
+Get Started
+
+
+
+
+
+
+
+Cassandra Basics
+
+
+
+
+
+
+
+
+
+Quickstart
+
+
+
+
+
+
+
+
+
+Ecosystem
+
+
+
+
+
+Documentation
+
+Community
+
+
+
+
+
+
+
+Welcome
+
+
+
+
+
+
+
+
+
+Discussions
+
+
+
+
+
+
+
+
+
+Governance
+
+
+
+
+
+
+
+
+
+Contribute
+
+
+
+
+
+
+
+
+
+Meet the Community
+
+
+
[cassandra] branch trunk updated (a6cfd64 -> 5d78123)
This is an automated email from the ASF dual-hosted git repository. bereng pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from a6cfd64 Merge branch 'cassandra-4.0' into trunk new 74b8015 Fix circle MID and HIGH for j11_jvm_dtests new 5d78123 Merge branch 'cassandra-4.0' into trunk The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .circleci/config-2_1.yml.high_res.patch | 6 +++--- .circleci/config-2_1.yml.mid_res.patch | 14 +++--- .circleci/config.yml.HIGHRES| 2 +- .circleci/config.yml.MIDRES | 2 +- 4 files changed, 16 insertions(+), 8 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated: Fix circle MID and HIGH for j11_jvm_dtests
This is an automated email from the ASF dual-hosted git repository. bereng pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-4.0 by this push: new 74b8015 Fix circle MID and HIGH for j11_jvm_dtests 74b8015 is described below commit 74b80154bc52847f1f923857a4d2557b393878bb Author: Bereng AuthorDate: Tue Nov 16 12:12:19 2021 +0100 Fix circle MID and HIGH for j11_jvm_dtests patch by Berenguer Blasi; reviewed by Brandon Williams for CASSANDRA-17138 --- .circleci/config-2_1.yml.high_res.patch | 6 +++--- .circleci/config-2_1.yml.mid_res.patch | 14 +++--- .circleci/config.yml.HIGHRES| 2 +- .circleci/config.yml.MIDRES | 2 +- 4 files changed, 16 insertions(+), 8 deletions(-) diff --git a/.circleci/config-2_1.yml.high_res.patch b/.circleci/config-2_1.yml.high_res.patch index 45c54b2..d28f185 100644 --- a/.circleci/config-2_1.yml.high_res.patch +++ b/.circleci/config-2_1.yml.high_res.patch @@ -1,5 +1,5 @@ .circleci/config-2_1.yml 2021-10-18 11:48:35.0 +0100 -+++ .circleci/config-2_1.yml.HIGHRES 2021-10-18 12:03:47.0 +0100 +--- config-2_1.yml 2021-11-12 11:02:52.301079060 +0100 config-2_1.yml.HIGHRES 2021-11-16 12:04:20.083117123 +0100 @@ -101,14 +101,14 @@ j8_par_executor: _par_executor executor: @@ -58,7 +58,7 @@ -#exec_resource_class: medium - parallelism: 1 +exec_resource_class: xlarge -+ parallelism: 2 ++ parallelism: 5 j8_repeated_utest_executor: _repeated_utest_executor executor: diff --git a/.circleci/config-2_1.yml.mid_res.patch b/.circleci/config-2_1.yml.mid_res.patch index 27df9cc..28021f6 100644 --- a/.circleci/config-2_1.yml.mid_res.patch +++ b/.circleci/config-2_1.yml.mid_res.patch @@ -1,5 +1,5 @@ .circleci/config-2_1.yml 2021-10-18 11:48:35.0 +0100 -+++ .circleci/config-2_1.yml.MIDRES2021-10-18 12:02:44.0 +0100 +--- config-2_1.yml 2021-11-12 11:02:52.301079060 +0100 config-2_1.yml.MIDRES 2021-11-16 11:53:09.052881200 +0100 @@ -101,14 +101,14 @@ j8_par_executor: _par_executor executor: @@ -19,7 +19,7 @@ j8_small_executor: _small_executor executor: -@@ -119,20 +119,32 @@ +@@ -119,26 +119,38 @@ j8_medium_par_executor: _medium_par_executor executor: name: java8-executor @@ -57,6 +57,14 @@ j11_small_par_executor: _small_par_executor executor: + name: java11-executor +-#exec_resource_class: xlarge +- parallelism: 1 ++#exec_resource_class: large ++ parallelism: 10 + + j11_small_executor: _small_executor + executor: @@ -146,35 +158,47 @@ #exec_resource_class: medium parallelism: 1 diff --git a/.circleci/config.yml.HIGHRES b/.circleci/config.yml.HIGHRES index 9c21467..90aae8c 100644 --- a/.circleci/config.yml.HIGHRES +++ b/.circleci/config.yml.HIGHRES @@ -1994,7 +1994,7 @@ jobs: resource_class: xlarge working_directory: ~/ shell: /bin/bash -eo pipefail -l -parallelism: 2 +parallelism: 5 steps: - attach_workspace: at: /home/cassandra diff --git a/.circleci/config.yml.MIDRES b/.circleci/config.yml.MIDRES index b3ac410..7fb008b 100644 --- a/.circleci/config.yml.MIDRES +++ b/.circleci/config.yml.MIDRES @@ -1994,7 +1994,7 @@ jobs: resource_class: medium working_directory: ~/ shell: /bin/bash -eo pipefail -l -parallelism: 1 +parallelism: 10 steps: - attach_workspace: at: /home/cassandra - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. bereng pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 5d781232ae9481bf6680eb644d838546c3f1df8e Merge: a6cfd64 74b8015 Author: Bereng AuthorDate: Thu Nov 18 07:46:01 2021 +0100 Merge branch 'cassandra-4.0' into trunk .circleci/config-2_1.yml.high_res.patch | 6 +++--- .circleci/config-2_1.yml.mid_res.patch | 14 +++--- .circleci/config.yml.HIGHRES| 2 +- .circleci/config.yml.MIDRES | 2 +- 4 files changed, 16 insertions(+), 8 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17072) DebuggableThreadPoolExecutor does not propagate client warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445668#comment-17445668
]
Jacek Lewandowski commented on CASSANDRA-17072:
---
[trunk|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/130/workflows/e79f362e-ca0a-4542-a117-5fb9223463d1]
[4.0|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/128/workflows/166706de-6847-4159-b177-664d11295f35]
> DebuggableThreadPoolExecutor does not propagate client warnings
> ---
>
> Key: CASSANDRA-17072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17072
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Extracted this as a separate ticket per discussion on CASSANDRA-17044
> The problem is in {{DebuggableThreadPoolExecutor}} - it does not propagate
> executor locals to the thread when tracing is disabled. It is probably
> expected that we propagate the state if at least one executor local is
> defined, but we only check for tracing and completely ignore client warnings.
> The attached PR fixes the problem, adds some tests and reverts a workaround
> for client warnings in some schema alteration statements implemented in
> CASSANDRA-16296 (described below).
>
> h4. Old description - still valid, but this is just a manifestation of the
> problem rather than the problem itself
> This seemed to be screwed a bit. In just two schema alteration statements we
> collect client warnings which are captured during the transformation into a
> local collection.
> I guess it is done that way because the transformation is being executed in a
> different stage (migration) and client warnings collected in that stage are
> not present in the stage where the query is executed.
> Then, the client warnings are retrieved using {{clientWarnings}} method and
> added to the captured client warnings in the stage which is executing the
> query.
> This mechanism was implemented only in two schema alteration statements. It
> is possible that for other ones the client warnings can simply get lost.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17138) Fix circle MID and HIGH for j11_jvm_dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-17138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17138: Status: Ready to Commit (was: Review In Progress) > Fix circle MID and HIGH for j11_jvm_dtests > --- > > Key: CASSANDRA-17138 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17138 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1, 4.0.x > > > Currently these configs have wrong values for MID and HIGH making it take 2h > when it should take around 20m to run. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17066) Blog post: "Harry: A Fuzz Testing Tool for Apache Cassandra"
[ https://issues.apache.org/jira/browse/CASSANDRA-17066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-17066: --- Source Control Link: https://github.com/apache/cassandra-website/commit/e35418ad9542cc50f61e9bcb3610a5a457657bd3 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as [e35418ad9542cc50f61e9bcb3610a5a457657bd3|https://github.com/apache/cassandra-website/commit/e35418ad9542cc50f61e9bcb3610a5a457657bd3]. > Blog post: "Harry: A Fuzz Testing Tool for Apache Cassandra" > > > Key: CASSANDRA-17066 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17066 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.2, 4.1 > > Attachments: c17066-01-blog-index.png, c17066-02-blog-post.png, > c17066-03-blog-post-v2.png > > > This ticket is to capture the work associated with publishing the November > 2021 blog post titled "Harry, an Open Source Fuzz Testing and Verification > Tool for Apache Cassandra." > If this blog cannot be published by the November 9 publish date, please be > sure to *correct the date* before going live. > This ticket can be closed once the blog post has gone live on the website. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: Harry blog post
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new e35418a Harry blog post e35418a is described below commit e35418ad9542cc50f61e9bcb3610a5a457657bd3 Author: Alex Petrov AuthorDate: Tue Oct 26 15:15:03 2021 +0200 Harry blog post patch by Alex Petrov; review by Erick Ramirez for CASSANDRA-17066 --- site-content/source/modules/ROOT/pages/blog.adoc | 25 + ...and-Verification-Tool-for-Apache-Cassandra.adoc | 528 + 2 files changed, 553 insertions(+) diff --git a/site-content/source/modules/ROOT/pages/blog.adoc b/site-content/source/modules/ROOT/pages/blog.adoc index 108fb33..c7277ba 100644 --- a/site-content/source/modules/ROOT/pages/blog.adoc +++ b/site-content/source/modules/ROOT/pages/blog.adoc @@ -14,6 +14,31 @@ NOTES FOR CONTENT CREATORS [openblock,card-header] -- [discrete] +=== Harry, an Open Source Fuzz Testing and Verification Tool for Apache Cassandra +[discrete] + November 18, 2021 +-- +[openblock,card-content] +-- +Introducing Harry, an Open Source fuzz testing and verification tool for Apache Cassandra that can combine properties of stress- and integration-testing tools. Harry can generate data for an arbitrary schema, execute data modification queries against the cluster, track the progress of operation execution, and make sure that responses to read queries are correct\ +. + +[openblock,card-btn card-btn--blog] + +[.btn.btn--alt] +xref:blog/Harry-an-Open-Source-Fuzz-Testing-and-Verification-Tool-for-Apache-Cassandra.adoc[Read More] + + +-- + +//end card + +//start card +[openblock,card shadow relative test] + +[openblock,card-header] +-- +[discrete] === Inside Cassandra: an interview with Marcel Birkner at Instana [discrete] November 17, 2021 diff --git a/site-content/source/modules/ROOT/pages/blog/Harry-an-Open-Source-Fuzz-Testing-and-Verification-Tool-for-Apache-Cassandra.adoc b/site-content/source/modules/ROOT/pages/blog/Harry-an-Open-Source-Fuzz-Testing-and-Verification-Tool-for-Apache-Cassandra.adoc new file mode 100644 index 000..6701c3b --- /dev/null +++ b/site-content/source/modules/ROOT/pages/blog/Harry-an-Open-Source-Fuzz-Testing-and-Verification-Tool-for-Apache-Cassandra.adoc @@ -0,0 +1,528 @@ += Harry, an Open Source Fuzz Testing and Verification Tool for Apache Cassandra +:page-layout: single-post +:page-role: blog-post +:page-post-date: November 18, 2021 +:page-post-author: Alex Petrov +:description: The Apache Cassandra Community +:keywords: + +Over the years working on Apache Cassandra while writing tests or +trying to reproduce the issues, I’ve always found myself repeating the +same procedure over and over again: creating schema, writing loops +generating data, then either manually reconciling it to check the +results, or comparing the result set against some predetermined +expected result. Not only is this approach tedious and time-consuming, +but it also does not scale: if some set of operations work for one +schema, there’s no way to know if it will also work for any arbitrary +schema, whether it will work if operations are executed in a different +order, or if operations themselves are slightly different. + +While preparing Apache Cassandra for 4.0 release, we’ve made extensive +progress in how we test. The new in-tree in-JVM distributed test +framework enables us to easily write tests that exercise coordinated +query execution code paths while giving us flexibility and control +that was previously offered only by CQLTester, a tool for exercising +node-local query paths. Many subsystems were audited and covered with +tests. Cassandra users tried the new version out in their clusters and +reported their findings. All of these things are useful and important, +but we still needed a tool that would give us the same or higher +degree of confidence for every commit so that we could know that the +database is working as expected, not only for an exact set of +operations that exercised by unit and integration tests, but +potentially for any use-case and combination of operations under +circumstances comparable to production. + +This all led us to develop Harry, a tool that can combine properties +of stress- and integration-testing tools. Harry is a tool that can +generate data for an arbitrary schema, execute data modification +queries against the cluster, track the progress of operation +execution, and make sure that responses to read queries are correct. + +After reading this post, you will understand: + +* how Harry generates the data +* how Harry performs verification +* which properties values generated by Harry make verification not only possible but also efficient. + +The primary audience for this post is Cassandra contributors, so you +will need to
[cassandra-website] branch asf-site updated (56fcf3d -> d6f7756)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
from 56fcf3d generate website for b954b931684e544ab50370269427f4c4ed9ae675
add 4ba371d generated for commit 7324a6f2623dd39d140bf9ad6394bb9208cfb1d6
add d6f7756 generated for eaf8d66ccfe04673f087b14c3d27165eec2b7901
No new revisions were added by this update.
Summary of changes:
.../inside-Cassandra-Marcel-Birkner/image1.png | Bin 0 -> 226775 bytes
.../inside-Cassandra-Marcel-Birkner/image2.png | Bin 0 -> 190105 bytes
.../inside-Cassandra-Marcel-Birkner/image3.png | Bin 0 -> 232206 bytes
.../inside-Cassandra-Marcel-Birkner/image4.png | Bin 0 -> 106451 bytes
.../inside-Cassandra-Marcel-Birkner/image5.png | Bin 0 -> 255327 bytes
content/_/blog.html| 24 +
...-interview-with-Marcel-Birkner-at-Instana.html} | 108 ++-
content/search-index.js| 2 +-
content/sitemap-Cassandra.xml | 840 ++---
content/sitemap-_.xml | 126 ++--
10 files changed, 552 insertions(+), 548 deletions(-)
create mode 100644
content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image1.png
create mode 100644
content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image2.png
create mode 100644
content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image3.png
create mode 100644
content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image4.png
create mode 100644
content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image5.png
copy content/_/blog/{Apache-Cassandra-Changelog-3-January-2021.html =>
Inside-Cassandra-an-interview-with-Marcel-Birkner-at-Instana.html} (63%)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17072) DebuggableThreadPoolExecutor does not propagate client warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445655#comment-17445655
]
Berenguer Blasi commented on CASSANDRA-17072:
-
[~jlewandowski] I can see you only ran CI for j11 but not for j8? I tried to
start them but it doesn't allow me... :-(
> DebuggableThreadPoolExecutor does not propagate client warnings
> ---
>
> Key: CASSANDRA-17072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17072
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Extracted this as a separate ticket per discussion on CASSANDRA-17044
> The problem is in {{DebuggableThreadPoolExecutor}} - it does not propagate
> executor locals to the thread when tracing is disabled. It is probably
> expected that we propagate the state if at least one executor local is
> defined, but we only check for tracing and completely ignore client warnings.
> The attached PR fixes the problem, adds some tests and reverts a workaround
> for client warnings in some schema alteration statements implemented in
> CASSANDRA-16296 (described below).
>
> h4. Old description - still valid, but this is just a manifestation of the
> problem rather than the problem itself
> This seemed to be screwed a bit. In just two schema alteration statements we
> collect client warnings which are captured during the transformation into a
> local collection.
> I guess it is done that way because the transformation is being executed in a
> different stage (migration) and client warnings collected in that stage are
> not present in the stage where the query is executed.
> Then, the client warnings are retrieved using {{clientWarnings}} method and
> added to the captured client warnings in the stage which is executing the
> query.
> This mechanism was implemented only in two schema alteration statements. It
> is possible that for other ones the client warnings can simply get lost.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17145) utests_system_keyspace_directory and not run in Jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-17145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17145: Summary: utests_system_keyspace_directory and not run in Jenkins (was: utests_system_keyspace_directory failing and not run in Jenkins) > utests_system_keyspace_directory and not run in Jenkins > --- > > Key: CASSANDRA-17145 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17145 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0.x, 4.x > > > It seems to me utests_system_keyspace_directory which we run with 4.0 and > trunk in CircleCI do not run in Jenkins as they all fail in trunk now in > CircleCI and nothing in Jenkins. The issue is not environmental and I don't > see that group of tests under Stage View in Jenkins so they are probably not > added there? We need to investigate that further. > CC [~mck] and [~blerer] if they know anything about those - like work in > progress to be added or a reason not to be added. > FYI [~bereng] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17145) utests_system_keyspace_directory failing and not run in Jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-17145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445654#comment-17445654 ] Berenguer Blasi commented on CASSANDRA-17145: - [~e.dimitrova] right I was looking here just being nosy playing with it and I ended up trying a fix which indeed belongs to CASSANDRA-17137. And this one should be the one to add these to jenkins. > utests_system_keyspace_directory failing and not run in Jenkins > --- > > Key: CASSANDRA-17145 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17145 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0.x, 4.x > > > It seems to me utests_system_keyspace_directory which we run with 4.0 and > trunk in CircleCI do not run in Jenkins as they all fail in trunk now in > CircleCI and nothing in Jenkins. The issue is not environmental and I don't > see that group of tests under Stage View in Jenkins so they are probably not > added there? We need to investigate that further. > CC [~mck] and [~blerer] if they know anything about those - like work in > progress to be added or a reason not to be added. > FYI [~bereng] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17137) utests_system_keyspace_directory - more than 500 tests failing on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-17137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445651#comment-17445651
]
Berenguer Blasi commented on CASSANDRA-17137:
-
[~blerer] investigating CASSANDRA-17145 I ended up starting to fix this one.
Had you already started here? do you mind I take over?
> utests_system_keyspace_directory - more than 500 tests failing on trunk
> ---
>
> Key: CASSANDRA-17137
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17137
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> I have more than 500 tests failing on trunk [with the
> new|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1194/workflows/5fb2b193-d99a-4168-b10d-f7a3a05a3abf/jobs/7136]
> and [with the old
> image|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1189/workflows/416dcd5e-720e-4eca-b3d5-61767906457b/jobs/6984/tests#failed-test-1]
> - please check under {_}utests_system_keyspace_directory{_}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16992) repair prepare message would produce a wrong error message if network timeout happened rather than reply wait timeout
[
https://issues.apache.org/jira/browse/CASSANDRA-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445586#comment-17445586
]
David Capwell commented on CASSANDRA-16992:
---
lower was green as well; CI is running normal CI now
> repair prepare message would produce a wrong error message if network timeout
> happened rather than reply wait timeout
> -
>
> Key: CASSANDRA-16992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16992
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Test/dtest/java
>Reporter: Josh McKenzie
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> Showed up on CASSANDRA-12988 test runs; can't reproduce locally.
> {quote}
> junit.framework.AssertionFailedError: nodetool command [repair,
> distributed_test_keyspace, preparerpctimeout_full_parallel_false, --full]
> Error message 'Got negative replies from endpoints [/127.0.0.2:7012]' does
> not contain any of [Did not get replies from all endpoints.]
> stdout:
> [2021-09-22 17:37:02,187] After waiting for poll interval of 1 seconds
> queried for parent session status and discovered repair failed.
> [2021-09-22 17:37:02,187] Got negative replies from endpoints
> [/127.0.0.2:7012]
> [2021-09-22 17:37:02,187] Repair command #4 finished with error
> stderr:
> error: Got negative replies from endpoints [/127.0.0.2:7012]
> -- StackTrace --
> java.io.IOException: Got negative replies from endpoints [/127.0.0.2:7012]
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:461)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:363)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:348)
> at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:251)
> at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:895)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$39(Instance.java:805)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17116) When zero-copy-streaming sees a channel close this triggers the disk failure policy
[
https://issues.apache.org/jira/browse/CASSANDRA-17116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445582#comment-17445582
]
David Capwell commented on CASSANDRA-17116:
---
Also didn't bother debugging but feel the bootstrap timeout tests (see
https://app.circleci.com/pipelines/github/dcapwell/cassandra/1129/workflows/43d3d109-58a5-42ac-846a-1eca0e9233ed/jobs/8175)
are caused by this bug. when the streams are in limbo jvm-dtest waits for them
> When zero-copy-streaming sees a channel close this triggers the disk failure
> policy
> ---
>
> Key: CASSANDRA-17116
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17116
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> Found in CASSANDRA-17085.
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7264
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7256
> {code}
> ERROR [Stream-Deserializer-/127.0.0.1:7000-f2eb1a15] 2021-11-02 21:35:40,983
> DefaultFSErrorHandler.java:104 - Exiting forcefully due to file system
> exception on startup, disk failure policy "stop"
> org.apache.cassandra.io.FSWriteError: java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:227)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.writeComponent(BigTableZeroCopyWriter.java:206)
> at
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:125)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:84)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:51)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:37)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)
> at
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:62)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.channels.ClosedChannelException: null
> at
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:136)
> at
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:155)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:217)
> ... 9 common frames omitted
> {code}
> When bootstrap fails and streaming is closed, this triggers the disk failure
> policy which causes the JVM to halt by default (if this happens outside of
> bootstrap, then we stop transports and keep the JVM up).
> org.apache.cassandra.streaming.StreamDeserializingTask attempts to handle
> this by ignoring this exception, but the call to
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize
> Does try/catch and inspects exception; triggering this condition.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17031) Add support for PEM based key material for SSL
[
https://issues.apache.org/jira/browse/CASSANDRA-17031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445566#comment-17445566
]
Maulin Vasavada edited comment on CASSANDRA-17031 at 11/18/21, 1:28 AM:
I just addressed most of the comments and marked them resolved. Please check
comments still unresolved. Also, I am looking for an input on -
Currently we combine private key and the certificate chain for that private key
in a single configuration `private_key` (as you might have noticed from the
test PEM files/content). We have a separate configuration for
`trusted_certificates` which makes sense but would it be better to separate the
cert chain as a separate configuration (like `certificate_chain`)?
Also, I remember [~stefan.miklosovic] provided a comment to have an example of
a private PEM key with more than one certificates in the chain (however, not
able to locate in the older PR now). I think we should have such an example.
I'll work on it.
was (Author: maulin.vasavada):
I just addressed most of the comments and marked them resolved. Please check
comments still unresolved. Also, I am looking for an input on -
Currently we combine private key and the certificate chain for that private key
in a single configuration `private_key` (as you might have noticed from the
test PEM files/content). We have a separate configuration for
`trusted_certificates` which makes sense but would it be better to separate the
cert chain as a separate configuration (like `certificate_chain`)?
Also, I remember [~stefan.miklosovic] provided a comment to have an example of
a private PEM key with more than one certificates in the chain. I think we
should have such an example. I'll work on it.
> Add support for PEM based key material for SSL
> --
>
> Key: CASSANDRA-17031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17031
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> h1. Scope
> Currently Cassandra supports standard keystore types for SSL
> keys/certificates. The scope of this enhancement is to add support for PEM
> based key material (keys/certificate) given that PEM is widely used common
> format for the same. We intend to add support for Unencrypted and Password
> Based Encrypted (PBE) PKCS#8 formatted Private Keys in PEM format with
> standard algorithms (RSA, DSA and EC) along with the certificate chain for
> the private key and PEM based X509 certificates. The work here is going to be
> built on top of [CEP-9: Make SSLContext creation
> pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable]
> for which the code is merged for Apache Cassandra 4.1 release.
> We intend to support the key material be configured as direct PEM values
> input OR via the file (configured with keystore and truststore configurations
> today). We are not going to model PEM as a valid 'store_type' given that
> 'store_type' has a [specific
> definition|https://docs.oracle.com/en/java/javase/11/security/java-cryptography-architecture-jca-reference-guide.html#GUID-AB51DEFD-5238-4F96-967F-082F6D34FBEA].
>
> h1. Approach
> Create an implementation for
> [ISslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/ISslContextFactory.java]
> extending
> [FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java]
> implementation to add PEM formatted key/certificates.
> h1. Motivation
> PEM is a widely used format for encoding Private Keys and X.509 Certificates
> and Apache Cassandra's current implementation lacks the support for
> specifying the PEM formatted key material for SSL configurations. This means
> operators have to re-create the key material to comply to the supported
> formats (using key/trust store types - jks, pkcs12 etc) and deal with an
> operational task for managing it. This is an operational overhead we can
> avoid by supporting the PEM format making Apache Cassandra even more customer
> friendly and drive more adoption.
> h1. Proposed Changes
> # A new implementation for ISslContextFactory - PEMBasedSslContextFactory
> with the following supported configuration
> {panel:title=New configurations}
> {panel}
> |{{encryption_options: }}
> {{}}{{ssl_context_factory:}}
> {{}}{{class_name:
> org.apache.cassandra.security.PEMBasedSslContextFactory}}
> {{}}{{parameters:}}
> {{ }}{{private_key: certificate chain>}}
> {{
[jira] [Commented] (CASSANDRA-17031) Add support for PEM based key material for SSL
[
https://issues.apache.org/jira/browse/CASSANDRA-17031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445566#comment-17445566
]
Maulin Vasavada commented on CASSANDRA-17031:
-
I just addressed most of the comments and marked them resolved. Please check
comments still unresolved. Also, I am looking for an input on -
Currently we combine private key and the certificate chain for that private key
in a single configuration `private_key` (as you might have noticed from the
test PEM files/content). We have a separate configuration for
`trusted_certificates` which makes sense but would it be better to separate the
cert chain as a separate configuration (like `certificate_chain`)?
Also, I remember [~stefan.miklosovic] provided a comment to have an example of
a private PEM key with more than one certificates in the chain. I think we
should have such an example. I'll work on it.
> Add support for PEM based key material for SSL
> --
>
> Key: CASSANDRA-17031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17031
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> h1. Scope
> Currently Cassandra supports standard keystore types for SSL
> keys/certificates. The scope of this enhancement is to add support for PEM
> based key material (keys/certificate) given that PEM is widely used common
> format for the same. We intend to add support for Unencrypted and Password
> Based Encrypted (PBE) PKCS#8 formatted Private Keys in PEM format with
> standard algorithms (RSA, DSA and EC) along with the certificate chain for
> the private key and PEM based X509 certificates. The work here is going to be
> built on top of [CEP-9: Make SSLContext creation
> pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable]
> for which the code is merged for Apache Cassandra 4.1 release.
> We intend to support the key material be configured as direct PEM values
> input OR via the file (configured with keystore and truststore configurations
> today). We are not going to model PEM as a valid 'store_type' given that
> 'store_type' has a [specific
> definition|https://docs.oracle.com/en/java/javase/11/security/java-cryptography-architecture-jca-reference-guide.html#GUID-AB51DEFD-5238-4F96-967F-082F6D34FBEA].
>
> h1. Approach
> Create an implementation for
> [ISslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/ISslContextFactory.java]
> extending
> [FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java]
> implementation to add PEM formatted key/certificates.
> h1. Motivation
> PEM is a widely used format for encoding Private Keys and X.509 Certificates
> and Apache Cassandra's current implementation lacks the support for
> specifying the PEM formatted key material for SSL configurations. This means
> operators have to re-create the key material to comply to the supported
> formats (using key/trust store types - jks, pkcs12 etc) and deal with an
> operational task for managing it. This is an operational overhead we can
> avoid by supporting the PEM format making Apache Cassandra even more customer
> friendly and drive more adoption.
> h1. Proposed Changes
> # A new implementation for ISslContextFactory - PEMBasedSslContextFactory
> with the following supported configuration
> {panel:title=New configurations}
> {panel}
> |{{encryption_options: }}
> {{}}{{ssl_context_factory:}}
> {{}}{{class_name:
> org.apache.cassandra.security.PEMBasedSslContextFactory}}
> {{}}{{parameters:}}
> {{ }}{{private_key: certificate chain>}}
> {{ }}{{private_key_password: }}{{private}} {{key }}{{if}} {{it is encrypted>}}
> {{ }}{{trusted_certificates: }}|
> *NOTE:* We could reuse 'keystore_password' instead of the
> 'private_key_password'. However PEM encoded private key is not a 'keystore'
> in itself hence it would be inappropriate to piggyback on that other than
> avoid duplicating similar fields.
> # The PEMBasedSslContextFactory will also support file based key material
> (and the corresponding HOT Reloading based on file timestamp updates) for the
> PEM format via existing 'keystore' and 'truststore' encryption options.
> However in that case the 'truststore_password' configuration won't be used
> since generally PEM formatted certificates for truststore don't get encrypted
> with a password.
> # The PEMBasedSslContextFactory will internally create PKCS12
[jira] [Updated] (CASSANDRA-17159) Log read timeouts and unavailables at INFO via a no-spam logger
[ https://issues.apache.org/jira/browse/CASSANDRA-17159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-17159: -- Reviewers: David Capwell, Yifan Cai (was: David Capwell) > Log read timeouts and unavailables at INFO via a no-spam logger > --- > > Key: CASSANDRA-17159 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17159 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Logging >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.x > > Time Spent: 20m > Remaining Estimate: 0h > > We don’t have great logging visibility into timeouts and unavailables for > reads and range reads. If we limit output to something like 1 per minute at > INFO, we should be able to avoid spam but also have some record of what > exactly failed. This could be especially helpful during node bounces and > upgrades. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17159) Log read timeouts and unavailables at INFO via a no-spam logger
[ https://issues.apache.org/jira/browse/CASSANDRA-17159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17159: -- Fix Version/s: 4.x (was: 4.1) > Log read timeouts and unavailables at INFO via a no-spam logger > --- > > Key: CASSANDRA-17159 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17159 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Logging >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > We don’t have great logging visibility into timeouts and unavailables for > reads and range reads. If we limit output to something like 1 per minute at > INFO, we should be able to avoid spam but also have some record of what > exactly failed. This could be especially helpful during node bounces and > upgrades. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16992) repair prepare message would produce a wrong error message if network timeout happened rather than reply wait timeout
[
https://issues.apache.org/jira/browse/CASSANDRA-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16992:
--
Complexity: Low Hanging Fruit (was: Normal)
> repair prepare message would produce a wrong error message if network timeout
> happened rather than reply wait timeout
> -
>
> Key: CASSANDRA-16992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16992
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Test/dtest/java
>Reporter: Josh McKenzie
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> Showed up on CASSANDRA-12988 test runs; can't reproduce locally.
> {quote}
> junit.framework.AssertionFailedError: nodetool command [repair,
> distributed_test_keyspace, preparerpctimeout_full_parallel_false, --full]
> Error message 'Got negative replies from endpoints [/127.0.0.2:7012]' does
> not contain any of [Did not get replies from all endpoints.]
> stdout:
> [2021-09-22 17:37:02,187] After waiting for poll interval of 1 seconds
> queried for parent session status and discovered repair failed.
> [2021-09-22 17:37:02,187] Got negative replies from endpoints
> [/127.0.0.2:7012]
> [2021-09-22 17:37:02,187] Repair command #4 finished with error
> stderr:
> error: Got negative replies from endpoints [/127.0.0.2:7012]
> -- StackTrace --
> java.io.IOException: Got negative replies from endpoints [/127.0.0.2:7012]
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:461)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:363)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:348)
> at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:251)
> at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:895)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$39(Instance.java:805)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16992) repair prepare message would produce a wrong error message if network timeout happened rather than reply wait timeout
[
https://issues.apache.org/jira/browse/CASSANDRA-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16992:
--
Component/s: Consistency/Repair
> repair prepare message would produce a wrong error message if network timeout
> happened rather than reply wait timeout
> -
>
> Key: CASSANDRA-16992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16992
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Test/dtest/java
>Reporter: Josh McKenzie
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> Showed up on CASSANDRA-12988 test runs; can't reproduce locally.
> {quote}
> junit.framework.AssertionFailedError: nodetool command [repair,
> distributed_test_keyspace, preparerpctimeout_full_parallel_false, --full]
> Error message 'Got negative replies from endpoints [/127.0.0.2:7012]' does
> not contain any of [Did not get replies from all endpoints.]
> stdout:
> [2021-09-22 17:37:02,187] After waiting for poll interval of 1 seconds
> queried for parent session status and discovered repair failed.
> [2021-09-22 17:37:02,187] Got negative replies from endpoints
> [/127.0.0.2:7012]
> [2021-09-22 17:37:02,187] Repair command #4 finished with error
> stderr:
> error: Got negative replies from endpoints [/127.0.0.2:7012]
> -- StackTrace --
> java.io.IOException: Got negative replies from endpoints [/127.0.0.2:7012]
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:461)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:363)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:348)
> at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:251)
> at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:895)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$39(Instance.java:805)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16992) repair prepare message would produce a wrong error message if network timeout happened rather than reply wait timeout
[
https://issues.apache.org/jira/browse/CASSANDRA-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16992:
--
Fix Version/s: 4.x
> repair prepare message would produce a wrong error message if network timeout
> happened rather than reply wait timeout
> -
>
> Key: CASSANDRA-16992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16992
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Josh McKenzie
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> Showed up on CASSANDRA-12988 test runs; can't reproduce locally.
> {quote}
> junit.framework.AssertionFailedError: nodetool command [repair,
> distributed_test_keyspace, preparerpctimeout_full_parallel_false, --full]
> Error message 'Got negative replies from endpoints [/127.0.0.2:7012]' does
> not contain any of [Did not get replies from all endpoints.]
> stdout:
> [2021-09-22 17:37:02,187] After waiting for poll interval of 1 seconds
> queried for parent session status and discovered repair failed.
> [2021-09-22 17:37:02,187] Got negative replies from endpoints
> [/127.0.0.2:7012]
> [2021-09-22 17:37:02,187] Repair command #4 finished with error
> stderr:
> error: Got negative replies from endpoints [/127.0.0.2:7012]
> -- StackTrace --
> java.io.IOException: Got negative replies from endpoints [/127.0.0.2:7012]
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:461)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:363)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:348)
> at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:251)
> at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:895)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$39(Instance.java:805)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16992) repair prepare message would produce a wrong error message if network timeout happened rather than reply wait timeout
[
https://issues.apache.org/jira/browse/CASSANDRA-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445557#comment-17445557
]
David Capwell commented on CASSANDRA-16992:
---
ran repeat job with HIGHER; green. Testing with LOWER now
> repair prepare message would produce a wrong error message if network timeout
> happened rather than reply wait timeout
> -
>
> Key: CASSANDRA-16992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16992
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Josh McKenzie
>Assignee: David Capwell
>Priority: Normal
>
> Showed up on CASSANDRA-12988 test runs; can't reproduce locally.
> {quote}
> junit.framework.AssertionFailedError: nodetool command [repair,
> distributed_test_keyspace, preparerpctimeout_full_parallel_false, --full]
> Error message 'Got negative replies from endpoints [/127.0.0.2:7012]' does
> not contain any of [Did not get replies from all endpoints.]
> stdout:
> [2021-09-22 17:37:02,187] After waiting for poll interval of 1 seconds
> queried for parent session status and discovered repair failed.
> [2021-09-22 17:37:02,187] Got negative replies from endpoints
> [/127.0.0.2:7012]
> [2021-09-22 17:37:02,187] Repair command #4 finished with error
> stderr:
> error: Got negative replies from endpoints [/127.0.0.2:7012]
> -- StackTrace --
> java.io.IOException: Got negative replies from endpoints [/127.0.0.2:7012]
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:461)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:363)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:348)
> at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:251)
> at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:895)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$39(Instance.java:805)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16992) repair prepare message would produce a wrong error message if network timeout happened rather than reply wait timeout
[
https://issues.apache.org/jira/browse/CASSANDRA-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16992:
--
Test and Documentation Plan: repeat jobs
Status: Patch Available (was: In Progress)
> repair prepare message would produce a wrong error message if network timeout
> happened rather than reply wait timeout
> -
>
> Key: CASSANDRA-16992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16992
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Josh McKenzie
>Assignee: David Capwell
>Priority: Normal
>
> Showed up on CASSANDRA-12988 test runs; can't reproduce locally.
> {quote}
> junit.framework.AssertionFailedError: nodetool command [repair,
> distributed_test_keyspace, preparerpctimeout_full_parallel_false, --full]
> Error message 'Got negative replies from endpoints [/127.0.0.2:7012]' does
> not contain any of [Did not get replies from all endpoints.]
> stdout:
> [2021-09-22 17:37:02,187] After waiting for poll interval of 1 seconds
> queried for parent session status and discovered repair failed.
> [2021-09-22 17:37:02,187] Got negative replies from endpoints
> [/127.0.0.2:7012]
> [2021-09-22 17:37:02,187] Repair command #4 finished with error
> stderr:
> error: Got negative replies from endpoints [/127.0.0.2:7012]
> -- StackTrace --
> java.io.IOException: Got negative replies from endpoints [/127.0.0.2:7012]
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:461)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:363)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:348)
> at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:251)
> at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:895)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$39(Instance.java:805)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16992) repair prepare message would produce a wrong error message if network timeout happened rather than reply wait timeout
[
https://issues.apache.org/jira/browse/CASSANDRA-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16992:
--
Summary: repair prepare message would produce a wrong error message if
network timeout happened rather than reply wait timeout (was: in-jvm dtest
failure: prepareRPCTimeout[PARALLEL/false] -
org.apache.cassandra.distributed.test.FullRepairCoordinatorTimeoutTest)
> repair prepare message would produce a wrong error message if network timeout
> happened rather than reply wait timeout
> -
>
> Key: CASSANDRA-16992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16992
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Josh McKenzie
>Priority: Normal
>
> Showed up on CASSANDRA-12988 test runs; can't reproduce locally.
> {quote}
> junit.framework.AssertionFailedError: nodetool command [repair,
> distributed_test_keyspace, preparerpctimeout_full_parallel_false, --full]
> Error message 'Got negative replies from endpoints [/127.0.0.2:7012]' does
> not contain any of [Did not get replies from all endpoints.]
> stdout:
> [2021-09-22 17:37:02,187] After waiting for poll interval of 1 seconds
> queried for parent session status and discovered repair failed.
> [2021-09-22 17:37:02,187] Got negative replies from endpoints
> [/127.0.0.2:7012]
> [2021-09-22 17:37:02,187] Repair command #4 finished with error
> stderr:
> error: Got negative replies from endpoints [/127.0.0.2:7012]
> -- StackTrace --
> java.io.IOException: Got negative replies from endpoints [/127.0.0.2:7012]
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:461)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:363)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:348)
> at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:251)
> at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:895)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$39(Instance.java:805)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16992) repair prepare message would produce a wrong error message if network timeout happened rather than reply wait timeout
[
https://issues.apache.org/jira/browse/CASSANDRA-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell reassigned CASSANDRA-16992:
-
Assignee: David Capwell
> repair prepare message would produce a wrong error message if network timeout
> happened rather than reply wait timeout
> -
>
> Key: CASSANDRA-16992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16992
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Josh McKenzie
>Assignee: David Capwell
>Priority: Normal
>
> Showed up on CASSANDRA-12988 test runs; can't reproduce locally.
> {quote}
> junit.framework.AssertionFailedError: nodetool command [repair,
> distributed_test_keyspace, preparerpctimeout_full_parallel_false, --full]
> Error message 'Got negative replies from endpoints [/127.0.0.2:7012]' does
> not contain any of [Did not get replies from all endpoints.]
> stdout:
> [2021-09-22 17:37:02,187] After waiting for poll interval of 1 seconds
> queried for parent session status and discovered repair failed.
> [2021-09-22 17:37:02,187] Got negative replies from endpoints
> [/127.0.0.2:7012]
> [2021-09-22 17:37:02,187] Repair command #4 finished with error
> stderr:
> error: Got negative replies from endpoints [/127.0.0.2:7012]
> -- StackTrace --
> java.io.IOException: Got negative replies from endpoints [/127.0.0.2:7012]
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:461)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:363)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:348)
> at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:251)
> at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:895)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$39(Instance.java:805)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17159) Log read timeouts and unavailables at INFO via a no-spam logger
[ https://issues.apache.org/jira/browse/CASSANDRA-17159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17159: -- Reviewers: David Capwell Status: Review In Progress (was: Patch Available) left small comments in PR; overall LGTM, will do a final review after comments are addressed > Log read timeouts and unavailables at INFO via a no-spam logger > --- > > Key: CASSANDRA-17159 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17159 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Logging >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.1 > > Time Spent: 10m > Remaining Estimate: 0h > > We don’t have great logging visibility into timeouts and unavailables for > reads and range reads. If we limit output to something like 1 per minute at > INFO, we should be able to avoid spam but also have some record of what > exactly failed. This could be especially helpful during node bounces and > upgrades. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17116) When zero-copy-streaming sees a channel close this triggers the disk failure policy
[
https://issues.apache.org/jira/browse/CASSANDRA-17116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445541#comment-17445541
]
Dinesh Joshi edited comment on CASSANDRA-17116 at 11/17/21, 11:07 PM:
--
I think with the introduction of {{COMPLETE_ACK}}, we would need to also
introduce a timeout after the {{COMPLETE}} message is transmitted but before
the sender closes the Channel. This would give the receiving peer time to
consume all the data and the {{COMPLETE}} message. This would not only solve
the issue but also be backward compatible as we could send {{COMPLETE_ACK}} to
peers that support the message and not to other peers.
was (Author: djoshi3):
I think with the introduction of {{COMPLETE_ACK}}, we would need to also
introduce a timeout after the {{COMPLETE}} message is transmitted but before
the sender closes the Channel. This would give the receiving peer time to
consume all the data and the `COMPLETE` message. This would also be backward
compatible as we could send {{COMPLETE_ACK}} to peers that support the message
and not to other peers.
> When zero-copy-streaming sees a channel close this triggers the disk failure
> policy
> ---
>
> Key: CASSANDRA-17116
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17116
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> Found in CASSANDRA-17085.
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7264
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7256
> {code}
> ERROR [Stream-Deserializer-/127.0.0.1:7000-f2eb1a15] 2021-11-02 21:35:40,983
> DefaultFSErrorHandler.java:104 - Exiting forcefully due to file system
> exception on startup, disk failure policy "stop"
> org.apache.cassandra.io.FSWriteError: java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:227)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.writeComponent(BigTableZeroCopyWriter.java:206)
> at
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:125)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:84)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:51)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:37)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)
> at
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:62)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.channels.ClosedChannelException: null
> at
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:136)
> at
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:155)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:217)
> ... 9 common frames omitted
> {code}
> When bootstrap fails and streaming is closed, this triggers the disk failure
> policy which causes the JVM to halt by default (if this happens outside of
> bootstrap, then we stop transports and keep the JVM up).
> org.apache.cassandra.streaming.StreamDeserializingTask attempts to handle
> this by ignoring this exception, but the call to
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize
> Does try/catch and inspects exception; triggering this condition.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17116) When zero-copy-streaming sees a channel close this triggers the disk failure policy
[
https://issues.apache.org/jira/browse/CASSANDRA-17116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445541#comment-17445541
]
Dinesh Joshi commented on CASSANDRA-17116:
--
I think with the introduction of {{COMPLETE_ACK}}, we would need to also
introduce a timeout after the {{COMPLETE}} message is transmitted but before
the sender closes the Channel. This would give the receiving peer time to
consume all the data and the `COMPLETE` message. This would also be backward
compatible as we could send {{COMPLETE_ACK}} to peers that support the message
and not to other peers.
> When zero-copy-streaming sees a channel close this triggers the disk failure
> policy
> ---
>
> Key: CASSANDRA-17116
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17116
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> Found in CASSANDRA-17085.
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7264
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7256
> {code}
> ERROR [Stream-Deserializer-/127.0.0.1:7000-f2eb1a15] 2021-11-02 21:35:40,983
> DefaultFSErrorHandler.java:104 - Exiting forcefully due to file system
> exception on startup, disk failure policy "stop"
> org.apache.cassandra.io.FSWriteError: java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:227)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.writeComponent(BigTableZeroCopyWriter.java:206)
> at
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:125)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:84)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:51)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:37)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)
> at
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:62)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.channels.ClosedChannelException: null
> at
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:136)
> at
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:155)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:217)
> ... 9 common frames omitted
> {code}
> When bootstrap fails and streaming is closed, this triggers the disk failure
> policy which causes the JVM to halt by default (if this happens outside of
> bootstrap, then we stop transports and keep the JVM up).
> org.apache.cassandra.streaming.StreamDeserializingTask attempts to handle
> this by ignoring this exception, but the call to
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize
> Does try/catch and inspects exception; triggering this condition.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17159) Log read timeouts and unavailables at INFO via a no-spam logger
[ https://issues.apache.org/jira/browse/CASSANDRA-17159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-17159: Test and Documentation Plan: - manual verification of logging output - new in-jvm unit tests Status: Patch Available (was: In Progress) patch: https://github.com/apache/cassandra/pull/1329 CircleCI: https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-17159 See [PR notes|https://github.com/apache/cassandra/pull/1329#issue-783181256]. > Log read timeouts and unavailables at INFO via a no-spam logger > --- > > Key: CASSANDRA-17159 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17159 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Logging >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.1 > > > We don’t have great logging visibility into timeouts and unavailables for > reads and range reads. If we limit output to something like 1 per minute at > INFO, we should be able to avoid spam but also have some record of what > exactly failed. This could be especially helpful during node bounces and > upgrades. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17136) FQL: Enabling via nodetool can trigger disk_failure_mode
[
https://issues.apache.org/jira/browse/CASSANDRA-17136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445510#comment-17445510
]
Brandon Williams commented on CASSANDRA-17136:
--
This broke some FullQueryLoggerTests I'll look into.
> FQL: Enabling via nodetool can trigger disk_failure_mode
>
>
> Key: CASSANDRA-17136
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17136
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/fql
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
>
> When enabling fullquerylog via nodetool, if there is a non empty directory
> present under the location specified via --path which would trigger an
> java.nio.file.AccessDeniedException during cleaning, the node will trigger
> the disk_failure_policy which by default is stop. This is a fairly easy way
> to offline a cluster if someone executes this in parallel. I don't that think
> the behavior is desirable for enabling via nodetool.
>
> Repro (1 node cluster already up):
> {code:bash}
> mkdir /some/path/dir
> touch /some/path/dir/file
> chown -R user: /some/path/dir # Non Cassandra process user
> chmod 700 /some/path/dir
> nodetool enablefullquerylog --path /some/path
> {code}
> Nodetool will give back this error:
> {code:java}
> error: /some/path/dir/file
> -- StackTrace --
> java.nio.file.AccessDeniedException: /some/path/dir/file
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at
> sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
> at
> sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
> at java.nio.file.Files.delete(Files.java:1126)
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:250)
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:237)
> at
> org.apache.cassandra.utils.binlog.BinLog.deleteRecursively(BinLog.java:492)
> at
> org.apache.cassandra.utils.binlog.BinLog.cleanDirectory(BinLog.java:477)
> at
> org.apache.cassandra.utils.binlog.BinLog$Builder.build(BinLog.java:436)
> at
> org.apache.cassandra.fql.FullQueryLogger.enable(FullQueryLogger.java:106)
> at
> org.apache.cassandra.service.StorageService.enableFullQueryLogger(StorageService.java:5915)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:276)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
[jira] [Commented] (CASSANDRA-16992) in-jvm dtest failure: prepareRPCTimeout[PARALLEL/false] - org.apache.cassandra.distributed.test.FullRepairCoordinatorTimeoutTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445507#comment-17445507
]
David Capwell commented on CASSANDRA-16992:
---
after 27 attempts I was finally able to replicate!
{code}
INFO [node1_Repair-Task:1] node1 2021-11-17 21:53:21,355 [repair
#c1f82130-47f0-11ec-a719-b9714b384415]Repair command #6 finished with error
ERROR [node1_InternalResponseStage:2] node1 2021-11-17 21:53:22,055 Failing
prepare caused by /127.0.0.2:7012 and reason TIMEOUT
java.lang.Throwable: null
at
org.apache.cassandra.service.ActiveRepairService$2.onFailure(ActiveRepairService.java:540)
at
org.apache.cassandra.net.RequestCallbacks.lambda$onExpired$0(RequestCallbacks.java:173)
at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81)
at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
{code}
so having 2 different definitions of timeout causes this bug!
> in-jvm dtest failure: prepareRPCTimeout[PARALLEL/false] -
> org.apache.cassandra.distributed.test.FullRepairCoordinatorTimeoutTest
>
>
> Key: CASSANDRA-16992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16992
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Josh McKenzie
>Priority: Normal
>
> Showed up on CASSANDRA-12988 test runs; can't reproduce locally.
> {quote}
> junit.framework.AssertionFailedError: nodetool command [repair,
> distributed_test_keyspace, preparerpctimeout_full_parallel_false, --full]
> Error message 'Got negative replies from endpoints [/127.0.0.2:7012]' does
> not contain any of [Did not get replies from all endpoints.]
> stdout:
> [2021-09-22 17:37:02,187] After waiting for poll interval of 1 seconds
> queried for parent session status and discovered repair failed.
> [2021-09-22 17:37:02,187] Got negative replies from endpoints
> [/127.0.0.2:7012]
> [2021-09-22 17:37:02,187] Repair command #4 finished with error
> stderr:
> error: Got negative replies from endpoints [/127.0.0.2:7012]
> -- StackTrace --
> java.io.IOException: Got negative replies from endpoints [/127.0.0.2:7012]
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:461)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:363)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:348)
> at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:251)
> at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:895)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$39(Instance.java:805)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17116) When zero-copy-streaming sees a channel close this triggers the disk failure policy
[
https://issues.apache.org/jira/browse/CASSANDRA-17116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445506#comment-17445506
]
David Capwell commented on CASSANDRA-17116:
---
In talking with [~djoshi] this is the following feedback
* from an API point of view we do not know if the FileChannel or the
SocketChannel is closed; FileChannel implies race condition bug where as socket
channel may be just "network hates us". Based off stack trace we know this
case is network close.
* when we send COMPLETE we also shutdown the channels, this doesn't give the
followers enough time to consistently handle this; the feedback was to extend
the state machine to have a COMPLETE_ACK (to attempt backwards compatibility,
if we timeout and the channel is closed, assume the closed channel is an ACK
(current behavior))
* "streaming doesn't support backwards compatibility" - me: "I have been called
into prod to support repair in mixed mode... so lets try ^_^"
> When zero-copy-streaming sees a channel close this triggers the disk failure
> policy
> ---
>
> Key: CASSANDRA-17116
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17116
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> Found in CASSANDRA-17085.
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7264
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1069/workflows/26b7b83a-686f-4516-a56a-0709d428d4f2/jobs/7256
> {code}
> ERROR [Stream-Deserializer-/127.0.0.1:7000-f2eb1a15] 2021-11-02 21:35:40,983
> DefaultFSErrorHandler.java:104 - Exiting forcefully due to file system
> exception on startup, disk failure policy "stop"
> org.apache.cassandra.io.FSWriteError: java.nio.channels.ClosedChannelException
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:227)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.writeComponent(BigTableZeroCopyWriter.java:206)
> at
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:125)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:84)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:51)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:37)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:50)
> at
> org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:62)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.channels.ClosedChannelException: null
> at
> org.apache.cassandra.net.AsyncStreamingInputPlus.reBuffer(AsyncStreamingInputPlus.java:136)
> at
> org.apache.cassandra.net.AsyncStreamingInputPlus.consume(AsyncStreamingInputPlus.java:155)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableZeroCopyWriter.write(BigTableZeroCopyWriter.java:217)
> ... 9 common frames omitted
> {code}
> When bootstrap fails and streaming is closed, this triggers the disk failure
> policy which causes the JVM to halt by default (if this happens outside of
> bootstrap, then we stop transports and keep the JVM up).
> org.apache.cassandra.streaming.StreamDeserializingTask attempts to handle
> this by ignoring this exception, but the call to
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize
> Does try/catch and inspects exception; triggering this condition.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16992) in-jvm dtest failure: prepareRPCTimeout[PARALLEL/false] - org.apache.cassandra.distributed.test.FullRepairCoordinatorTimeoutTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445487#comment-17445487
]
David Capwell commented on CASSANDRA-16992:
---
not replicated yet, but added logging to show caller... I have a feeling that
org.apache.cassandra.net.RequestCallbacks#onExpired(org.apache.cassandra.net.RequestCallbacks.CallbackInfo)
is what is doing this
{code}
if (info.invokeOnFailure())
INTERNAL_RESPONSE.submit(() -> info.callback.onFailure(info.peer,
RequestFailureReason.TIMEOUT));
{code}
if we fail with a timeout, then we don't get a timeout but instead get a
negative reply?
> in-jvm dtest failure: prepareRPCTimeout[PARALLEL/false] -
> org.apache.cassandra.distributed.test.FullRepairCoordinatorTimeoutTest
>
>
> Key: CASSANDRA-16992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16992
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Josh McKenzie
>Priority: Normal
>
> Showed up on CASSANDRA-12988 test runs; can't reproduce locally.
> {quote}
> junit.framework.AssertionFailedError: nodetool command [repair,
> distributed_test_keyspace, preparerpctimeout_full_parallel_false, --full]
> Error message 'Got negative replies from endpoints [/127.0.0.2:7012]' does
> not contain any of [Did not get replies from all endpoints.]
> stdout:
> [2021-09-22 17:37:02,187] After waiting for poll interval of 1 seconds
> queried for parent session status and discovered repair failed.
> [2021-09-22 17:37:02,187] Got negative replies from endpoints
> [/127.0.0.2:7012]
> [2021-09-22 17:37:02,187] Repair command #4 finished with error
> stderr:
> error: Got negative replies from endpoints [/127.0.0.2:7012]
> -- StackTrace --
> java.io.IOException: Got negative replies from endpoints [/127.0.0.2:7012]
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:461)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:363)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:348)
> at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:251)
> at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:895)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$39(Instance.java:805)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17161) Remove commitlog_sync_batch_window_in_ms
[ https://issues.apache.org/jira/browse/CASSANDRA-17161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445473#comment-17445473 ] Ekaterina Dimitrova commented on CASSANDRA-17161: - There are also a few other parameters deprecated already in 4.0 which we might want to revise as part of this ticket or a follow up one. FYI > Remove commitlog_sync_batch_window_in_ms > > > Key: CASSANDRA-17161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17161 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > commitlog_sync_batch_window_in_ms is deprecated in 4.0 and has to be removed > in 5.0 > This will require also some work around the in-jvm upgrade tests. > Currently they do not work if we remove a parameter in a later version. > Side note: They also don't work if we change the type of the parameter in > Config class in a newer Cassandra version. If you plan to set it in the tests > themselves, it won't work. If you change the type but your don't set the > parameter, no issue so there might be some workaround solution instead of > working on the dtest framework itself TBD -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17161) Remove commitlog_sync_batch_window_in_ms
[ https://issues.apache.org/jira/browse/CASSANDRA-17161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17161: Description: commitlog_sync_batch_window_in_ms is deprecated in 4.0 and has to be removed in 5.0 This will require also some work around the in-jvm upgrade tests. Currently they do not work if we remove a parameter in a later version. Side note: They also don't work if we change the type of the parameter in Config class in a newer Cassandra version. If you plan to set it in the tests themselves, it won't work. If you change the type but your don't set the parameter, no issue so there might be some workaround solution instead of working on the dtest framework itself TBD was: commitlog_sync_batch_window_in_ms is deprecated in 4.0 and has to be removed in 5.0 This will require also some work around the in-jvm upgrade tests. Currently they do not work if we remove a parameter in a later version. Side note: They also don't work if we change the type of the parameter in Config class in a newer Cassandra version. > Remove commitlog_sync_batch_window_in_ms > > > Key: CASSANDRA-17161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17161 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > commitlog_sync_batch_window_in_ms is deprecated in 4.0 and has to be removed > in 5.0 > This will require also some work around the in-jvm upgrade tests. > Currently they do not work if we remove a parameter in a later version. > Side note: They also don't work if we change the type of the parameter in > Config class in a newer Cassandra version. If you plan to set it in the tests > themselves, it won't work. If you change the type but your don't set the > parameter, no issue so there might be some workaround solution instead of > working on the dtest framework itself TBD -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17161) Remove commitlog_sync_batch_window_in_ms
[ https://issues.apache.org/jira/browse/CASSANDRA-17161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17161: Fix Version/s: 5.x > Remove commitlog_sync_batch_window_in_ms > > > Key: CASSANDRA-17161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17161 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 5.x > > > commitlog_sync_batch_window_in_ms is deprecated in 4.0 and has to be removed > in 5.0 > This will require also some work around the in-jvm upgrade tests. > Currently they do not work if we remove a parameter in a later version. > Side note: They also don't work if we change the type of the parameter in > Config class in a newer Cassandra version. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17161) Remove commitlog_sync_batch_window_in_ms
Ekaterina Dimitrova created CASSANDRA-17161: --- Summary: Remove commitlog_sync_batch_window_in_ms Key: CASSANDRA-17161 URL: https://issues.apache.org/jira/browse/CASSANDRA-17161 Project: Cassandra Issue Type: Task Reporter: Ekaterina Dimitrova commitlog_sync_batch_window_in_ms is deprecated in 4.0 and has to be removed in 5.0 This will require also some work around the in-jvm upgrade tests. Currently they do not work if we remove a parameter in a later version. Side note: They also don't work if we change the type of the parameter in Config class in a newer Cassandra version. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17161) Remove commitlog_sync_batch_window_in_ms
[ https://issues.apache.org/jira/browse/CASSANDRA-17161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17161: Change Category: Code Clarity Complexity: Normal Component/s: Build Status: Open (was: Triage Needed) > Remove commitlog_sync_batch_window_in_ms > > > Key: CASSANDRA-17161 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17161 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Priority: Normal > > commitlog_sync_batch_window_in_ms is deprecated in 4.0 and has to be removed > in 5.0 > This will require also some work around the in-jvm upgrade tests. > Currently they do not work if we remove a parameter in a later version. > Side note: They also don't work if we change the type of the parameter in > Config class in a newer Cassandra version. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17160) Emit warnings for deprecated parameters (changed names) only once
[ https://issues.apache.org/jira/browse/CASSANDRA-17160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17160: Change Category: Operability Complexity: Low Hanging Fruit Component/s: Build Fix Version/s: 4.0.x Assignee: Ekaterina Dimitrova Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Emit warnings for deprecated parameters (changed names) only once > - > > Key: CASSANDRA-17160 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17160 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0.x > > > We added backward compatibility for two config parameters in CASSANDRA-17141 > to fix a bug but I realized that with the current setup, a warning for > deprecated parameter can be logged more than once which is not needed and > only introduces noise to the logs. > I already fixed that in CASSANDRA-15234 where this would lead to a lot of > warnings and it is easy to spot. I will backport the tiny fix here too in > case we add more parameters, etc; to prevent the potential noise. > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17160) Emit warnings for deprecated parameters (changed names) only once
Ekaterina Dimitrova created CASSANDRA-17160: --- Summary: Emit warnings for deprecated parameters (changed names) only once Key: CASSANDRA-17160 URL: https://issues.apache.org/jira/browse/CASSANDRA-17160 Project: Cassandra Issue Type: Improvement Reporter: Ekaterina Dimitrova We added backward compatibility for two config parameters in CASSANDRA-17141 to fix a bug but I realized that with the current setup, a warning for deprecated parameter can be logged more than once which is not needed and only introduces noise to the logs. I already fixed that in CASSANDRA-15234 where this would lead to a lot of warnings and it is easy to spot. I will backport the tiny fix here too in case we add more parameters, etc; to prevent the potential noise. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16992) in-jvm dtest failure: prepareRPCTimeout[PARALLEL/false] - org.apache.cassandra.distributed.test.FullRepairCoordinatorTimeoutTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445461#comment-17445461
]
David Capwell commented on CASSANDRA-16992:
---
here is the logging code
{code}
try
{
if (!prepareLatch.await(getRpcTimeout(MILLISECONDS), MILLISECONDS))
failRepair(parentRepairSession, "Did not get replies from all
endpoints.");
}
catch (InterruptedException e)
{
failRepair(parentRepairSession, "Interrupted while waiting for
prepare repair response.");
}
if (!status.get())
{
failRepair(parentRepairSession, "Got negative replies from
endpoints " + failedNodes);
}
{code}
The test is trying to make sure we see the timeout, but the log is saying we
didn't and instead saw failed status
{code}
public void onFailure(InetAddressAndPort from, RequestFailureReason
failureReason)
{
status.set(false);
{code}
> in-jvm dtest failure: prepareRPCTimeout[PARALLEL/false] -
> org.apache.cassandra.distributed.test.FullRepairCoordinatorTimeoutTest
>
>
> Key: CASSANDRA-16992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16992
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Josh McKenzie
>Priority: Normal
>
> Showed up on CASSANDRA-12988 test runs; can't reproduce locally.
> {quote}
> junit.framework.AssertionFailedError: nodetool command [repair,
> distributed_test_keyspace, preparerpctimeout_full_parallel_false, --full]
> Error message 'Got negative replies from endpoints [/127.0.0.2:7012]' does
> not contain any of [Did not get replies from all endpoints.]
> stdout:
> [2021-09-22 17:37:02,187] After waiting for poll interval of 1 seconds
> queried for parent session status and discovered repair failed.
> [2021-09-22 17:37:02,187] Got negative replies from endpoints
> [/127.0.0.2:7012]
> [2021-09-22 17:37:02,187] Repair command #4 finished with error
> stderr:
> error: Got negative replies from endpoints [/127.0.0.2:7012]
> -- StackTrace --
> java.io.IOException: Got negative replies from endpoints [/127.0.0.2:7012]
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:461)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:363)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:348)
> at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:251)
> at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:895)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$39(Instance.java:805)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16992) in-jvm dtest failure: prepareRPCTimeout[PARALLEL/false] - org.apache.cassandra.distributed.test.FullRepairCoordinatorTimeoutTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445455#comment-17445455
]
David Capwell commented on CASSANDRA-16992:
---
I am the test author, will try to take a look today
> in-jvm dtest failure: prepareRPCTimeout[PARALLEL/false] -
> org.apache.cassandra.distributed.test.FullRepairCoordinatorTimeoutTest
>
>
> Key: CASSANDRA-16992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16992
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Josh McKenzie
>Priority: Normal
>
> Showed up on CASSANDRA-12988 test runs; can't reproduce locally.
> {quote}
> junit.framework.AssertionFailedError: nodetool command [repair,
> distributed_test_keyspace, preparerpctimeout_full_parallel_false, --full]
> Error message 'Got negative replies from endpoints [/127.0.0.2:7012]' does
> not contain any of [Did not get replies from all endpoints.]
> stdout:
> [2021-09-22 17:37:02,187] After waiting for poll interval of 1 seconds
> queried for parent session status and discovered repair failed.
> [2021-09-22 17:37:02,187] Got negative replies from endpoints
> [/127.0.0.2:7012]
> [2021-09-22 17:37:02,187] Repair command #4 finished with error
> stderr:
> error: Got negative replies from endpoints [/127.0.0.2:7012]
> -- StackTrace --
> java.io.IOException: Got negative replies from endpoints [/127.0.0.2:7012]
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:461)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:363)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:348)
> at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:251)
> at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:895)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$39(Instance.java:805)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17072) DebuggableThreadPoolExecutor does not propagate client warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445448#comment-17445448
]
David Capwell commented on CASSANDRA-17072:
---
I don't see a +1 from [~bereng] so holding off merge until he has the time to
finish his review (think this has 2 +1s, Andres and I). If [~bereng] wants to
merge I am cool with that, else I can merge
> DebuggableThreadPoolExecutor does not propagate client warnings
> ---
>
> Key: CASSANDRA-17072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17072
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Extracted this as a separate ticket per discussion on CASSANDRA-17044
> The problem is in {{DebuggableThreadPoolExecutor}} - it does not propagate
> executor locals to the thread when tracing is disabled. It is probably
> expected that we propagate the state if at least one executor local is
> defined, but we only check for tracing and completely ignore client warnings.
> The attached PR fixes the problem, adds some tests and reverts a workaround
> for client warnings in some schema alteration statements implemented in
> CASSANDRA-16296 (described below).
>
> h4. Old description - still valid, but this is just a manifestation of the
> problem rather than the problem itself
> This seemed to be screwed a bit. In just two schema alteration statements we
> collect client warnings which are captured during the transformation into a
> local collection.
> I guess it is done that way because the transformation is being executed in a
> different stage (migration) and client warnings collected in that stage are
> not present in the stage where the query is executed.
> Then, the client warnings are retrieved using {{clientWarnings}} method and
> added to the captured client warnings in the stage which is executing the
> query.
> This mechanism was implemented only in two schema alteration statements. It
> is possible that for other ones the client warnings can simply get lost.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17159) Log read timeouts and unavailables at INFO via a no-spam logger
Caleb Rackliffe created CASSANDRA-17159: --- Summary: Log read timeouts and unavailables at INFO via a no-spam logger Key: CASSANDRA-17159 URL: https://issues.apache.org/jira/browse/CASSANDRA-17159 Project: Cassandra Issue Type: Improvement Components: Observability/Logging Reporter: Caleb Rackliffe Assignee: Caleb Rackliffe We don’t have great logging visibility into timeouts and unavailables for reads and range reads. If we limit output to something like 1 per minute at INFO, we should be able to avoid spam but also have some record of what exactly failed. This could be especially helpful during node bounces and upgrades. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17159) Log read timeouts and unavailables at INFO via a no-spam logger
[ https://issues.apache.org/jira/browse/CASSANDRA-17159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-17159: Change Category: Operability Complexity: Normal Fix Version/s: 4.1 Status: Open (was: Triage Needed) > Log read timeouts and unavailables at INFO via a no-spam logger > --- > > Key: CASSANDRA-17159 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17159 > Project: Cassandra > Issue Type: Improvement > Components: Observability/Logging >Reporter: Caleb Rackliffe >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.1 > > > We don’t have great logging visibility into timeouts and unavailables for > reads and range reads. If we limit output to something like 1 per minute at > INFO, we should be able to avoid spam but also have some record of what > exactly failed. This could be especially helpful during node bounces and > upgrades. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated: generated for eaf8d66ccfe04673f087b14c3d27165eec2b7901
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
The following commit(s) were added to refs/heads/asf-staging by this push:
new d6f7756 generated for eaf8d66ccfe04673f087b14c3d27165eec2b7901
d6f7756 is described below
commit d6f77564eeaa99e3625f70c21a44f3398ee2c12e
Author: mck
AuthorDate: Wed Nov 17 19:28:01 2021 +0100
generated for eaf8d66ccfe04673f087b14c3d27165eec2b7901
---
...n-interview-with-Marcel-Birkner-at-Instana.html | 5 +-
content/search-index.js| 2 +-
content/sitemap-Cassandra.xml | 840 ++---
content/sitemap-_.xml | 124 +--
4 files changed, 487 insertions(+), 484 deletions(-)
diff --git
a/content/_/blog/Inside-Cassandra-an-interview-with-Marcel-Birkner-at-Instana.html
b/content/_/blog/Inside-Cassandra-an-interview-with-Marcel-Birkner-at-Instana.html
index b0ce25b..f974708 100644
---
a/content/_/blog/Inside-Cassandra-an-interview-with-Marcel-Birkner-at-Instana.html
+++
b/content/_/blog/Inside-Cassandra-an-interview-with-Marcel-Birkner-at-Instana.html
@@ -187,7 +187,10 @@
-Patrick McFadin, Apache Cassandra community member, sat down with Marcel
Birkner, Site Reliability Engineer (SRE) at Instana, an IBM Company. They
discussed the unique challenge faced by the company as it strives to scale
highly useful telemetry with a responsive query system. This article uses
extracts from that conversation, which took place before IBM acquired the
business.
+Welcome to Inside Cassandra, a new series on the Apache Cassandra blog,
where we interview engineers and devs in the community either about their use
of Apache Cassandra to power their businesses or how they contribute to the
project.
+
+
+In our first interview, Patrick McFadin, Apache Cassandra community member,
sat down with Marcel Birkner, Site Reliability Engineer (SRE) at Instana, an
IBM Company. They discussed the unique challenge faced by the company as it
strives to scale highly useful telemetry with a responsive query system. This
article uses extracts from that conversation, which took place before IBM
acquired the business.
One of the constants of life as an SRE is that https://www.instana.com/blog/life-of-an-sre-at-instana-things-break-all-the-time-in-distributed-systems-part-1-clickhouse/;
target="_blank" rel="noopener">things break all the time. If developers
are expanding what the product can do, and operations are making sure
everything keeps running smoothly, SREs often fill that annoying gap between
theory and practice. They fix things as they break, set up alerts to enable
them to kn [...]
diff --git a/content/search-index.js b/content/search-index.js
index b0f1be7..24966ba 100644
--- a/content/search-index.js
+++ b/content/search-index.js
@@ -1 +1 @@
-window.antoraLunr.init({"index":{"version":"2.3.8","fields":["title","name","text","component"],"fieldVectors":[["title//_/apachecon_cfp.html",[]],["name//_/apachecon_cfp.html",[0,3.334]],["text//_/apachecon_cfp.html",[]],["component//_/apachecon_cfp.html",[1,1.105]],["title//_/blog.html",[]],["name//_/blog.html",[2,2.807]],["text//_/blog.html",[]],["component//_/blog.html",[1,1.105]],["title//_/bugs.html",[]],["name//_/bugs.html",[3,2.561]],["text//_/bugs.html",[]],["component//_/bugs.h
[...]
\ No newline at end of file
+window.antoraLunr.init({"index":{"version":"2.3.8","fields":["title","name","text","component"],"fieldVectors":[["title//_/apachecon_cfp.html",[]],["name//_/apachecon_cfp.html",[0,3.334]],["text//_/apachecon_cfp.html",[]],["component//_/apachecon_cfp.html",[1,1.105]],["title//_/blog.html",[]],["name//_/blog.html",[2,2.807]],["text//_/blog.html",[]],["component//_/blog.html",[1,1.105]],["title//_/bugs.html",[]],["name//_/bugs.html",[3,2.561]],["text//_/bugs.html",[]],["component//_/bugs.h
[...]
\ No newline at end of file
diff --git a/content/sitemap-Cassandra.xml b/content/sitemap-Cassandra.xml
index 3b98ea3..89e77c7 100644
--- a/content/sitemap-Cassandra.xml
+++ b/content/sitemap-Cassandra.xml
@@ -2,1682 +2,1682 @@
http://www.sitemaps.org/schemas/sitemap/0.9;>
https://cassandra.apache.org/Cassandra/4.0/cassandra/architecture/dynamo.html
-2021-11-17T17:54:43.405Z
+2021-11-17T18:22:10.425Z
https://cassandra.apache.org/Cassandra/4.0/cassandra/architecture/guarantees.html
-2021-11-17T17:54:43.405Z
+2021-11-17T18:22:10.425Z
https://cassandra.apache.org/Cassandra/4.0/cassandra/architecture/index.html
-2021-11-17T17:54:43.405Z
+2021-11-17T18:22:10.425Z
https://cassandra.apache.org/Cassandra/4.0/cassandra/architecture/overview.html
-2021-11-17T17:54:43.405Z
+2021-11-17T18:22:10.425Z
https://cassandra.apache.org/Cassandra/4.0/cassandra/architecture/snitch.html
-2021-11-17T17:54:43.405Z
+2021-11-17T18:22:10.425Z
[jira] [Updated] (CASSANDRA-17158) BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
[
https://issues.apache.org/jira/browse/CASSANDRA-17158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17158:
---
Source Control Link:
https://github.com/apache/cassandra-website/commit/eaf8d66ccfe04673f087b14c3d27165eec2b7901
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[eaf8d66ccfe04673f087b14c3d27165eec2b7901|https://github.com/apache/cassandra-website/commit/eaf8d66ccfe04673f087b14c3d27165eec2b7901].
> BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
> -
>
> Key: CASSANDRA-17158
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17158
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0.2, 4.1
>
> Attachments: c17158-blog-post.png
>
>
> [~Calico] advised that [the intro paragraph of the Instana blog post was
> missed|https://the-asf.slack.com/archives/C01RY1LUPD5/p1637144903062900]:
> {quote}Welcome to Inside Cassandra, a new series on the Apache Cassandra
> blog, where we interview engineers and devs in the community either about
> their use of Apache Cassandra to power their businesses or how they
> contribute to the project.
> In our first interview, ...{quote}
> See [Google Doc
> draft|https://docs.google.com/document/d/1eutwlZePuf1-J6W5L1Duo7Yiy4l2TGLjfsFdW7LaF6s/edit?usp=sharing]
> for reference.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: CASSANDRA-17158 BLOG - Fixed missing paragraph in Instana post
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new eaf8d66 CASSANDRA-17158 BLOG - Fixed missing paragraph in Instana post eaf8d66 is described below commit eaf8d66ccfe04673f087b14c3d27165eec2b7901 Author: Erick Ramirez AuthorDate: Wed Nov 17 12:14:43 2021 + CASSANDRA-17158 BLOG - Fixed missing paragraph in Instana post --- ...nside-Cassandra-an-interview-with-Marcel-Birkner-at-Instana.adoc | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/site-content/source/modules/ROOT/pages/blog/Inside-Cassandra-an-interview-with-Marcel-Birkner-at-Instana.adoc b/site-content/source/modules/ROOT/pages/blog/Inside-Cassandra-an-interview-with-Marcel-Birkner-at-Instana.adoc index f2716dd..3ea9dea 100644 --- a/site-content/source/modules/ROOT/pages/blog/Inside-Cassandra-an-interview-with-Marcel-Birkner-at-Instana.adoc +++ b/site-content/source/modules/ROOT/pages/blog/Inside-Cassandra-an-interview-with-Marcel-Birkner-at-Instana.adoc @@ -6,7 +6,9 @@ :description: The Apache Cassandra Community :keywords: -Patrick McFadin, Apache Cassandra community member, sat down with Marcel Birkner, Site Reliability Engineer (SRE) at Instana, an IBM Company. They discussed the unique challenge faced by the company as it strives to scale highly useful telemetry with a responsive query system. This article uses extracts from that conversation, which took place before IBM acquired the business. +Welcome to Inside Cassandra, a new series on the Apache Cassandra blog, where we interview engineers and devs in the community either about their use of Apache Cassandra to power their businesses or how they contribute to the project. + +In our first interview, Patrick McFadin, Apache Cassandra community member, sat down with Marcel Birkner, Site Reliability Engineer (SRE) at Instana, an IBM Company. They discussed the unique challenge faced by the company as it strives to scale highly useful telemetry with a responsive query system. This article uses extracts from that conversation, which took place before IBM acquired the business. One of the constants of life as an SRE is that https://www.instana.com/blog/life-of-an-sre-at-instana-things-break-all-the-time-in-distributed-systems-part-1-clickhouse/[things break all the time,window=_blank]. If developers are expanding what the product can do, and operations are making sure everything keeps running smoothly, SREs often fill that annoying gap between theory and practice. They fix things as they break, set up alerts to enable them to know the next time it breaks, and k [...] @@ -49,4 +51,4 @@ The most important benefit of ‘dog-fooding,’ or using your own product the w “If we have problems as an SRE team, and we don't have the insights, we just tell our engineering team,” says Marcel. “Then they just enhance the product, either by new data routes or by new data that they're collecting from the different technologies we monitor. And that makes our lives a lot easier.” -Head here for more information on https://cassandra.apache.org/doc/latest/cassandra/operating/metrics.html[monitoring and metrics within Apache Cassandra], and for a list of third-party projects, tools, and products, head to the project’s https://cassandra.apache.org/_/ecosystem.html[Ecosystem page]. \ No newline at end of file +Head here for more information on https://cassandra.apache.org/doc/latest/cassandra/operating/metrics.html[monitoring and metrics within Apache Cassandra], and for a list of third-party projects, tools, and products, head to the project’s https://cassandra.apache.org/_/ecosystem.html[Ecosystem page]. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17158) BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
[
https://issues.apache.org/jira/browse/CASSANDRA-17158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CASSANDRA-17158:
---
Labels: pull-request-available (was: )
> BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
> -
>
> Key: CASSANDRA-17158
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17158
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0.x
>
> Attachments: c17158-blog-post.png
>
>
> [~Calico] advised that [the intro paragraph of the Instana blog post was
> missed|https://the-asf.slack.com/archives/C01RY1LUPD5/p1637144903062900]:
> {quote}Welcome to Inside Cassandra, a new series on the Apache Cassandra
> blog, where we interview engineers and devs in the community either about
> their use of Apache Cassandra to power their businesses or how they
> contribute to the project.
> In our first interview, ...{quote}
> See [Google Doc
> draft|https://docs.google.com/document/d/1eutwlZePuf1-J6W5L1Duo7Yiy4l2TGLjfsFdW7LaF6s/edit?usp=sharing]
> for reference.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17158) BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
[
https://issues.apache.org/jira/browse/CASSANDRA-17158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17158:
---
Fix Version/s: 4.0.2
4.1
(was: 4.0.x)
> BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
> -
>
> Key: CASSANDRA-17158
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17158
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0.2, 4.1
>
> Attachments: c17158-blog-post.png
>
>
> [~Calico] advised that [the intro paragraph of the Instana blog post was
> missed|https://the-asf.slack.com/archives/C01RY1LUPD5/p1637144903062900]:
> {quote}Welcome to Inside Cassandra, a new series on the Apache Cassandra
> blog, where we interview engineers and devs in the community either about
> their use of Apache Cassandra to power their businesses or how they
> contribute to the project.
> In our first interview, ...{quote}
> See [Google Doc
> draft|https://docs.google.com/document/d/1eutwlZePuf1-J6W5L1Duo7Yiy4l2TGLjfsFdW7LaF6s/edit?usp=sharing]
> for reference.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated: generated for commit 7324a6f2623dd39d140bf9ad6394bb9208cfb1d6
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
The following commit(s) were added to refs/heads/asf-staging by this push:
new 4ba371d generated for commit 7324a6f2623dd39d140bf9ad6394bb9208cfb1d6
4ba371d is described below
commit 4ba371d968129eca2a7e32fd43ee04c2cf28bb95
Author: mck
AuthorDate: Wed Nov 17 19:06:52 2021 +0100
generated for commit 7324a6f2623dd39d140bf9ad6394bb9208cfb1d6
---
.../inside-Cassandra-Marcel-Birkner/image1.png | Bin 0 -> 226775 bytes
.../inside-Cassandra-Marcel-Birkner/image2.png | Bin 0 -> 190105 bytes
.../inside-Cassandra-Marcel-Birkner/image3.png | Bin 0 -> 232206 bytes
.../inside-Cassandra-Marcel-Birkner/image4.png | Bin 0 -> 106451 bytes
.../inside-Cassandra-Marcel-Birkner/image5.png | Bin 0 -> 255327 bytes
content/_/blog.html| 24 +
...n-interview-with-Marcel-Birkner-at-Instana.html | 358 +
content/search-index.js| 2 +-
content/sitemap-Cassandra.xml | 840 ++---
content/sitemap-_.xml | 126 ++--
10 files changed, 868 insertions(+), 482 deletions(-)
diff --git a/content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image1.png
b/content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image1.png
new file mode 100644
index 000..eda2e6b
Binary files /dev/null and
b/content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image1.png differ
diff --git a/content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image2.png
b/content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image2.png
new file mode 100644
index 000..3848cb5
Binary files /dev/null and
b/content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image2.png differ
diff --git a/content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image3.png
b/content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image3.png
new file mode 100644
index 000..a17f6d9
Binary files /dev/null and
b/content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image3.png differ
diff --git a/content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image4.png
b/content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image4.png
new file mode 100644
index 000..f9dea75
Binary files /dev/null and
b/content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image4.png differ
diff --git a/content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image5.png
b/content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image5.png
new file mode 100644
index 000..94238a3
Binary files /dev/null and
b/content/_/_images/blog/inside-Cassandra-Marcel-Birkner/image5.png differ
diff --git a/content/_/blog.html b/content/_/blog.html
index ea06b10..1a7629c 100644
--- a/content/_/blog.html
+++ b/content/_/blog.html
@@ -185,6 +185,30 @@
+Inside Cassandra: an interview with Marcel Birkner at
Instana
+November 17, 2021
+
+
+
+
+
+We interview Marcel Birkner, Site Reliability Engineer at Instana, how they
use Apache Cassandra to store and process the metric data at scale and benefit
from Cassandra’s fault tolerance, and have learned the importance of
dog-fooding.
+
+
+
+
+Read More
+
+
+
+
+
+
+
+
+
+
+
What the
Future Holds for Apache Cassandra
October 26, 2021
diff --git
a/content/_/blog/Inside-Cassandra-an-interview-with-Marcel-Birkner-at-Instana.html
b/content/_/blog/Inside-Cassandra-an-interview-with-Marcel-Birkner-at-Instana.html
new file mode 100644
index 000..b0ce25b
--- /dev/null
+++
b/content/_/blog/Inside-Cassandra-an-interview-with-Marcel-Birkner-at-Instana.html
@@ -0,0 +1,358 @@
+
+
+
+
+
+Apache Cassandra | Apache Cassandra Documentation
+
+https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,400;0,700;1,400family=Red+Hat+Display:ital,wght@0,400;0,500;0,700;1,400;1,500display=swap;
rel="stylesheet">
+
+
+https://purl.org/dc/terms/;>
+
+
+
+
+
+ const script = document.createElement("script");
+ const domain = window.location.hostname;
+ script.type = "text/javascript";
+ script.src = "https://plausible.cassandra.apache.org/js/plausible.js";;
+ script.setAttribute("data-domain",domain);
+ script.setAttribute("defer",'true');
+ script.setAttribute("async",'true');
+ document.getElementsByTagName("head")[0].appendChild(script);
+
+
+
+https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js";>
+
+
+ https://cassandra.apache.org; />
+
+
+
+
+https://cassandra.apache.org;>
+
+
+
+
+
+Get Started
+
+
+
+
+
+
+
+
[jira] [Commented] (CASSANDRA-16310) Track top partitions (by size and tombstone count) and display in nodetool tablestats
[
https://issues.apache.org/jira/browse/CASSANDRA-16310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445416#comment-17445416
]
Yifan Cai commented on CASSANDRA-16310:
---
+1
Thanks for addressing the prior comment and the recent comments in the PR.
> Track top partitions (by size and tombstone count) and display in nodetool
> tablestats
> -
>
> Key: CASSANDRA-16310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16310
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.x
>
>
> We should track the top partitions by size and tombstone count and display in
> {{nodetool tablestats}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17136) FQL: Enabling via nodetool can trigger disk_failure_mode
[
https://issues.apache.org/jira/browse/CASSANDRA-17136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445415#comment-17445415
]
Brandon Williams commented on CASSANDRA-17136:
--
bq. So the thing that got me to uncover this was that fqltool dump command can
very conveniently create a directory layout just like the one above.
Aha, I see.
bq. looks like we only cleanDirectory when enabling FQL via JMX, so we can
probably just catch the exception and let the user know.
cleanDirectory is what calls the JVMStabilityInspector, so instead I disabled
it when called via JMX.
||Branch||CI||
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-17136]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17136],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1285/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1285/pipeline]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17136]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-17136-trunk],
[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1285/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1286/pipeline]|
> FQL: Enabling via nodetool can trigger disk_failure_mode
>
>
> Key: CASSANDRA-17136
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17136
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/fql
>Reporter: Brendan Cicchi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
>
> When enabling fullquerylog via nodetool, if there is a non empty directory
> present under the location specified via --path which would trigger an
> java.nio.file.AccessDeniedException during cleaning, the node will trigger
> the disk_failure_policy which by default is stop. This is a fairly easy way
> to offline a cluster if someone executes this in parallel. I don't that think
> the behavior is desirable for enabling via nodetool.
>
> Repro (1 node cluster already up):
> {code:bash}
> mkdir /some/path/dir
> touch /some/path/dir/file
> chown -R user: /some/path/dir # Non Cassandra process user
> chmod 700 /some/path/dir
> nodetool enablefullquerylog --path /some/path
> {code}
> Nodetool will give back this error:
> {code:java}
> error: /some/path/dir/file
> -- StackTrace --
> java.nio.file.AccessDeniedException: /some/path/dir/file
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at
> sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
> at
> sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
> at java.nio.file.Files.delete(Files.java:1126)
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:250)
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:237)
> at
> org.apache.cassandra.utils.binlog.BinLog.deleteRecursively(BinLog.java:492)
> at
> org.apache.cassandra.utils.binlog.BinLog.cleanDirectory(BinLog.java:477)
> at
> org.apache.cassandra.utils.binlog.BinLog$Builder.build(BinLog.java:436)
> at
> org.apache.cassandra.fql.FullQueryLogger.enable(FullQueryLogger.java:106)
> at
> org.apache.cassandra.service.StorageService.enableFullQueryLogger(StorageService.java:5915)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:276)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at
[jira] [Commented] (CASSANDRA-17147) Guardrails prototype
[
https://issues.apache.org/jira/browse/CASSANDRA-17147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445397#comment-17445397
]
David Capwell commented on CASSANDRA-17147:
---
moved to 4.x not because I am saying "this doesn't belong into 4.1" but more
that this was not committed, so should use the .x versions
> Guardrails prototype
>
>
> Key: CASSANDRA-17147
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17147
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 7h
> Remaining Estimate: 0h
>
> The purpose of this ticket is creating an initial implementation of the
> guardrails framework, as well as adding a few simple guardrails using this
> framework.
> To keep things easy, this initial implementation would only support
> guardrails that are triggered on the coordinator, and they would be
> dynamically updatable only through JMX.
> Once we have this initial framework ready in a feature branch we can have
> multiple tickets addressing all the things that would have been left out of
> the scope of this ticket, such as:
> * Dynamic updates through virtual tables
> * Being able to notify about guardrails triggered on replicas
> * Using custom exceptions other than {{InvalidRequestException}}.
> * Porting existing limits to use the new guardrails framework
> * Adding new guardrails beyond the initial ones
> The reason for having this simpler prototype is that it will give us a common
> ground to parallelize work on the parts mentioned above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17147) Guardrails prototype
[
https://issues.apache.org/jira/browse/CASSANDRA-17147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-17147:
--
Fix Version/s: 4.x
(was: 4.1)
> Guardrails prototype
>
>
> Key: CASSANDRA-17147
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17147
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 7h
> Remaining Estimate: 0h
>
> The purpose of this ticket is creating an initial implementation of the
> guardrails framework, as well as adding a few simple guardrails using this
> framework.
> To keep things easy, this initial implementation would only support
> guardrails that are triggered on the coordinator, and they would be
> dynamically updatable only through JMX.
> Once we have this initial framework ready in a feature branch we can have
> multiple tickets addressing all the things that would have been left out of
> the scope of this ticket, such as:
> * Dynamic updates through virtual tables
> * Being able to notify about guardrails triggered on replicas
> * Using custom exceptions other than {{InvalidRequestException}}.
> * Porting existing limits to use the new guardrails framework
> * Adding new guardrails beyond the initial ones
> The reason for having this simpler prototype is that it will give us a common
> ground to parallelize work on the parts mentioned above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17072) DebuggableThreadPoolExecutor does not propagate client warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445384#comment-17445384
]
Jacek Lewandowski commented on CASSANDRA-17072:
---
Yup, so can we move forward?
> DebuggableThreadPoolExecutor does not propagate client warnings
> ---
>
> Key: CASSANDRA-17072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17072
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Extracted this as a separate ticket per discussion on CASSANDRA-17044
> The problem is in {{DebuggableThreadPoolExecutor}} - it does not propagate
> executor locals to the thread when tracing is disabled. It is probably
> expected that we propagate the state if at least one executor local is
> defined, but we only check for tracing and completely ignore client warnings.
> The attached PR fixes the problem, adds some tests and reverts a workaround
> for client warnings in some schema alteration statements implemented in
> CASSANDRA-16296 (described below).
>
> h4. Old description - still valid, but this is just a manifestation of the
> problem rather than the problem itself
> This seemed to be screwed a bit. In just two schema alteration statements we
> collect client warnings which are captured during the transformation into a
> local collection.
> I guess it is done that way because the transformation is being executed in a
> different stage (migration) and client warnings collected in that stage are
> not present in the stage where the query is executed.
> Then, the client warnings are retrieved using {{clientWarnings}} method and
> added to the captured client warnings in the stage which is executing the
> query.
> This mechanism was implemented only in two schema alteration statements. It
> is possible that for other ones the client warnings can simply get lost.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17155) Increase the buckets count for timer histogram
[ https://issues.apache.org/jira/browse/CASSANDRA-17155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445357#comment-17445357 ] Caleb Rackliffe commented on CASSANDRA-17155: - +1 on the dtest PR > Increase the buckets count for timer histogram > -- > > Key: CASSANDRA-17155 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17155 > Project: Cassandra > Issue Type: Bug > Components: Observability/Metrics >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > EstimatedHistograms used in timers are allocated with 90 buckets, as part of > CASSANDRA-16760. It can represent the highest value of 25 seconds. The > setting is not free from hitting overflow error when calculating the mean > value from the histogram. We can increase the buckets count to 127 to > increase the upper limit to 21,356 seconds, which just covers the range of > 164 buckets prior CASSANDRA-16760. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17147) Guardrails prototype
[
https://issues.apache.org/jira/browse/CASSANDRA-17147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17147:
Reviewers: David Capwell, Stefan Miklosovic (was: Caleb Rackliffe, David
Capwell)
> Guardrails prototype
>
>
> Key: CASSANDRA-17147
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17147
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> The purpose of this ticket is creating an initial implementation of the
> guardrails framework, as well as adding a few simple guardrails using this
> framework.
> To keep things easy, this initial implementation would only support
> guardrails that are triggered on the coordinator, and they would be
> dynamically updatable only through JMX.
> Once we have this initial framework ready in a feature branch we can have
> multiple tickets addressing all the things that would have been left out of
> the scope of this ticket, such as:
> * Dynamic updates through virtual tables
> * Being able to notify about guardrails triggered on replicas
> * Using custom exceptions other than {{InvalidRequestException}}.
> * Porting existing limits to use the new guardrails framework
> * Adding new guardrails beyond the initial ones
> The reason for having this simpler prototype is that it will give us a common
> ground to parallelize work on the parts mentioned above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17138) Fix circle MID and HIGH for j11_jvm_dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-17138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445326#comment-17445326 ] Brandon Williams commented on CASSANDRA-17138: -- I left a comment on CASSANDRA-16992 about the one unrelated failure. Run times look good, +1. > Fix circle MID and HIGH for j11_jvm_dtests > --- > > Key: CASSANDRA-17138 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17138 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1, 4.0.x > > > Currently these configs have wrong values for MID and HIGH making it take 2h > when it should take around 20m to run. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16992) in-jvm dtest failure: prepareRPCTimeout[PARALLEL/false] - org.apache.cassandra.distributed.test.FullRepairCoordinatorTimeoutTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445322#comment-17445322
]
Brandon Williams commented on CASSANDRA-16992:
--
There is also the same failure in
org.apache.cassandra.distributed.test.IncrementalRepairCoordinatorTimeoutTest:
https://app.circleci.com/pipelines/github/bereng/cassandra/501/workflows/735504ab-58ad-4a27-9a69-6d3094caa1ad/jobs/4483
> in-jvm dtest failure: prepareRPCTimeout[PARALLEL/false] -
> org.apache.cassandra.distributed.test.FullRepairCoordinatorTimeoutTest
>
>
> Key: CASSANDRA-16992
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16992
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Josh McKenzie
>Priority: Normal
>
> Showed up on CASSANDRA-12988 test runs; can't reproduce locally.
> {quote}
> junit.framework.AssertionFailedError: nodetool command [repair,
> distributed_test_keyspace, preparerpctimeout_full_parallel_false, --full]
> Error message 'Got negative replies from endpoints [/127.0.0.2:7012]' does
> not contain any of [Did not get replies from all endpoints.]
> stdout:
> [2021-09-22 17:37:02,187] After waiting for poll interval of 1 seconds
> queried for parent session status and discovered repair failed.
> [2021-09-22 17:37:02,187] Got negative replies from endpoints
> [/127.0.0.2:7012]
> [2021-09-22 17:37:02,187] Repair command #4 finished with error
> stderr:
> error: Got negative replies from endpoints [/127.0.0.2:7012]
> -- StackTrace --
> java.io.IOException: Got negative replies from endpoints [/127.0.0.2:7012]
> at
> org.apache.cassandra.tools.RepairRunner.queryForCompletedRepair(RepairRunner.java:167)
> at org.apache.cassandra.tools.RepairRunner.run(RepairRunner.java:72)
> at org.apache.cassandra.tools.NodeProbe.repairAsync(NodeProbe.java:461)
> at org.apache.cassandra.tools.nodetool.Repair.execute(Repair.java:171)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.runInternal(NodeTool.java:363)
> at
> org.apache.cassandra.tools.NodeTool$NodeToolCmd.run(NodeTool.java:348)
> at org.apache.cassandra.tools.NodeTool.execute(NodeTool.java:251)
> at
> org.apache.cassandra.distributed.impl.Instance$DTestNodeTool.execute(Instance.java:895)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$nodetoolResult$39(Instance.java:805)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17072) DebuggableThreadPoolExecutor does not propagate client warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445266#comment-17445266
]
Andres de la Peña commented on CASSANDRA-17072:
---
CI looks good, so I guess we are ready to commit.
> DebuggableThreadPoolExecutor does not propagate client warnings
> ---
>
> Key: CASSANDRA-17072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17072
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Extracted this as a separate ticket per discussion on CASSANDRA-17044
> The problem is in {{DebuggableThreadPoolExecutor}} - it does not propagate
> executor locals to the thread when tracing is disabled. It is probably
> expected that we propagate the state if at least one executor local is
> defined, but we only check for tracing and completely ignore client warnings.
> The attached PR fixes the problem, adds some tests and reverts a workaround
> for client warnings in some schema alteration statements implemented in
> CASSANDRA-16296 (described below).
>
> h4. Old description - still valid, but this is just a manifestation of the
> problem rather than the problem itself
> This seemed to be screwed a bit. In just two schema alteration statements we
> collect client warnings which are captured during the transformation into a
> local collection.
> I guess it is done that way because the transformation is being executed in a
> different stage (migration) and client warnings collected in that stage are
> not present in the stage where the query is executed.
> Then, the client warnings are retrieved using {{clientWarnings}} method and
> added to the captured client warnings in the stage which is executing the
> query.
> This mechanism was implemented only in two schema alteration statements. It
> is possible that for other ones the client warnings can simply get lost.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17145) utests_system_keyspace_directory failing and not run in Jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-17145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17145: Fix Version/s: 4.0.x 4.x (was: 4.1) > utests_system_keyspace_directory failing and not run in Jenkins > --- > > Key: CASSANDRA-17145 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17145 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0.x, 4.x > > > It seems to me utests_system_keyspace_directory which we run with 4.0 and > trunk in CircleCI do not run in Jenkins as they all fail in trunk now in > CircleCI and nothing in Jenkins. The issue is not environmental and I don't > see that group of tests under Stage View in Jenkins so they are probably not > added there? We need to investigate that further. > CC [~mck] and [~blerer] if they know anything about those - like work in > progress to be added or a reason not to be added. > FYI [~bereng] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17145) utests_system_keyspace_directory failing and not run in Jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-17145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445260#comment-17445260 ] Ekaterina Dimitrova commented on CASSANDRA-17145: - [~bereng], thank you for looking into the failures further to adding the tests in Jenkins but there is a separate ticket for them. CASSANDRA-17137 is assigned by [~blerer] , you might want to check with him if he is already looking into things. Also, I added v 4.0.x series as the tests run there too. > utests_system_keyspace_directory failing and not run in Jenkins > --- > > Key: CASSANDRA-17145 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17145 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1 > > > It seems to me utests_system_keyspace_directory which we run with 4.0 and > trunk in CircleCI do not run in Jenkins as they all fail in trunk now in > CircleCI and nothing in Jenkins. The issue is not environmental and I don't > see that group of tests under Stage View in Jenkins so they are probably not > added there? We need to investigate that further. > CC [~mck] and [~blerer] if they know anything about those - like work in > progress to be added or a reason not to be added. > FYI [~bereng] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17145) utests_system_keyspace_directory failing and not run in Jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-17145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445151#comment-17445151 ] Sam Tunnicliffe commented on CASSANDRA-17145: - [~bereng] that looks right to me, I think it's just a bug in the CASSANDRA-16925 patch. > utests_system_keyspace_directory failing and not run in Jenkins > --- > > Key: CASSANDRA-17145 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17145 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1 > > > It seems to me utests_system_keyspace_directory which we run with 4.0 and > trunk in CircleCI do not run in Jenkins as they all fail in trunk now in > CircleCI and nothing in Jenkins. The issue is not environmental and I don't > see that group of tests under Stage View in Jenkins so they are probably not > added there? We need to investigate that further. > CC [~mck] and [~blerer] if they know anything about those - like work in > progress to be added or a reason not to be added. > FYI [~bereng] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17158) BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
[
https://issues.apache.org/jira/browse/CASSANDRA-17158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17158:
--
Reviewers: Benjamin Lerer, Erick Ramirez, Michael Semb Wever (was: Erick
Ramirez)
> BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
> -
>
> Key: CASSANDRA-17158
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17158
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: c17158-blog-post.png
>
>
> [~Calico] advised that [the intro paragraph of the Instana blog post was
> missed|https://the-asf.slack.com/archives/C01RY1LUPD5/p1637144903062900]:
> {quote}Welcome to Inside Cassandra, a new series on the Apache Cassandra
> blog, where we interview engineers and devs in the community either about
> their use of Apache Cassandra to power their businesses or how they
> contribute to the project.
> In our first interview, ...{quote}
> See [Google Doc
> draft|https://docs.google.com/document/d/1eutwlZePuf1-J6W5L1Duo7Yiy4l2TGLjfsFdW7LaF6s/edit?usp=sharing]
> for reference.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17158) BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
[
https://issues.apache.org/jira/browse/CASSANDRA-17158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445131#comment-17445131
]
Erick Ramirez commented on CASSANDRA-17158:
---
Update staged successfully:
!c17158-blog-post.png|width=300!
> BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
> -
>
> Key: CASSANDRA-17158
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17158
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: c17158-blog-post.png
>
>
> [~Calico] advised that [the intro paragraph of the Instana blog post was
> missed|https://the-asf.slack.com/archives/C01RY1LUPD5/p1637144903062900]:
> {quote}Welcome to Inside Cassandra, a new series on the Apache Cassandra
> blog, where we interview engineers and devs in the community either about
> their use of Apache Cassandra to power their businesses or how they
> contribute to the project.
> In our first interview, ...{quote}
> See [Google Doc
> draft|https://docs.google.com/document/d/1eutwlZePuf1-J6W5L1Duo7Yiy4l2TGLjfsFdW7LaF6s/edit?usp=sharing]
> for reference.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17158) BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
[
https://issues.apache.org/jira/browse/CASSANDRA-17158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17158:
--
Status: Ready to Commit (was: Review In Progress)
> BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
> -
>
> Key: CASSANDRA-17158
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17158
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: c17158-blog-post.png
>
>
> [~Calico] advised that [the intro paragraph of the Instana blog post was
> missed|https://the-asf.slack.com/archives/C01RY1LUPD5/p1637144903062900]:
> {quote}Welcome to Inside Cassandra, a new series on the Apache Cassandra
> blog, where we interview engineers and devs in the community either about
> their use of Apache Cassandra to power their businesses or how they
> contribute to the project.
> In our first interview, ...{quote}
> See [Google Doc
> draft|https://docs.google.com/document/d/1eutwlZePuf1-J6W5L1Duo7Yiy4l2TGLjfsFdW7LaF6s/edit?usp=sharing]
> for reference.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17158) BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
[
https://issues.apache.org/jira/browse/CASSANDRA-17158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17158:
--
Reviewers: Erick Ramirez
Status: Review In Progress (was: Patch Available)
> BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
> -
>
> Key: CASSANDRA-17158
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17158
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: c17158-blog-post.png
>
>
> [~Calico] advised that [the intro paragraph of the Instana blog post was
> missed|https://the-asf.slack.com/archives/C01RY1LUPD5/p1637144903062900]:
> {quote}Welcome to Inside Cassandra, a new series on the Apache Cassandra
> blog, where we interview engineers and devs in the community either about
> their use of Apache Cassandra to power their businesses or how they
> contribute to the project.
> In our first interview, ...{quote}
> See [Google Doc
> draft|https://docs.google.com/document/d/1eutwlZePuf1-J6W5L1Duo7Yiy4l2TGLjfsFdW7LaF6s/edit?usp=sharing]
> for reference.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17158) BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
[
https://issues.apache.org/jira/browse/CASSANDRA-17158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445130#comment-17445130
]
Erick Ramirez edited comment on CASSANDRA-17158 at 11/17/21, 12:18 PM:
---
Submitted [PR #82|https://github.com/apache/cassandra-website/pull/82].
was (Author: flightc):
Submitted PR #82.
> BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
> -
>
> Key: CASSANDRA-17158
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17158
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: c17158-blog-post.png
>
>
> [~Calico] advised that [the intro paragraph of the Instana blog post was
> missed|https://the-asf.slack.com/archives/C01RY1LUPD5/p1637144903062900]:
> {quote}Welcome to Inside Cassandra, a new series on the Apache Cassandra
> blog, where we interview engineers and devs in the community either about
> their use of Apache Cassandra to power their businesses or how they
> contribute to the project.
> In our first interview, ...{quote}
> See [Google Doc
> draft|https://docs.google.com/document/d/1eutwlZePuf1-J6W5L1Duo7Yiy4l2TGLjfsFdW7LaF6s/edit?usp=sharing]
> for reference.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17158) BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
[
https://issues.apache.org/jira/browse/CASSANDRA-17158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17158:
--
Test and Documentation Plan: Stage update
Status: Patch Available (was: In Progress)
Submitted PR #82.
> BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
> -
>
> Key: CASSANDRA-17158
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17158
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: c17158-blog-post.png
>
>
> [~Calico] advised that [the intro paragraph of the Instana blog post was
> missed|https://the-asf.slack.com/archives/C01RY1LUPD5/p1637144903062900]:
> {quote}Welcome to Inside Cassandra, a new series on the Apache Cassandra
> blog, where we interview engineers and devs in the community either about
> their use of Apache Cassandra to power their businesses or how they
> contribute to the project.
> In our first interview, ...{quote}
> See [Google Doc
> draft|https://docs.google.com/document/d/1eutwlZePuf1-J6W5L1Duo7Yiy4l2TGLjfsFdW7LaF6s/edit?usp=sharing]
> for reference.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17158) BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
[
https://issues.apache.org/jira/browse/CASSANDRA-17158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17158:
--
Attachment: c17158-blog-post.png
> BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
> -
>
> Key: CASSANDRA-17158
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17158
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: c17158-blog-post.png
>
>
> [~Calico] advised that [the intro paragraph of the Instana blog post was
> missed|https://the-asf.slack.com/archives/C01RY1LUPD5/p1637144903062900]:
> {quote}Welcome to Inside Cassandra, a new series on the Apache Cassandra
> blog, where we interview engineers and devs in the community either about
> their use of Apache Cassandra to power their businesses or how they
> contribute to the project.
> In our first interview, ...{quote}
> See [Google Doc
> draft|https://docs.google.com/document/d/1eutwlZePuf1-J6W5L1Duo7Yiy4l2TGLjfsFdW7LaF6s/edit?usp=sharing]
> for reference.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17158) BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
[
https://issues.apache.org/jira/browse/CASSANDRA-17158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17158:
--
Change Category: Semantic
Complexity: Normal
Component/s: Documentation/Blog
Fix Version/s: 4.0.x
Status: Open (was: Triage Needed)
> BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
> -
>
> Key: CASSANDRA-17158
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17158
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.x
>
>
> [~Calico] advised that [the intro paragraph of the Instana blog post was
> missed|https://the-asf.slack.com/archives/C01RY1LUPD5/p1637144903062900]:
> {quote}Welcome to Inside Cassandra, a new series on the Apache Cassandra
> blog, where we interview engineers and devs in the community either about
> their use of Apache Cassandra to power their businesses or how they
> contribute to the project.
> In our first interview, ...{quote}
> See [Google Doc
> draft|https://docs.google.com/document/d/1eutwlZePuf1-J6W5L1Duo7Yiy4l2TGLjfsFdW7LaF6s/edit?usp=sharing]
> for reference.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17158) BLOG - Update intro paragraph of interview with Marcel Birkner at Instana
Erick Ramirez created CASSANDRA-17158:
-
Summary: BLOG - Update intro paragraph of interview with Marcel
Birkner at Instana
Key: CASSANDRA-17158
URL: https://issues.apache.org/jira/browse/CASSANDRA-17158
Project: Cassandra
Issue Type: Task
Reporter: Erick Ramirez
Assignee: Erick Ramirez
[~Calico] advised that [the intro paragraph of the Instana blog post was
missed|https://the-asf.slack.com/archives/C01RY1LUPD5/p1637144903062900]:
{quote}Welcome to Inside Cassandra, a new series on the Apache Cassandra blog,
where we interview engineers and devs in the community either about their use
of Apache Cassandra to power their businesses or how they contribute to the
project.
In our first interview, ...{quote}
See [Google Doc
draft|https://docs.google.com/document/d/1eutwlZePuf1-J6W5L1Duo7Yiy4l2TGLjfsFdW7LaF6s/edit?usp=sharing]
for reference.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17072) DebuggableThreadPoolExecutor does not propagate client warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445112#comment-17445112
]
Jacek Lewandowski commented on CASSANDRA-17072:
---
trunk tests passed, I could not reproduce locally two failures on 4.0
> DebuggableThreadPoolExecutor does not propagate client warnings
> ---
>
> Key: CASSANDRA-17072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17072
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Extracted this as a separate ticket per discussion on CASSANDRA-17044
> The problem is in {{DebuggableThreadPoolExecutor}} - it does not propagate
> executor locals to the thread when tracing is disabled. It is probably
> expected that we propagate the state if at least one executor local is
> defined, but we only check for tracing and completely ignore client warnings.
> The attached PR fixes the problem, adds some tests and reverts a workaround
> for client warnings in some schema alteration statements implemented in
> CASSANDRA-16296 (described below).
>
> h4. Old description - still valid, but this is just a manifestation of the
> problem rather than the problem itself
> This seemed to be screwed a bit. In just two schema alteration statements we
> collect client warnings which are captured during the transformation into a
> local collection.
> I guess it is done that way because the transformation is being executed in a
> different stage (migration) and client warnings collected in that stage are
> not present in the stage where the query is executed.
> Then, the client warnings are retrieved using {{clientWarnings}} method and
> added to the captured client warnings in the stage which is executing the
> query.
> This mechanism was implemented only in two schema alteration statements. It
> is possible that for other ones the client warnings can simply get lost.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17145) utests_system_keyspace_directory failing and not run in Jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-17145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445100#comment-17445100
]
Berenguer Blasi edited comment on CASSANDRA-17145 at 11/17/21, 10:58 AM:
-
[~samt] I need to pick your brain here for a test failure introduced by CEP-10
which should be quick for you to asses (I hope) bc that PR is massive.
As you can see
[here|https://app.circleci.com/pipelines/github/bereng/cassandra/502/workflows/f5880a6d-4742-4607-9294-cac78dd36f11/jobs/4561/steps]
these tests started failing in trunk. Drilling a bit I found the culprit being
[this
line|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L2877]
in 4.0 using {{numberOfExecutors}} in the loop whereas trunk
[here|https://github.com/apache/cassandra/blame/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L2944]
using {{DatabaseDescriptor.getAllDataFileLocations().length}}. This produces
the following error in 500+ tests:
{noformat}
[junit-timeout] java.lang.ExceptionInInitializerError
[junit-timeout] at
org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:472)
[junit-timeout] at
org.apache.cassandra.db.Keyspace.(Keyspace.java:366)
[junit-timeout] at
org.apache.cassandra.db.Keyspace.open(Keyspace.java:154)
[junit-timeout] at
org.apache.cassandra.db.Keyspace.open(Keyspace.java:130)
[junit-timeout] at
org.apache.cassandra.db.Keyspace.openAndGetStore(Keyspace.java:189)
[junit-timeout] at
org.apache.cassandra.index.IndexRegistry.obtain(IndexRegistry.java:251)
[junit-timeout] at
org.apache.cassandra.db.partitions.PartitionUpdate.validateIndexedColumns(PartitionUpdate.java:473)
[junit-timeout] at
org.apache.cassandra.db.IMutation.validateIndexedColumns(IMutation.java:42)
[junit-timeout] at
org.apache.cassandra.cql3.statements.SingleTableUpdatesCollector.toMutations(SingleTableUpdatesCollector.java:107)
[junit-timeout] at
org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:690)
[junit-timeout] at
org.apache.cassandra.cql3.statements.ModificationStatement.executeInternalWithoutCondition(ModificationStatement.java:633)
[junit-timeout] at
org.apache.cassandra.cql3.statements.ModificationStatement.executeLocally(ModificationStatement.java:625)
[junit-timeout] at
org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:453)
[junit-timeout] at
org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:435)
[junit-timeout] at
org.apache.cassandra.db.SystemKeyspace.persistLocalMetadata(SystemKeyspace.java:491)
[junit-timeout] at
org.apache.cassandra.ServerTestUtils.prepareServer(ServerTestUtils.java:129)
[junit-timeout] at
org.apache.cassandra.cql3.CQLTester.prepareServer(CQLTester.java:263)
[junit-timeout] at
org.apache.cassandra.cql3.CQLTester.setUpClass(CQLTester.java:311)
[junit-timeout] Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
[junit-timeout] at
org.apache.cassandra.db.ColumnFamilyStore$PerDiskFlushExecutors.createPerDiskFlushWriters(ColumnFamilyStore.java:2946)
[junit-timeout] at
org.apache.cassandra.db.ColumnFamilyStore$PerDiskFlushExecutors.(ColumnFamilyStore.java:2934)
[junit-timeout] at
org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:148)
{noformat}
Changing it back to {{numberOfExecutors}} seems to fix the problem and seems
correct at face value without knowing anything on CEP-10 implementation
details. Can you confirm the fix is good please?
was (Author: bereng):
[~samt] I need to pick your brain here for a test failure introduced by CEP-10
which should be quick for you to asses (I hope) bc that PR is massive.
As you can see
[here|https://app.circleci.com/pipelines/github/bereng/cassandra/502/workflows/f5880a6d-4742-4607-9294-cac78dd36f11/jobs/4561/steps]
these tests started failing in trunk. Drilling a bit I found the culprit being
[this
line|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L2877]
in 4.0 using {{numberOfExecutors}} in the loop whereas trunk
[here|https://github.com/apache/cassandra/blame/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L2944]
using {{DatabaseDescriptor.getAllDataFileLocations().length}}. This produces
the following error in 500+ tests:
{noformat}
[junit-timeout] java.lang.ExceptionInInitializerError
[junit-timeout] at
org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:472)
[junit-timeout] at
org.apache.cassandra.db.Keyspace.(Keyspace.java:366)
[junit-timeout] at
org.apache.cassandra.db.Keyspace.open(Keyspace.java:154)
[junit-timeout] at
[jira] [Comment Edited] (CASSANDRA-17145) utests_system_keyspace_directory failing and not run in Jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-17145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445100#comment-17445100
]
Berenguer Blasi edited comment on CASSANDRA-17145 at 11/17/21, 10:57 AM:
-
[~samt] I need to pick your brain here for a test failure introduced by CEP-10
which should be quick for you to asses (I hope) bc that PR is massive.
As you can see
[here|https://app.circleci.com/pipelines/github/bereng/cassandra/502/workflows/f5880a6d-4742-4607-9294-cac78dd36f11/jobs/4561/steps]
these tests started failing in trunk. Drilling a bit I found the culprit being
[this
line|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L2877]
in 4.0 using {{numberOfExecutors}} in the loop whereas trunk
[here|https://github.com/apache/cassandra/blame/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L2944]
using {{DatabaseDescriptor.getAllDataFileLocations().length}}. This produces
the following error in 500+ tests:
{noformat}
[junit-timeout] java.lang.ExceptionInInitializerError
[junit-timeout] at
org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:472)
[junit-timeout] at
org.apache.cassandra.db.Keyspace.(Keyspace.java:366)
[junit-timeout] at
org.apache.cassandra.db.Keyspace.open(Keyspace.java:154)
[junit-timeout] at
org.apache.cassandra.db.Keyspace.open(Keyspace.java:130)
[junit-timeout] at
org.apache.cassandra.db.Keyspace.openAndGetStore(Keyspace.java:189)
[junit-timeout] at
org.apache.cassandra.index.IndexRegistry.obtain(IndexRegistry.java:251)
[junit-timeout] at
org.apache.cassandra.db.partitions.PartitionUpdate.validateIndexedColumns(PartitionUpdate.java:473)
[junit-timeout] at
org.apache.cassandra.db.IMutation.validateIndexedColumns(IMutation.java:42)
[junit-timeout] at
org.apache.cassandra.cql3.statements.SingleTableUpdatesCollector.toMutations(SingleTableUpdatesCollector.java:107)
[junit-timeout] at
org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:690)
[junit-timeout] at
org.apache.cassandra.cql3.statements.ModificationStatement.executeInternalWithoutCondition(ModificationStatement.java:633)
[junit-timeout] at
org.apache.cassandra.cql3.statements.ModificationStatement.executeLocally(ModificationStatement.java:625)
[junit-timeout] at
org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:453)
[junit-timeout] at
org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:435)
[junit-timeout] at
org.apache.cassandra.db.SystemKeyspace.persistLocalMetadata(SystemKeyspace.java:491)
[junit-timeout] at
org.apache.cassandra.ServerTestUtils.prepareServer(ServerTestUtils.java:129)
[junit-timeout] at
org.apache.cassandra.cql3.CQLTester.prepareServer(CQLTester.java:263)
[junit-timeout] at
org.apache.cassandra.cql3.CQLTester.setUpClass(CQLTester.java:311)
[junit-timeout] Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
[junit-timeout] at
org.apache.cassandra.db.ColumnFamilyStore$PerDiskFlushExecutors.createPerDiskFlushWriters(ColumnFamilyStore.java:2946)
[junit-timeout] at
org.apache.cassandra.db.ColumnFamilyStore$PerDiskFlushExecutors.(ColumnFamilyStore.java:2934)
[junit-timeout] at
org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:148)
{noformat}
Changing it back to {{numberOfExecutors}} seems to fix the problem and seems
correct at face value without knowing anything on CEP-10 implementation
details. Can you confirm the check is good please?
was (Author: bereng):
[~samt] I need to pick your brain here for a test failure introduced by CEP-10
which should be quick for you to asses (I hope) bc that PR is massive.
As you can see
[here|https://app.circleci.com/pipelines/github/bereng/cassandra/502/workflows/f5880a6d-4742-4607-9294-cac78dd36f11/jobs/4561/steps]
these tests started failing. Drilling a bit I found the culprit being [this
line|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L2877]
in 4.0 using {{numberOfExecutors}} in the loop whereas trunk
[here|https://github.com/apache/cassandra/blame/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L2944]
using {{DatabaseDescriptor.getAllDataFileLocations().length}}. This produces
the following error in 500+ tests:
{noformat}
[junit-timeout] java.lang.ExceptionInInitializerError
[junit-timeout] at
org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:472)
[junit-timeout] at
org.apache.cassandra.db.Keyspace.(Keyspace.java:366)
[junit-timeout] at
org.apache.cassandra.db.Keyspace.open(Keyspace.java:154)
[junit-timeout] at
[jira] [Commented] (CASSANDRA-17145) utests_system_keyspace_directory failing and not run in Jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-17145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445100#comment-17445100
]
Berenguer Blasi commented on CASSANDRA-17145:
-
[~samt] I need to pick your brain here for a test failure introduced by CEP-10
which should be quick for you to asses (I hope) bc that PR is massive.
As you can see
[here|https://app.circleci.com/pipelines/github/bereng/cassandra/502/workflows/f5880a6d-4742-4607-9294-cac78dd36f11/jobs/4561/steps]
these tests started failing. Drilling a bit I found the culprit being [this
line|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L2877]
in 4.0 using {{numberOfExecutors}} in the loop whereas trunk
[here|https://github.com/apache/cassandra/blame/trunk/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L2944]
using {{DatabaseDescriptor.getAllDataFileLocations().length}}. This produces
the following error in 500+ tests:
{noformat}
[junit-timeout] java.lang.ExceptionInInitializerError
[junit-timeout] at
org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:472)
[junit-timeout] at
org.apache.cassandra.db.Keyspace.(Keyspace.java:366)
[junit-timeout] at
org.apache.cassandra.db.Keyspace.open(Keyspace.java:154)
[junit-timeout] at
org.apache.cassandra.db.Keyspace.open(Keyspace.java:130)
[junit-timeout] at
org.apache.cassandra.db.Keyspace.openAndGetStore(Keyspace.java:189)
[junit-timeout] at
org.apache.cassandra.index.IndexRegistry.obtain(IndexRegistry.java:251)
[junit-timeout] at
org.apache.cassandra.db.partitions.PartitionUpdate.validateIndexedColumns(PartitionUpdate.java:473)
[junit-timeout] at
org.apache.cassandra.db.IMutation.validateIndexedColumns(IMutation.java:42)
[junit-timeout] at
org.apache.cassandra.cql3.statements.SingleTableUpdatesCollector.toMutations(SingleTableUpdatesCollector.java:107)
[junit-timeout] at
org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:690)
[junit-timeout] at
org.apache.cassandra.cql3.statements.ModificationStatement.executeInternalWithoutCondition(ModificationStatement.java:633)
[junit-timeout] at
org.apache.cassandra.cql3.statements.ModificationStatement.executeLocally(ModificationStatement.java:625)
[junit-timeout] at
org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:453)
[junit-timeout] at
org.apache.cassandra.cql3.QueryProcessor.executeOnceInternal(QueryProcessor.java:435)
[junit-timeout] at
org.apache.cassandra.db.SystemKeyspace.persistLocalMetadata(SystemKeyspace.java:491)
[junit-timeout] at
org.apache.cassandra.ServerTestUtils.prepareServer(ServerTestUtils.java:129)
[junit-timeout] at
org.apache.cassandra.cql3.CQLTester.prepareServer(CQLTester.java:263)
[junit-timeout] at
org.apache.cassandra.cql3.CQLTester.setUpClass(CQLTester.java:311)
[junit-timeout] Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
[junit-timeout] at
org.apache.cassandra.db.ColumnFamilyStore$PerDiskFlushExecutors.createPerDiskFlushWriters(ColumnFamilyStore.java:2946)
[junit-timeout] at
org.apache.cassandra.db.ColumnFamilyStore$PerDiskFlushExecutors.(ColumnFamilyStore.java:2934)
[junit-timeout] at
org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:148)
{noformat}
Changing that seems to fix the problem and seems correct at face value without
knowing anything on CEP-10 implementation details. Can you confirm the check is
good please?
> utests_system_keyspace_directory failing and not run in Jenkins
> ---
>
> Key: CASSANDRA-17145
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17145
> Project: Cassandra
> Issue Type: Improvement
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1
>
>
> It seems to me utests_system_keyspace_directory which we run with 4.0 and
> trunk in CircleCI do not run in Jenkins as they all fail in trunk now in
> CircleCI and nothing in Jenkins. The issue is not environmental and I don't
> see that group of tests under Stage View in Jenkins so they are probably not
> added there? We need to investigate that further.
> CC [~mck] and [~blerer] if they know anything about those - like work in
> progress to be added or a reason not to be added.
> FYI [~bereng]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17145) utests_system_keyspace_directory failing and not run in Jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-17145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi reassigned CASSANDRA-17145: --- Assignee: Berenguer Blasi > utests_system_keyspace_directory failing and not run in Jenkins > --- > > Key: CASSANDRA-17145 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17145 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Berenguer Blasi >Priority: Normal > > It seems to me utests_system_keyspace_directory which we run with 4.0 and > trunk in CircleCI do not run in Jenkins as they all fail in trunk now in > CircleCI and nothing in Jenkins. The issue is not environmental and I don't > see that group of tests under Stage View in Jenkins so they are probably not > added there? We need to investigate that further. > CC [~mck] and [~blerer] if they know anything about those - like work in > progress to be added or a reason not to be added. > FYI [~bereng] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17145) utests_system_keyspace_directory failing and not run in Jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-17145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17145: Fix Version/s: 4.1 > utests_system_keyspace_directory failing and not run in Jenkins > --- > > Key: CASSANDRA-17145 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17145 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1 > > > It seems to me utests_system_keyspace_directory which we run with 4.0 and > trunk in CircleCI do not run in Jenkins as they all fail in trunk now in > CircleCI and nothing in Jenkins. The issue is not environmental and I don't > see that group of tests under Stage View in Jenkins so they are probably not > added there? We need to investigate that further. > CC [~mck] and [~blerer] if they know anything about those - like work in > progress to be added or a reason not to be added. > FYI [~bereng] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17145) utests_system_keyspace_directory failing and not run in Jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-17145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17145: Summary: utests_system_keyspace_directory failing and not run in Jenkins (was: utests_system_keyspace_directory not run in Jenkins) > utests_system_keyspace_directory failing and not run in Jenkins > --- > > Key: CASSANDRA-17145 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17145 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > > It seems to me utests_system_keyspace_directory which we run with 4.0 and > trunk in CircleCI do not run in Jenkins as they all fail in trunk now in > CircleCI and nothing in Jenkins. The issue is not environmental and I don't > see that group of tests under Stage View in Jenkins so they are probably not > added there? We need to investigate that further. > CC [~mck] and [~blerer] if they know anything about those - like work in > progress to be added or a reason not to be added. > FYI [~bereng] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16917) Create property to hold local maven repository location
[
https://issues.apache.org/jira/browse/CASSANDRA-16917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16917:
---
Fix Version/s: 3.0.26
3.11.12
4.0.2
4.1
(was: 3.0.x)
(was: 4.x)
(was: 3.11.x)
(was: 4.0.x)
Source Control Link:
https://github.com/apache/cassandra/commit/44d81b5d09147fa2de505b4f03bcaa2e9017a9b2
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[44d81b5d09147fa2de505b4f03bcaa2e9017a9b2|https://github.com/apache/cassandra/commit/44d81b5d09147fa2de505b4f03bcaa2e9017a9b2].
> Create property to hold local maven repository location
> ---
>
> Key: CASSANDRA-16917
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16917
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2, 4.1
>
>
> In their current state, both build.xml and .build/build-resolver.xml refer to
> the local maven repository by "${user.home}/.m2/repository" in multiple
> places.
> It would be nice instead to have a property store this location, and refer
> the property vs the actual location itself.
> If one needs to change this maven repository location for their environmental
> purposes, this change makes it easy since it will need to be changed only at
> one place (the value of the property) vs changing all the direct references
> to the repository location.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit cd73c14cec6417a100e2f667671eef2f485a34ea Merge: 40f4fe7 44d81b5 Author: Mick Semb Wever AuthorDate: Wed Nov 17 10:27:31 2021 +0100 Merge branch 'cassandra-3.0' into cassandra-3.11 .build/build-resolver.xml | 66 +++ build.xml | 4 ++- 2 files changed, 36 insertions(+), 34 deletions(-) diff --cc .build/build-resolver.xml index 02722f8,de98eed..698fb57 --- a/.build/build-resolver.xml +++ b/.build/build-resolver.xml @@@ -21,12 -21,8 +21,12 @@@ - + https://repo1.maven.org/maven2/org/apache/maven/resolver/maven-resolver-ant-tasks; /> + + + + @@@ -151,9 -143,8 +151,9 @@@ + - + - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated: Create property for local repository
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
new 44d81b5 Create property for local repository
44d81b5 is described below
commit 44d81b5d09147fa2de505b4f03bcaa2e9017a9b2
Author: Sumanth Pasupuleti
AuthorDate: Fri Sep 3 11:03:41 2021 -0700
Create property for local repository
patch by Sumanth Pasupuleti; reviewed by Mick Semb Wever for
CASSANDRA-16917
---
.build/build-resolver.xml | 66 +++
build.xml | 4 ++-
2 files changed, 36 insertions(+), 34 deletions(-)
diff --git a/.build/build-resolver.xml b/.build/build-resolver.xml
index 8a413bf..de98eed 100644
--- a/.build/build-resolver.xml
+++ b/.build/build-resolver.xml
@@ -21,7 +21,7 @@
-
+
https://repo1.maven.org/maven2/org/apache/maven/resolver/maven-resolver-ant-tasks;
/>
@@ -38,7 +38,7 @@
Downloading Resolver ANT Tasks...
-
+
@@ -144,7 +144,7 @@
-
+
@@ -165,18 +165,18 @@
-
+
-https://files.pythonhosted.org/packages/59/a0/cf4cd997e1750f0c2d91c6ea5abea218251c43c3581bcc2f118b00baf5cf/futures-2.1.6-py2.py3-none-any.whl;
dest="${user.home}/.m2/repository/org/apache/cassandra/deps/futures-2.1.6-py2.py3-none-any.zip"
usetimestamp="true" quiet="true" skipexisting="true"/>
-https://files.pythonhosted.org/packages/2e/a4/6dcb84af409b7bc0c258a0d6bd7e14231724d9a46b750c048f09d74d870c/six-1.7.3-py2.py3-none-any.whl;
dest="${user.home}/.m2/repository/org/apache/cassandra/deps/six-1.7.3-py2.py3-none-any.zip"
usetimestamp="true" quiet="true" skipexisting="true"/>
+https://files.pythonhosted.org/packages/59/a0/cf4cd997e1750f0c2d91c6ea5abea218251c43c3581bcc2f118b00baf5cf/futures-2.1.6-py2.py3-none-any.whl;
dest="${local.repository}/org/apache/cassandra/deps/futures-2.1.6-py2.py3-none-any.zip"
usetimestamp="true" quiet="true" skipexisting="true"/>
+https://files.pythonhosted.org/packages/2e/a4/6dcb84af409b7bc0c258a0d6bd7e14231724d9a46b750c048f09d74d870c/six-1.7.3-py2.py3-none-any.whl;
dest="${local.repository}/org/apache/cassandra/deps/six-1.7.3-py2.py3-none-any.zip"
usetimestamp="true" quiet="true" skipexisting="true"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/cassandra-driver-internal-only-3.11.0-bb96859b.zip;
dest="${user.home}/.m2/repository/org/apache/cassandra/deps/cassandra-driver-internal-only-3.11.0-bb96859b.zip"
usetimestamp="true" quiet="true" skipexisting="true"/>
+https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/cassandra-driver-internal-only-3.11.0-bb96859b.zip;
dest="${local.repository}/org/apache/cassandra/deps/cassandra-driver-internal-only-3.11.0-bb96859b.zip"
usetimestamp="true" quiet="true" skipexisting="true"/>
-
+
https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-amd64-freebsd-6.so"/>
https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-amd64-linux.so"/>
https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-amd64-solaris.so"/>
@@ -202,33 +202,33 @@
-
-
-
+
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/build.xml b/build.xml
index 7cc0693..b42c8ea 100644
--- a/build.xml
+++ b/build.xml
@@ -78,9 +78,11 @@
value="${build.src.resources}/org/apache/cassandra/config/" />
+
+
-
+
https://repo.maven.apache.org/maven2/org/apache/maven/maven-ant-tasks; />
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 3f2066d15088e08935ae9de436c77f285c07d325
Merge: 44ace88 cd73c14
Author: Mick Semb Wever
AuthorDate: Wed Nov 17 10:42:05 2021 +0100
Merge branch 'cassandra-3.11' into cassandra-4.0
.build/build-resolver.xml | 68 +++
build.xml | 4 ++-
2 files changed, 37 insertions(+), 35 deletions(-)
diff --cc .build/build-resolver.xml
index 888f4b9,698fb57..03db1c8
--- a/.build/build-resolver.xml
+++ b/.build/build-resolver.xml
@@@ -22,8 -21,12 +22,8 @@@
-
+
https://repo1.maven.org/maven2/org/apache/maven/resolver/maven-resolver-ant-tasks;
/>
-
-
-
-
@@@ -187,76 -162,82 +187,76 @@@
-
+
-
-
+
-
-
-
-
-
-
+
-
+
-
-
-https://files.pythonhosted.org/packages/59/a0/cf4cd997e1750f0c2d91c6ea5abea218251c43c3581bcc2f118b00baf5cf/futures-2.1.6-py2.py3-none-any.whl;
dest="${local.repository}/org/apache/cassandra/deps/futures-2.1.6-py2.py3-none-any.zip"
usetimestamp="true" quiet="true" skipexisting="true"/>
-https://files.pythonhosted.org/packages/2e/a4/6dcb84af409b7bc0c258a0d6bd7e14231724d9a46b750c048f09d74d870c/six-1.7.3-py2.py3-none-any.whl;
dest="${local.repository}/org/apache/cassandra/deps/six-1.7.3-py2.py3-none-any.zip"
usetimestamp="true" quiet="true" skipexisting="true"/>
-
-
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/cassandra-driver-internal-only-3.11.0-bb96859b.zip;
dest="${local.repository}/org/apache/cassandra/deps/cassandra-driver-internal-only-3.11.0-bb96859b.zip"
usetimestamp="true" quiet="true" skipexisting="true"/>
++
++
-
-
++
+
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-amd64-freebsd-6.so"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-amd64-linux.so"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-amd64-solaris.so"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-ia64-hpux-11.sl"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-ia64-linux.so"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-pa-hpux-11.sl"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-ppc-aix-5.so"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-ppc-linux.so"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-ppc64-aix-5.so"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-ppc64-linux.so"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-s390x-linux.so"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-sparc-solaris.so"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-sparc64-solaris.so"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-universal-macosx.dylib"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-universal64-macosx.dylib"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-x86-freebsd-5.so"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-x86-freebsd-6.so"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-x86-linux.so"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/libsigar-x86-solaris.so"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/sigar-amd64-winnt.dll"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/sigar-x86-winnt.dll"/>
-https://raw.githubusercontent.com/apache/cassandra/${lib.download.sha}/lib/sigar-bin/sigar-x86-winnt.lib"/>
+
+
+
+
[cassandra] branch cassandra-4.0 updated (44ace88 -> 3f2066d)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 44ace88 internode_send_buff_size_in_bytes and internode_recv_buff_size_in_bytes have new names. Backward compatibility with the old names added patch by Ekaterina Dimitrova; reviewed by David Capwell for CASSANDRA-17141 new 44d81b5 Create property for local repository new cd73c14 Merge branch 'cassandra-3.0' into cassandra-3.11 new 3f2066d Merge branch 'cassandra-3.11' into cassandra-4.0 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .build/build-resolver.xml | 68 +++ build.xml | 4 ++- 2 files changed, 37 insertions(+), 35 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (1c79c68 -> a6cfd64)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 1c79c68 Fix test distributed.test.trackwarnings.TombstoneWarningTest new 44d81b5 Create property for local repository new cd73c14 Merge branch 'cassandra-3.0' into cassandra-3.11 new 3f2066d Merge branch 'cassandra-3.11' into cassandra-4.0 new a6cfd64 Merge branch 'cassandra-4.0' into trunk The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .build/build-resolver.xml | 68 +++ build.xml | 4 ++- 2 files changed, 37 insertions(+), 35 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit a6cfd64bee636ab6ba2017d535d6324f742bb25f Merge: 1c79c68 3f2066d Author: Mick Semb Wever AuthorDate: Wed Nov 17 10:56:24 2021 +0100 Merge branch 'cassandra-4.0' into trunk .build/build-resolver.xml | 68 +++ build.xml | 4 ++- 2 files changed, 37 insertions(+), 35 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (40f4fe7 -> cd73c14)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 40f4fe7 Merge branch 'cassandra-3.0' into cassandra-3.11 new 44d81b5 Create property for local repository new cd73c14 Merge branch 'cassandra-3.0' into cassandra-3.11 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .build/build-resolver.xml | 66 +++ build.xml | 4 ++- 2 files changed, 36 insertions(+), 34 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17138) Fix circle MID and HIGH for j11_jvm_dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-17138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17445051#comment-17445051 ] Berenguer Blasi commented on CASSANDRA-17138: - Ah yeah the good trick of 'moving' the ticket from bug to improvement +1: - Pre 4.0 we are good, correct. - I have added MID and HIGH CI runs to both 4.0 and trunk just to be on the safe side. - Trunk ci files are just a copy of the 4.0 ones. Up for final review and hopefully merge. > Fix circle MID and HIGH for j11_jvm_dtests > --- > > Key: CASSANDRA-17138 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17138 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1, 4.0.x > > > Currently these configs have wrong values for MID and HIGH making it take 2h > when it should take around 20m to run. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
