[cassandra-website] branch asf-staging updated (8091bb16 -> 36e45665)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 8091bb16 generate docs for 8545a889 new 36e45665 generate docs for 8545a889 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (8091bb16) \ N -- N -- N refs/heads/asf-staging (36e45665) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4796442 -> 4796442 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17708) Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails
[ https://issues.apache.org/jira/browse/CASSANDRA-17708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-17708: -- Source Control Link: https://github.com/apache/cassandra/commit/4a555f47ee943ce9fd70862cc8127d707e3507a2 (was: 4a555f4) > Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails > - > > Key: CASSANDRA-17708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17708 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.2 > > Time Spent: 50m > Remaining Estimate: 0h > > testOutboundConnectionsAreRejectedWhenAuthFails was introduced in > CASSANDRA-17661 > It seems it was introduced flaky from the very beginning as per this run in a > loop - > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=flaky-testOutboundConnectionsAreRejectedWhenAuthFails&filter=all] > CC [~janaki.manchala] , [~jonmeredith], [~ycai] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17708) Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails
[ https://issues.apache.org/jira/browse/CASSANDRA-17708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690671#comment-17690671 ] Yifan Cai commented on CASSANDRA-17708: --- Committed into trunk as [4a555f4|https://github.com/apache/cassandra/commit/4a555f47ee943ce9fd70862cc8127d707e3507a2] > Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails > - > > Key: CASSANDRA-17708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17708 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.2 > > Time Spent: 50m > Remaining Estimate: 0h > > testOutboundConnectionsAreRejectedWhenAuthFails was introduced in > CASSANDRA-17661 > It seems it was introduced flaky from the very beginning as per this run in a > loop - > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=flaky-testOutboundConnectionsAreRejectedWhenAuthFails&filter=all] > CC [~janaki.manchala] , [~jonmeredith], [~ycai] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17708) Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails
[ https://issues.apache.org/jira/browse/CASSANDRA-17708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-17708: -- Since Version: 4.2 Source Control Link: 4a555f4 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails > - > > Key: CASSANDRA-17708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17708 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.2 > > Time Spent: 50m > Remaining Estimate: 0h > > testOutboundConnectionsAreRejectedWhenAuthFails was introduced in > CASSANDRA-17661 > It seems it was introduced flaky from the very beginning as per this run in a > loop - > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=flaky-testOutboundConnectionsAreRejectedWhenAuthFails&filter=all] > CC [~janaki.manchala] , [~jonmeredith], [~ycai] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails
This is an automated email from the ASF dual-hosted git repository.
ycai pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 4a555f47ee Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails
4a555f47ee is described below
commit 4a555f47ee943ce9fd70862cc8127d707e3507a2
Author: Jyothsna Konisa
AuthorDate: Fri Feb 17 13:50:06 2023 -0800
Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails
patch by Jyothsna Konisa; reviewed by Jon Meredith, Yifan Cai for
CASSANDRA-17708
---
.../cassandra/net/OutboundConnectionInitiator.java | 5 +-
.../test/InternodeEncryptionEnforcementTest.java | 72 ++
2 files changed, 36 insertions(+), 41 deletions(-)
diff --git a/src/java/org/apache/cassandra/net/OutboundConnectionInitiator.java
b/src/java/org/apache/cassandra/net/OutboundConnectionInitiator.java
index f8df49b598..ebd30f5406 100644
--- a/src/java/org/apache/cassandra/net/OutboundConnectionInitiator.java
+++ b/src/java/org/apache/cassandra/net/OutboundConnectionInitiator.java
@@ -147,7 +147,8 @@ public class OutboundConnectionInitiator openConnections(cluster));
/*
- * instance (1) should not connect to instance (2) as
authentication fails;
- * instance (2) should not connect to instance (1) as
authentication fails.
+ * Instance (1) should be able to make outbound connections to
instance (2) but Instance (1) should not be
+ * accepting any inbound connections. we should wait for the
authentication failure log on Instance (1)
*/
SerializableRunnable runnable = () ->
{
-// There should be no inbound handlers as authentication fails
and we remove handlers.
+// There should be no inbound handlers as authentication fails
& we remove handlers.
assertEquals(0,
MessagingService.instance().messageHandlers.values().size());
-// There should be no outbound connections as authentication
fails.
-OutboundConnections outbound =
getOnlyElement(MessagingService.instance().channelManagers.values());
-assertTrue(!outbound.small.isConnected() &&
!outbound.large.isConnected() && !outbound.urgent.isConnected());
-
// Verify that the failure is due to authentication failure
final RejectInboundConnections authenticator =
(RejectInboundConnections) DatabaseDescriptor.getInternodeAuthenticator();
assertTrue(authenticator.authenticationFailed);
@@ -86,10 +85,8 @@ public final class InternodeEncryptionEnforcementTest
extends TestBaseImpl
// Wait for authentication to fail
cluster.get(1).logs().watchFor("Unable to authenticate peer");
cluster.get(1).runOnInstance(runnable);
-cluster.get(2).logs().watchFor("Unable to authenticate peer");
-cluster.get(2).runOnInstance(runnable);
+
}
-executorService.shutdown();
}
@Test
@@ -98,21 +95,17 @@ public final class InternodeEncryptionEnforcementTest
extends TestBaseImpl
Cluster.Builder builder =
createCluster(RejectOutboundAuthenticator.class);
final ExecutorService executorService =
Executors.newSingleThreadExecutor();
-try (Cluster cluster = builder.start())
+try (Cluster cluster = builder.start(); Closeable es =
executorService::shutdown)
{
executorService.submit(() -> openConnections(cluster));
/*
- * instance (1) should not connect to instance (2) as
authentication fails;
- * instance (2) should not connect to instance (1) as
authentication fails.
+ * Instance (1) should not be able to make outbound connections to
instance (2) but Instance (2) should be
+ * accepting outbound connections from Instance (1)
*/
SerializableRunnable runnable = () ->
{
-// There should be no inbound connections as authentication
fails.
-InboundMessageHandlers inbound =
getOnlyElement(MessagingService.instance().messageHandlers.values());
-assertEquals(0, inbound.count());
-
-// There should be no outbound connections as authentication
fails.
+// There should be no outbound connections as authentication
fails on Instance (1).
OutboundConnections outbound =
getOnlyElement(MessagingService.instance().channelManagers.values());
assertTrue(!outbound.small.isConnected() &&
!outbound.large.isConnected() && !outbound.urgent.isConnected());
@@ -122,31 +115,23 @@ public final class InternodeEncryptionEnforcementTest
extends TestBaseImpl
};
// Wait for authentication to fail
-cluster.get(1).
[jira] [Updated] (CASSANDRA-17708) Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails
[ https://issues.apache.org/jira/browse/CASSANDRA-17708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-17708: -- Status: Ready to Commit (was: Review In Progress) > Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails > - > > Key: CASSANDRA-17708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17708 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.x > > Time Spent: 50m > Remaining Estimate: 0h > > testOutboundConnectionsAreRejectedWhenAuthFails was introduced in > CASSANDRA-17661 > It seems it was introduced flaky from the very beginning as per this run in a > loop - > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=flaky-testOutboundConnectionsAreRejectedWhenAuthFails&filter=all] > CC [~janaki.manchala] , [~jonmeredith], [~ycai] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17708) Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails
[ https://issues.apache.org/jira/browse/CASSANDRA-17708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-17708: -- Fix Version/s: 4.2 (was: 4.x) > Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails > - > > Key: CASSANDRA-17708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17708 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.2 > > Time Spent: 50m > Remaining Estimate: 0h > > testOutboundConnectionsAreRejectedWhenAuthFails was introduced in > CASSANDRA-17661 > It seems it was introduced flaky from the very beginning as per this run in a > loop - > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=flaky-testOutboundConnectionsAreRejectedWhenAuthFails&filter=all] > CC [~janaki.manchala] , [~jonmeredith], [~ycai] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17708) Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails
[ https://issues.apache.org/jira/browse/CASSANDRA-17708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690622#comment-17690622 ] Yifan Cai edited comment on CASSANDRA-17708 at 2/18/23 1:37 AM: CI Results: ||Branch||Source||Circle CI|| |trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17708-trunk-1662A2B4-3399-4286-B740-E99FABB18E10]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17708-trunk-1662A2B4-3399-4286-B740-E99FABB18E10]| The patch only contains test code changes. The flaky tests do not fail in the run attached. And [running it repeatedly|https://app.circleci.com/pipelines/github/jyothsnakonisa/cassandra/132/workflows/182dd59d-cffe-4f6e-959e-0c32395b9088/jobs/2017/steps] (500 times) also shows green. was (Author: yifanc): Starting commit CI Results (pending): ||Branch||Source||Circle CI|| |trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17708-trunk-1662A2B4-3399-4286-B740-E99FABB18E10]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17708-trunk-1662A2B4-3399-4286-B740-E99FABB18E10]| > Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails > - > > Key: CASSANDRA-17708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17708 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.x > > Time Spent: 50m > Remaining Estimate: 0h > > testOutboundConnectionsAreRejectedWhenAuthFails was introduced in > CASSANDRA-17661 > It seems it was introduced flaky from the very beginning as per this run in a > loop - > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=flaky-testOutboundConnectionsAreRejectedWhenAuthFails&filter=all] > CC [~janaki.manchala] , [~jonmeredith], [~ycai] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18204) CEP-15: (C*) Add git submodule for Accord
[ https://issues.apache.org/jira/browse/CASSANDRA-18204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18204: -- Fix Version/s: 4.2 (was: 4.x) Source Control Link: 71f836b33eb90525f2b1e08fa26bcdb4f821b6ff Resolution: Fixed Status: Resolved (was: Ready to Commit) > CEP-15: (C*) Add git submodule for Accord > - > > Key: CASSANDRA-18204 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18204 > Project: Cassandra > Issue Type: Task > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.2 > > Time Spent: 9h 20m > Remaining Estimate: 0h > > As talked about in dev@ thread "Intra-project dependencies”, we talked about > adding git submodules but before doing this had to work out a few issues > first; this ticket is to track this work. > Goals > * when checking out an older commit, or pulling in newer commits, the > submodule should also be updated automatically > * release artifact must include the submodule and must be able to build > without issue > * build.xml must be updated to build the submodule > * build.xml must be updated to release the submodule jar -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cep-15-accord updated: CEP-15: (C*) Add git submodule for Accord
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch cep-15-accord
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cep-15-accord by this push:
new 71f836b33e CEP-15: (C*) Add git submodule for Accord
71f836b33e is described below
commit 71f836b33eb90525f2b1e08fa26bcdb4f821b6ff
Author: David Capwell
AuthorDate: Fri Feb 17 15:24:10 2023 -0800
CEP-15: (C*) Add git submodule for Accord
patch by David Capwell; reviewed by Caleb Rackliffe, Michael Semb Wever for
CASSANDRA-18204
---
.build/build-accord.xml| 37 +
.build/build-resolver.xml | 4 +-
.build/cassandra-build-deps-template.xml | 4 +-
.build/cassandra-deps-template.xml | 4 +-
.../post-checkout/100-update-submodules.sh}| 35 ++---
.build/git/git-hooks/post-switch | 1 +
.../pre-commit/100-verify-submodules-pushed.sh | 98 +
.../git-hooks/pre-push/100-push-submodules.sh} | 45 +++---
.build/git/install-git-defaults.sh | 117
.build/parent-pom-template.xml | 12 +-
.build/{include-accord.sh => sh/bump-accord.sh}| 36 ++---
.../change-submodule-accord.sh}| 29 +---
.../{include-accord.sh => sh/change-submodule.sh} | 43 +++---
.build/sh/development-switch.sh| 153 +
.gitignore | 1 -
.gitmodules| 4 +
CHANGES.txt| 1 +
CONTRIBUTING.md| 33 +
build.xml | 42 --
ide/idea-iml-file.xml | 20 +++
ide/idea/vcs.xml | 3 +-
modules/accord | 1 +
22 files changed, 576 insertions(+), 147 deletions(-)
diff --git a/.build/build-accord.xml b/.build/build-accord.xml
new file mode 100644
index 00..eeadf4dd18
--- /dev/null
+++ b/.build/build-accord.xml
@@ -0,0 +1,37 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/.build/build-resolver.xml b/.build/build-resolver.xml
index 60122b854f..7c47d0790a 100644
--- a/.build/build-resolver.xml
+++ b/.build/build-resolver.xml
@@ -165,7 +165,7 @@
-
+
@@ -189,7 +189,7 @@
-
+
diff --git a/.build/cassandra-build-deps-template.xml
b/.build/cassandra-build-deps-template.xml
index cfd2806fe7..704772a143 100644
--- a/.build/cassandra-build-deps-template.xml
+++ b/.build/cassandra-build-deps-template.xml
@@ -128,8 +128,8 @@
jackson-dataformat-yaml
- accord
- accord
+ org.apache.cassandra
+ cassandra-accord
tests
diff --git a/.build/cassandra-deps-template.xml
b/.build/cassandra-deps-template.xml
index 85940f5ae6..8f54619fbf 100644
--- a/.build/cassandra-deps-template.xml
+++ b/.build/cassandra-deps-template.xml
@@ -130,8 +130,8 @@
jbcrypt
- accord
- accord
+ org.apache.cassandra
+ cassandra-accord
io.airlift
diff --git a/.build/include-accord.sh
b/.build/git/git-hooks/post-checkout/100-update-submodules.sh
similarity index 55%
copy from .build/include-accord.sh
copy to .build/git/git-hooks/post-checkout/100-update-submodules.sh
index 34ee959221..b495ed0860 100755
--- a/.build/include-accord.sh
+++ b/.build/git/git-hooks/post-checkout/100-update-submodules.sh
@@ -1,5 +1,4 @@
#!/usr/bin/env bash
-#
# Licensed to the Apache Software Foundation (ASF) under one
# or more contributor license agreements. See the NOTICE file
# distributed with this work for additional information
@@ -15,7 +14,9 @@
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
-#
+
+# Redirect output to stderr.
+exec 1>&2
#set -o xtrace
set -o errexit
@@ -24,29 +25,17 @@ set -o nounset
bin="$(cd "$(dirname "$0")" > /dev/null; pwd)"
-accord_repo='https://github.com/apache/cassandra-accord.git'
-accord_sha='da77b744e4fdb5f39656e4269f4f1806e485c9c0'
-accord_src="$bin/cassandra-accord"
-
_main() {
- # have we already cloned?
- if [[ ! -e "$accord_src" ]] || [[ $(cat "$accord_src/.REPO" || true) !=
"$accord_repo" ]]; then
-rm -rf "$accord_src" || true
-git clone "$accord_repo" "$accord_src"
-echo "$accord_repo" > "$accord_src/.REPO"
- fi
- cd "$accord_src"
- # switch to target SHA
- git fetch origin # check for changes
- local current_sha
- current_sha="$(git rev-parse HEAD)
[cassandra-website] branch asf-staging updated (f8d87a14 -> 8091bb16)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard f8d87a14 generate docs for 8545a889 new 8091bb16 generate docs for 8545a889 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (f8d87a14) \ N -- N -- N refs/heads/asf-staging (8091bb16) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4796442 -> 4796442 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18204) CEP-15: (C*) Add git submodule for Accord
[ https://issues.apache.org/jira/browse/CASSANDRA-18204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690658#comment-17690658 ] David Capwell commented on CASSANDRA-18204: --- Starting commit CI Results (pending): ||Branch||Source||Circle CI||Jenkins|| |cep-15-accord|[branch|https://github.com/dcapwell/cassandra/tree/commit_remote_branch/CASSANDRA-18204-cep-15-accord-4D1D2E46-F51E-41FE-BB7E-A84047D0E61C]|[build|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-18204-cep-15-accord-4D1D2E46-F51E-41FE-BB7E-A84047D0E61C]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/2289/]| > CEP-15: (C*) Add git submodule for Accord > - > > Key: CASSANDRA-18204 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18204 > Project: Cassandra > Issue Type: Task > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > Time Spent: 9h 20m > Remaining Estimate: 0h > > As talked about in dev@ thread "Intra-project dependencies”, we talked about > adding git submodules but before doing this had to work out a few issues > first; this ticket is to track this work. > Goals > * when checking out an older commit, or pulling in newer commits, the > submodule should also be updated automatically > * release artifact must include the submodule and must be able to build > without issue > * build.xml must be updated to build the submodule > * build.xml must be updated to release the submodule jar -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-accord] branch trunk updated: CEP-15: (C*) Add git submodule for Accord (#29)
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-accord.git
The following commit(s) were added to refs/heads/trunk by this push:
new b9025e5 CEP-15: (C*) Add git submodule for Accord (#29)
b9025e5 is described below
commit b9025e59395f47535e4ed1fec20b1186cdb07db8
Author: dcapwell
AuthorDate: Fri Feb 17 14:55:27 2023 -0800
CEP-15: (C*) Add git submodule for Accord (#29)
patch by David Capwell; reviewed by Caleb Rackliffe, Michael Semb Wever for
CASSANDRA-18204
---
accord-core/build.gradle | 33 ++-
accord-maelstrom/build.gradle | 2 +-
.../src/main/groovy/accord.java-conventions.gradle | 18 +-
.../gradle-wrapper.properties => gradle.properties | 8 +-
gradle/wrapper/gradle-wrapper.jar | Bin 59203 -> 61574 bytes
gradle/wrapper/gradle-wrapper.properties | 3 +-
gradlew| 269 +
gradlew.bat| 15 +-
8 files changed, 220 insertions(+), 128 deletions(-)
diff --git a/accord-core/build.gradle b/accord-core/build.gradle
index 32e1164..c5d61cd 100644
--- a/accord-core/build.gradle
+++ b/accord-core/build.gradle
@@ -41,7 +41,7 @@ dependencies {
task burn(type: JavaExec) {
classpath sourceSets.main.runtimeClasspath, sourceSets.test.output
-main = 'accord.burn.BurnTest'
+mainClass = 'accord.burn.BurnTest'
jvmArgs '-Dlogback.configurationFile=burn-logback.xml'
args = ['-c', '1']
}
@@ -56,15 +56,32 @@ task testJar(type: Jar, dependsOn: testClasses) {
publishing {
publications {
mavenJava(MavenPublication) {
- artifactId = 'accord'
+ artifactId = accord_artifactId
pom {
+name = 'Apache Cassandra Accord'
+description = 'General purpose transactions library using a leaderless
consensus protocol to have highly available transactions'
+url =
'https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-15%3A+General+Purpose+Transactions'
inceptionYear = '2021'
+licenses {
+ license {
+name = 'The Apache Software License, Version 2.0'
+url = 'https://www.apache.org/licenses/LICENSE-2.0.txt'
+ }
+}
+scm {
+ connection =
'scm:https://gitbox.apache.org/repos/asf/cassandra-accord.git'
+ developerConnection =
'scm:https://gitbox.apache.org/repos/asf/cassandra-accord.git'
+ url =
'https://gitbox.apache.org/repos/asf?p=cassandra-accord.git;a=tree'
+}
+ }
+ // This is a hack to remove accord from the dependency list as this
breaks Apache Cassandra
+ // This is a bug with Gradle that was supposed to be fixed in 8.0 but
does not seem to work
+ // see
https://github.com/gradle/gradle/commit/6e596c638dff59dfa06032a7e7a3974275ddb3e1
+ pom.withXml {
+asNode().dependencies.'*'.findAll() { it.artifactId.text() ==
accord_artifactId }.each() { it.parent().remove(it) }
}
from components.java
-}
-
-test(MavenPublication) {
- artifactId = 'accord'
+ // don't need to add javadoc or sources as they were added already in
the java block
artifact testJar
}
}
@@ -76,7 +93,7 @@ task burnforkloop {
.times {
javaexec {
classpath sourceSets.main.runtimeClasspath,
sourceSets.test.output
-main = 'accord.burn.BurnTest'
+mainClass = 'accord.burn.BurnTest'
jvmArgs '-Dlogback.configurationFile=burn-logback.xml'
args = ['-c', '1']
}
@@ -88,7 +105,7 @@ task burnloop {
doLast {
javaexec {
classpath sourceSets.main.runtimeClasspath, sourceSets.test.output
-main = 'accord.burn.BurnTest'
+mainClass = 'accord.burn.BurnTest'
jvmArgs '-Dlogback.configurationFile=burn-logback.xml'
args = ['-c', project.hasProperty('burnTimes') ?
project.getProperty('burnTimes') : '100']
}
diff --git a/accord-maelstrom/build.gradle b/accord-maelstrom/build.gradle
index dfc1173..f07c43c 100644
--- a/accord-maelstrom/build.gradle
+++ b/accord-maelstrom/build.gradle
@@ -38,7 +38,7 @@ jar {
task fatJar(type: Jar) {
manifest.from jar.manifest
-classifier = 'all'
+archiveClassifier = 'all'
from {
configurations.runtimeClasspath.collect { it.isDirectory() ? it :
zipTree(it) }
} {
diff --git a/buildSrc/src/main/groovy/accord.java-conventions.gradle
b/buildSrc/src/main/groovy/accord.java-conventions.gradle
index c967906..3ca1d57 100644
--- a/buildSrc/src/main/groovy/accord.java-conventions.gradle
+++ b/buildSrc/src/main/groovy/accord.java-conventions.gradle
@@ -20,8 +20,8 @@ plugins {
id 'jav
[jira] [Updated] (CASSANDRA-18204) CEP-15: (C*) Add git submodule for Accord
[ https://issues.apache.org/jira/browse/CASSANDRA-18204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18204: -- Status: Ready to Commit (was: Review In Progress) > CEP-15: (C*) Add git submodule for Accord > - > > Key: CASSANDRA-18204 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18204 > Project: Cassandra > Issue Type: Task > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > Time Spent: 9h 20m > Remaining Estimate: 0h > > As talked about in dev@ thread "Intra-project dependencies”, we talked about > adding git submodules but before doing this had to work out a few issues > first; this ticket is to track this work. > Goals > * when checking out an older commit, or pulling in newer commits, the > submodule should also be updated automatically > * release artifact must include the submodule and must be able to build > without issue > * build.xml must be updated to build the submodule > * build.xml must be updated to release the submodule jar -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (bae0da05 -> f8d87a14)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard bae0da05 generate docs for 8545a889 new f8d87a14 generate docs for 8545a889 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (bae0da05) \ N -- N -- N refs/heads/asf-staging (f8d87a14) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4796442 -> 4796442 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18247) Add CircleCI config file for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690636#comment-17690636 ] Ekaterina Dimitrova commented on CASSANDRA-18247: - I have a patch for this one, but then it seems we might want to rework it for CASSANDRA-18133. [~mck], [~brandonwilliams] we need to align on this next week really. > Add CircleCI config file for J11+J17 > > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose a CircleCI config file which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18247) Add CircleCI config file for J11+J17
[ https://issues.apache.org/jira/browse/CASSANDRA-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690636#comment-17690636 ] Ekaterina Dimitrova edited comment on CASSANDRA-18247 at 2/17/23 10:17 PM: --- I have a preliminary patch for this one, but then it seems we might want to rework it for CASSANDRA-18133. [~mck], [~brandonwilliams] we need to align on this next week really. was (Author: e.dimitrova): I have a patch for this one, but then it seems we might want to rework it for CASSANDRA-18133. [~mck], [~brandonwilliams] we need to align on this next week really. > Add CircleCI config file for J11+J17 > > > Key: CASSANDRA-18247 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18247 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Based on the direction of [this > discussion|https://lists.apache.org/thread/hchv59c1sntgb74clynj0zfd8jvwdmgy], > I would like to propose a CircleCI config file which can be used to test > current trunk with JDK 17 (after I blindly remove the scripted UDFs in > another ticket, to be opened soon) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690631#comment-17690631 ] Ekaterina Dimitrova commented on CASSANDRA-18106: - Well I still see pointing to 11 unfortunately :( Yes, I also noticed it detected it which is definitely step forward in the right direction :) Thanks > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18258) Add test conf for JDK17
[ https://issues.apache.org/jira/browse/CASSANDRA-18258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690630#comment-17690630 ] Ekaterina Dimitrova commented on CASSANDRA-18258: - PS the jvm args in build.xml can be split in a more beautiful way but considering this is temporarily until we drop JDK8 which will simplify and get back us to where we were, I opt out of spending too much time on those. > Add test conf for JDK17 > --- > > Key: CASSANDRA-18258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18258 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Post CASSANDRA-18252 and CASSANDRA-18179 we will be able to compile current > trunk with JDK17 but in order to start Cassandra and test it we will need > also our conf files updated with some preliminary conf for test purposes. > This ticket will be used to add those to current trunk -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18258) Add test conf for JDK17
[ https://issues.apache.org/jira/browse/CASSANDRA-18258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18258: Test and Documentation Plan: ||Patch||CI 8+11||CI 11+17|| |[trunk|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:cassandra:18258-trunk-3?expand=1]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18258-test-8]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18258-trunk-3]| Here it is preliminary config to enable start Cassandra and run at least Unit and JVM tests(the build.xml GC config should be changed in CASSANDRA-18263). I added some CircleCI tests so I can show at least the unit tests that they pickup the right things. Final agreement on what we want for CircleCI precisely will be made in CASSANDRA-18247 and I guess it might need revisit based on CASSANDRA-18133. I added IntelliJ IDEA target too but I am again in a loop with my IDE today. Now it sends me a message it cannot save my settings all the time... I will have to figure that out over the weekend. Please ignore the CircleCI files for now. Also, we had with Michael Semb Wever a conversation to add some exports for fqltool and auditlogviewer, I opted to add them in jvm17-clients.options (even if the other tools do not need them) as while they will be needed also with Java 11 after we upgrade Chronicle Queue, they cannot be used with Java 8 now. There are still some tests running but so far it seems we see JDK17 around 20 unit tests failing which we already know about - pending the ECJ upgrade, etc PS the jvm args in build.xml can be split in a more beautiful way but considering this is temporarily until we drop JDK8 which will simplify and get back us to where we were, I opt out of spending too much time on those. was: ||Patch||CI 8+11||CI 11+17|| |[trunk|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:cassandra:18258-trunk-3?expand=1]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18258-test-8]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18258-trunk-3]| Here it is preliminary config to enable start Cassandra and run at least Unit and JVM tests(the build.xml GC config should be changed in CASSANDRA-18263). I added some CircleCI tests so I can show at least the unit tests that they pickup the right things. Final agreement on what we want for CircleCI precisely will be made in CASSANDRA-18247 and I guess it might need revisit based on CASSANDRA-18133. I added IntelliJ IDEA target too but I am again in a loop with my IDE today. Now it sends me a message it cannot save my settings all the time... I will have to figure that out over the weekend. Please ignore the CircleCI files for now. Also, we had with Michael Semb Wever a conversation to add some exports for fqltool and auditlogviewer, I opted to add them in jvm17-clients.options (even if the other tools do not need them) as while they will be needed also with Java 11 after we upgrade Chronicle Queue, they cannot be used with Java 8 now. There are still some tests running but so far it seems we see JDK17 around 20 unit tests failing which we already know about - pending the ECJ upgrade, etc > Add test conf for JDK17 > --- > > Key: CASSANDRA-18258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18258 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Post CASSANDRA-18252 and CASSANDRA-18179 we will be able to compile current > trunk with JDK17 but in order to start Cassandra and test it we will need > also our conf files updated with some preliminary conf for test purposes. > This ticket will be used to add those to current trunk -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18258) Add test conf for JDK17
[ https://issues.apache.org/jira/browse/CASSANDRA-18258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18258: Test and Documentation Plan: ||Patch||CI 8+11||CI 11+17|| |[trunk|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:cassandra:18258-trunk-3?expand=1]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18258-test-8]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18258-trunk-3]| Here it is preliminary config to enable start Cassandra and run at least Unit and JVM tests(the build.xml GC config should be changed in CASSANDRA-18263). I added some CircleCI tests so I can show at least the unit tests that they pickup the right things. Final agreement on what we want for CircleCI precisely will be made in CASSANDRA-18247 and I guess it might need revisit based on CASSANDRA-18133. I added IntelliJ IDEA target too but I am again in a loop with my IDE today. Now it sends me a message it cannot save my settings all the time... I will have to figure that out over the weekend. Please ignore the CircleCI files for now. Also, we had with Michael Semb Wever a conversation to add some exports for fqltool and auditlogviewer, I opted to add them in jvm17-clients.options (even if the other tools do not need them) as while they will be needed also with Java 11 after we upgrade Chronicle Queue, they cannot be used with Java 8 now. There are still some tests running but so far it seems we see JDK17 around 20 unit tests failing which we already know about - pending the ECJ upgrade, etc was: Here it is preliminary config to enable start Cassandra and run at least Unit and JVM tests(the build.xml GC config should be changed in CASSANDRA-18263). I added some CircleCI tests so I can show at least the unit tests that they pickup the right things. Final agreement on what we want for CircleCI precisely will be made in CASSANDRA-18247 and I guess it might need revisit based on CASSANDRA-18133. I added IntelliJ IDEA target too but I am again in a loop with my IDE today. Now it sends me a message it cannot save my settings all the time... I will have to figure that out over the weekend. Please ignore the CircleCI files for now. Also, we had with Michael Semb Wever a conversation to add some exports for fqltool and auditlogviewer, I opted to add them in jvm17-clients.options (even if the other tools do not need them) as while they will be needed also with Java 11 after we upgrade Chronicle Queue, they cannot be used with Java 8 now. There are still some tests running but so far it seems we see JDK17 around 20 unit tests failing which we already know about - pending the ECJ upgrade, etc > Add test conf for JDK17 > --- > > Key: CASSANDRA-18258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18258 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Post CASSANDRA-18252 and CASSANDRA-18179 we will be able to compile current > trunk with JDK17 but in order to start Cassandra and test it we will need > also our conf files updated with some preliminary conf for test purposes. > This ticket will be used to add those to current trunk -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18258) Add test conf for JDK17
[ https://issues.apache.org/jira/browse/CASSANDRA-18258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18258: Test and Documentation Plan: Here it is preliminary config to enable start Cassandra and run at least Unit and JVM tests(the build.xml GC config should be changed in CASSANDRA-18263). I added some CircleCI tests so I can show at least the unit tests that they pickup the right things. Final agreement on what we want for CircleCI precisely will be made in CASSANDRA-18247 and I guess it might need revisit based on CASSANDRA-18133. I added IntelliJ IDEA target too but I am again in a loop with my IDE today. Now it sends me a message it cannot save my settings all the time... I will have to figure that out over the weekend. Please ignore the CircleCI files for now. Also, we had with Michael Semb Wever a conversation to add some exports for fqltool and auditlogviewer, I opted to add them in jvm17-clients.options (even if the other tools do not need them) as while they will be needed also with Java 11 after we upgrade Chronicle Queue, they cannot be used with Java 8 now. There are still some tests running but so far it seems we see JDK17 around 20 unit tests failing which we already know about - pending the ECJ upgrade, etc was: Patch CI 8+11 CI 11+17 trunk CI CI Here it is preliminary config to enable start Cassandra and run at least Unit and JVM tests(the build.xml GC config should be changed in CASSANDRA-18263). I added some CircleCI tests so I can show at least the unit tests that they pickup the right things. Final agreement on what we want for CircleCI precisely will be made in CASSANDRA-18247 and I guess it might need revisit based on CASSANDRA-18133. I added IntelliJ IDEA target too but I am again in a loop with my IDE today. Now it sends me a message it cannot save my settings all the time... I will have to figure that out over the weekend. Please ignore the CircleCI files for now. Also, we had with Michael Semb Wever a conversation to add some exports for fqltool and auditlogviewer, I opted to add them in jvm17-clients.options (even if the other tools do not need them) as while they will be needed also with Java 11 after we upgrade Chronicle Queue, they cannot be used with Java 8 now. There are still some tests running but so far it seems we see JDK17 around 20 unit tests failing which we already know about - pending the ECJ upgrade, etc > Add test conf for JDK17 > --- > > Key: CASSANDRA-18258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18258 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Post CASSANDRA-18252 and CASSANDRA-18179 we will be able to compile current > trunk with JDK17 but in order to start Cassandra and test it we will need > also our conf files updated with some preliminary conf for test purposes. > This ticket will be used to add those to current trunk -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18258) Add test conf for JDK17
[ https://issues.apache.org/jira/browse/CASSANDRA-18258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690626#comment-17690626 ] Ekaterina Dimitrova edited comment on CASSANDRA-18258 at 2/17/23 10:04 PM: --- ||Patch||CI 8+11||CI 11+17|| |[trunk|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:cassandra:18258-trunk-3?expand=1]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18258-test-8]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18258-trunk-3]| Here it is preliminary config to enable start Cassandra and run at least Unit and JVM tests(the build.xml GC config should be changed in CASSANDRA-18263). I added _some_ CircleCI tests so I can show at least the unit tests that they pickup the right things. Final agreement on what we want for CircleCI precisely will be made in CASSANDRA-18247 and I guess it might need revisit based on CASSANDRA-18133. I added IntelliJ IDEA target too but I am again in a loop with my IDE today. Now it sends me a message it cannot save my settings all the time... I will have to figure that out over the weekend. Please ignore the CircleCI files for now. Also, we had with [~mck] a conversation to add some exports for fqltool and auditlogviewer, I opted to add them in jvm17-clients.options (even if the other tools do not need them) as while they will be needed also with Java 11 after we upgrade Chronicle Queue, they cannot be used with Java 8 now. There are still some tests running but so far it seems we see JDK17 around 20 unit tests failing which we already know about - pending the ECJ upgrade, etc [~mck] and [~brandon.williams], do you mind to take a look? I will also revisit it one more time on Tuesday. My main concern is that there are things that can break and become unnoticed in CI so trying to be extra careful. Thanks was (Author: e.dimitrova): ||Patch||CI 8+11||CI 11+17|| |[trunk|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:cassandra:18258-trunk-3?expand=1]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18258-test-8]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18258-trunk-3]| Here it is preliminary config to enable start Cassandra and run at least Unit and JVM tests(the build.xml GC config should be changed in CASSANDRA-18263). I added _some_ CircleCI tests so I can show at least the unit tests that they pickup the right things. Final agreement on what we want for CircleCI precisely will be made in CASSANDRA-18247 and I guess it might need revisit based on CASSANDRA-18133. I added IntelliJ IDEA target too but I am again in a loop with my IDE today. Now it sends me a message it cannot save my settings all the time... I will have to figure that out over the weekend. Please ignore the CircleCI files for now. Also, we had with [~mck] a conversation to add some exports for fqltool and auditlogviewer, I opted to add them in jvm17-clients.options (even if the other tools do not need them) as while they will be needed also with Java 11 after we upgrade Chronicle Queue, they cannot be used with Java 8 now. There are still some tests running but so far it seems we see JDK17 around 20 unit tests failing which we already know about - pending the ECJ upgrade, etc [~mck] and [~brandon.williams], do you mind to take a look? I will also revisit it one more time on Tuesday. My main concern is that there are things that can break and become unnoticed in CI so trying to be extra careful. Thanks > Add test conf for JDK17 > --- > > Key: CASSANDRA-18258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18258 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Post CASSANDRA-18252 and CASSANDRA-18179 we will be able to compile current > trunk with JDK17 but in order to start Cassandra and test it we will need > also our conf files updated with some preliminary conf for test purposes. > This ticket will be used to add those to current trunk -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18258) Add test conf for JDK17
[ https://issues.apache.org/jira/browse/CASSANDRA-18258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18258: Test and Documentation Plan: Patch CI 8+11 CI 11+17 trunk CI CI Here it is preliminary config to enable start Cassandra and run at least Unit and JVM tests(the build.xml GC config should be changed in CASSANDRA-18263). I added some CircleCI tests so I can show at least the unit tests that they pickup the right things. Final agreement on what we want for CircleCI precisely will be made in CASSANDRA-18247 and I guess it might need revisit based on CASSANDRA-18133. I added IntelliJ IDEA target too but I am again in a loop with my IDE today. Now it sends me a message it cannot save my settings all the time... I will have to figure that out over the weekend. Please ignore the CircleCI files for now. Also, we had with Michael Semb Wever a conversation to add some exports for fqltool and auditlogviewer, I opted to add them in jvm17-clients.options (even if the other tools do not need them) as while they will be needed also with Java 11 after we upgrade Chronicle Queue, they cannot be used with Java 8 now. There are still some tests running but so far it seems we see JDK17 around 20 unit tests failing which we already know about - pending the ECJ upgrade, etc Status: Patch Available (was: In Progress) > Add test conf for JDK17 > --- > > Key: CASSANDRA-18258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18258 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Post CASSANDRA-18252 and CASSANDRA-18179 we will be able to compile current > trunk with JDK17 but in order to start Cassandra and test it we will need > also our conf files updated with some preliminary conf for test purposes. > This ticket will be used to add those to current trunk -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18258) Add test conf for JDK17
[ https://issues.apache.org/jira/browse/CASSANDRA-18258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690626#comment-17690626 ] Ekaterina Dimitrova commented on CASSANDRA-18258: - ||Patch||CI 8+11||CI 11+17|| |[trunk|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:cassandra:18258-trunk-3?expand=1]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18258-test-8]|[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=18258-trunk-3]| Here it is preliminary config to enable start Cassandra and run at least Unit and JVM tests(the build.xml GC config should be changed in CASSANDRA-18263). I added _some_ CircleCI tests so I can show at least the unit tests that they pickup the right things. Final agreement on what we want for CircleCI precisely will be made in CASSANDRA-18247 and I guess it might need revisit based on CASSANDRA-18133. I added IntelliJ IDEA target too but I am again in a loop with my IDE today. Now it sends me a message it cannot save my settings all the time... I will have to figure that out over the weekend. Please ignore the CircleCI files for now. Also, we had with [~mck] a conversation to add some exports for fqltool and auditlogviewer, I opted to add them in jvm17-clients.options (even if the other tools do not need them) as while they will be needed also with Java 11 after we upgrade Chronicle Queue, they cannot be used with Java 8 now. There are still some tests running but so far it seems we see JDK17 around 20 unit tests failing which we already know about - pending the ECJ upgrade, etc [~mck] and [~brandon.williams], do you mind to take a look? I will also revisit it one more time on Tuesday. My main concern is that there are things that can break and become unnoticed in CI so trying to be extra careful. Thanks > Add test conf for JDK17 > --- > > Key: CASSANDRA-18258 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18258 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Post CASSANDRA-18252 and CASSANDRA-18179 we will be able to compile current > trunk with JDK17 but in order to start Cassandra and test it we will need > also our conf files updated with some preliminary conf for test purposes. > This ticket will be used to add those to current trunk -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690624#comment-17690624 ] Brandon Williams commented on CASSANDRA-18106: -- Got the same result [here|https://app.circleci.com/pipelines/github/driftx/cassandra/863/workflows/43619e1b-e52e-4b0a-ab36-f520ada13c18/jobs/12380] but instead of adding to the array, I [removed it|https://github.com/driftx/ccm/commit/8cbcebaab021f0812c678a2912616cbde0898c9b]. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17708) Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails
[ https://issues.apache.org/jira/browse/CASSANDRA-17708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690622#comment-17690622 ] Yifan Cai commented on CASSANDRA-17708: --- Starting commit CI Results (pending): ||Branch||Source||Circle CI|| |trunk|[branch|https://github.com/yifan_cai/cassandra/tree/commit_remote_branch/CASSANDRA-17708-trunk-1662A2B4-3399-4286-B740-E99FABB18E10]|[build|https://app.circleci.com/pipelines/github/yifan_cai/cassandra?branch=commit_remote_branch%2FCASSANDRA-17708-trunk-1662A2B4-3399-4286-B740-E99FABB18E10]| > Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails > - > > Key: CASSANDRA-17708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17708 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.x > > Time Spent: 50m > Remaining Estimate: 0h > > testOutboundConnectionsAreRejectedWhenAuthFails was introduced in > CASSANDRA-17661 > It seems it was introduced flaky from the very beginning as per this run in a > loop - > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=flaky-testOutboundConnectionsAreRejectedWhenAuthFails&filter=all] > CC [~janaki.manchala] , [~jonmeredith], [~ycai] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17708) Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails
[ https://issues.apache.org/jira/browse/CASSANDRA-17708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690622#comment-17690622 ] Yifan Cai edited comment on CASSANDRA-17708 at 2/17/23 9:55 PM: Starting commit CI Results (pending): ||Branch||Source||Circle CI|| |trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17708-trunk-1662A2B4-3399-4286-B740-E99FABB18E10]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17708-trunk-1662A2B4-3399-4286-B740-E99FABB18E10]| was (Author: yifanc): Starting commit CI Results (pending): ||Branch||Source||Circle CI|| |trunk|[branch|https://github.com/yifan_cai/cassandra/tree/commit_remote_branch/CASSANDRA-17708-trunk-1662A2B4-3399-4286-B740-E99FABB18E10]|[build|https://app.circleci.com/pipelines/github/yifan_cai/cassandra?branch=commit_remote_branch%2FCASSANDRA-17708-trunk-1662A2B4-3399-4286-B740-E99FABB18E10]| > Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails > - > > Key: CASSANDRA-17708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17708 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.x > > Time Spent: 50m > Remaining Estimate: 0h > > testOutboundConnectionsAreRejectedWhenAuthFails was introduced in > CASSANDRA-17661 > It seems it was introduced flaky from the very beginning as per this run in a > loop - > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=flaky-testOutboundConnectionsAreRejectedWhenAuthFails&filter=all] > CC [~janaki.manchala] , [~jonmeredith], [~ycai] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690614#comment-17690614 ] Brandon Williams commented on CASSANDRA-18106: -- It did indeed run with 11, but it detected 8 correctly: bq. 20:57:54,193 ccm INFO Starting node1 with JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 java_version=8 cassandra_version=4.2, Whatever set JAVA_HOME pointed at 11. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690604#comment-17690604 ] Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 2/17/23 9:24 PM: -- Please check here, 8 passes with 11: [https://app.circleci.com/pipelines/github/driftx/cassandra/863/workflows/7fde3481-a4fe-4dc3-87a5-85efe0444910/jobs/12336/steps] It is visible in step "Run dtests" Easy to miss, I did before so always checking since then :) I suspect you need to add 8 in the array maybe? was (Author: e.dimitrova): Please check here, 8 passes with 11: [https://app.circleci.com/pipelines/github/driftx/cassandra/863/workflows/7fde3481-a4fe-4dc3-87a5-85efe0444910/jobs/12336/steps] It is visible in step "Run dtests" Easy to miss, I did before so always checking since then :) > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690604#comment-17690604 ] Ekaterina Dimitrova commented on CASSANDRA-18106: - Please check here, 8 passes with 11: [https://app.circleci.com/pipelines/github/driftx/cassandra/863/workflows/7fde3481-a4fe-4dc3-87a5-85efe0444910/jobs/12336/steps] It is visible in step "Under DTests" Easy to miss, I did before so always checking since then :) > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690604#comment-17690604 ] Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 2/17/23 9:23 PM: -- Please check here, 8 passes with 11: [https://app.circleci.com/pipelines/github/driftx/cassandra/863/workflows/7fde3481-a4fe-4dc3-87a5-85efe0444910/jobs/12336/steps] It is visible in step "Run dtests" Easy to miss, I did before so always checking since then :) was (Author: e.dimitrova): Please check here, 8 passes with 11: [https://app.circleci.com/pipelines/github/driftx/cassandra/863/workflows/7fde3481-a4fe-4dc3-87a5-85efe0444910/jobs/12336/steps] It is visible in step "Under DTests" Easy to miss, I did before so always checking since then :) > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690598#comment-17690598 ] Brandon Williams commented on CASSANDRA-18106: -- ||Branch||CI|| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-18106-trunk]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/863/workflows/7fde3481-a4fe-4dc3-87a5-85efe0444910], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/863/workflows/3d4b4877-d2e3-4dd3-81bf-cf2a0874f278]| Looks like I was wrong, 8 passes. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18204) CEP-15: (C*) Add git submodule for Accord
[ https://issues.apache.org/jira/browse/CASSANDRA-18204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690592#comment-17690592 ] Michael Semb Wever commented on CASSANDRA-18204: +1, thanks David. > CEP-15: (C*) Add git submodule for Accord > - > > Key: CASSANDRA-18204 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18204 > Project: Cassandra > Issue Type: Task > Components: Accord >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > Time Spent: 9h 10m > Remaining Estimate: 0h > > As talked about in dev@ thread "Intra-project dependencies”, we talked about > adding git submodules but before doing this had to work out a few issues > first; this ticket is to track this work. > Goals > * when checking out an older commit, or pulling in newer commits, the > submodule should also be updated automatically > * release artifact must include the submodule and must be able to build > without issue > * build.xml must be updated to build the submodule > * build.xml must be updated to release the submodule jar -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690581#comment-17690581
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 2/17/23 8:51 PM:
--
{quote}+1
{quote}
I am lost considering our earlier conversation. +1 on the approach or +1 to
commit?
My understanding from the previous conversation in Slack is the current patch
will break Java 8 Python tests with trunk. So I am +1 on the patch, but not on
commit/retag yet as this will break trunk. Thank you
was (Author: e.dimitrova):
bq. +1
I am lost considering our earlier conversation. +1 on the approach or +1 to
commit?
My understanding is the current patch will break Java 8 Python tests with
trunk. So I am +1 on the patch, but not on commit/retag yet as this will break
trunk. Thank you
> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690587#comment-17690587
]
Ekaterina Dimitrova commented on CASSANDRA-18106:
-
{quote}I think there's a good chance that's true, I will investigate and update.
{quote}
Thanks. :)
> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690585#comment-17690585 ] Brandon Williams commented on CASSANDRA-18106: -- bq. My understanding is the current patch will break Java 8 Python tests with trunk. I think there's a good chance that's true, I will investigate and update. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690584#comment-17690584 ] Michael Semb Wever edited comment on CASSANDRA-18106 at 2/17/23 8:48 PM: - it won't break j8 on trunk source building ccm usage. so long as both JAVA_HOME and PATH is set to the jdk you want to use. was (Author: michaelsembwever): it won't break j8 on trunk source building ccm usage. so long as both JAVA_HOME and PATH is set to the jdk you want to use. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690584#comment-17690584 ] Michael Semb Wever commented on CASSANDRA-18106: it won't break j8 on trunk source building ccm usage. so long as both JAVA_HOME and PATH is set to the jdk you want to use. > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690561#comment-17690561 ] Michael Semb Wever edited comment on CASSANDRA-18106 at 2/17/23 8:48 PM: - +1 (EDIT: on the patch) was (Author: michaelsembwever): +1 > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (3ace8206 -> bae0da05)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 3ace8206 generate docs for 8545a889 new bae0da05 generate docs for 8545a889 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (3ace8206) \ N -- N -- N refs/heads/asf-staging (bae0da05) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4796442 -> 4796442 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690581#comment-17690581 ] Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 2/17/23 8:45 PM: -- bq. +1 I am lost considering our earlier conversation. +1 on the approach or +1 to commit? My understanding is the current patch will break Java 8 Python tests with trunk. So I am +1 on the patch, but not on commit/retag yet as this will break trunk. Thank you was (Author: e.dimitrova): +1 I am lost considering our earlier conversation. +1 on the approach or +1 to commit? My understanding is the current patch will break Java 8 Python tests with trunk. So I am +1 on the patch, but not on commit/retag yet as this will break trunk. Thank you > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18106: Reviewers: Ekaterina Dimitrova, Michael Semb Wever Status: Review In Progress (was: Patch Available) > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690581#comment-17690581
]
Ekaterina Dimitrova commented on CASSANDRA-18106:
-
{quote}bq. +1
{quote}
I am lost considering our earlier conversation. +1 on the approach or +1 to
commit?
My understanding is the current patch will break Java 8 Python tests. So I am
+1 on the patch but please, but not on commit/retag yet as this will break
trunk. Thank you
> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690581#comment-17690581
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 2/17/23 8:39 PM:
--
{quote}{quote}+1
{quote}{quote}
I am lost considering our earlier conversation. +1 on the approach or +1 to
commit?
My understanding is the current patch will break Java 8 Python tests with
trunk. So I am +1 on the patch but please, but not on commit/retag yet as this
will break trunk. Thank you
was (Author: e.dimitrova):
{quote}bq. +1
{quote}
I am lost considering our earlier conversation. +1 on the approach or +1 to
commit?
My understanding is the current patch will break Java 8 Python tests. So I am
+1 on the patch but please, but not on commit/retag yet as this will break
trunk. Thank you
> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[
https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690581#comment-17690581
]
Ekaterina Dimitrova edited comment on CASSANDRA-18106 at 2/17/23 8:39 PM:
--
+1
I am lost considering our earlier conversation. +1 on the approach or +1 to
commit?
My understanding is the current patch will break Java 8 Python tests with
trunk. So I am +1 on the patch, but not on commit/retag yet as this will break
trunk. Thank you
was (Author: e.dimitrova):
{quote}{quote}+1
{quote}{quote}
I am lost considering our earlier conversation. +1 on the approach or +1 to
commit?
My understanding is the current patch will break Java 8 Python tests with
trunk. So I am +1 on the patch but please, but not on commit/retag yet as this
will break trunk. Thank you
> Update CCM for JDK17 and revise current JDK detection strategy
> --
>
> Key: CASSANDRA-18106
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18106
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> As part of CASSANDRA-16895 initial POC an initial version of CCM patch was
> created. This needs to be revisited and reviewed
> Recently we closed CASSANDRA-18039 which brought questions, probably we need
> to revise how we detect JDK versions in CCM and whether it is correct. To the
> best of my knowledge there are certain tests in the repo around that and they
> pass so my guess is we need to revise just the strategy and maybe document it
> explicitly or consider if we want any changes to be applied. Also, we need to
> be careful with breaking changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18240) Using SELECT COUNT(*) FROM... LIMIT 1 in the returning section results in ClassCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-18240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690575#comment-17690575
]
Caleb Rackliffe commented on CASSANDRA-18240:
-
+1
> Using SELECT COUNT(*) FROM... LIMIT 1 in the returning section results in
> ClassCastException
>
>
> Key: CASSANDRA-18240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18240
> Project: Cassandra
> Issue Type: Bug
> Components: Accord
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
>
> {noformat}
> cqlsh>
> BEGIN TRANSACTION
> LET row1 = (SELECT * FROM ks.tbl1 WHERE k = 5);
> SELECT COUNT(*) FROM ks.tbl1 LIMIT 1;
> IF row1 IS NULL THEN
> INSERT INTO ks.tbl1 (k, v) VALUES (5, 10);
> END IF
> COMMIT TRANSACTION;
> NoHostAvailable: ('Unable to complete the operation against any hosts',
> {: error] message="java.lang.ClassCastException:
> org.apache.cassandra.db.PartitionRangeReadCommand cannot be cast to
> org.apache.cassandra.db.SinglePartitionReadQuery$Group">})
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690561#comment-17690561 ] Michael Semb Wever commented on CASSANDRA-18106: +1 > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17708) Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails
[ https://issues.apache.org/jira/browse/CASSANDRA-17708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-17708: -- Reviewers: Jon Meredith, Yifan Cai (was: Jon Meredith, Yifan Cai, Yifan Cai) > Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails > - > > Key: CASSANDRA-17708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17708 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.x > > Time Spent: 50m > Remaining Estimate: 0h > > testOutboundConnectionsAreRejectedWhenAuthFails was introduced in > CASSANDRA-17661 > It seems it was introduced flaky from the very beginning as per this run in a > loop - > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=flaky-testOutboundConnectionsAreRejectedWhenAuthFails&filter=all] > CC [~janaki.manchala] , [~jonmeredith], [~ycai] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17708) Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails
[ https://issues.apache.org/jira/browse/CASSANDRA-17708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-17708: -- Reviewers: Jon Meredith, Yifan Cai, Yifan Cai Status: Review In Progress (was: Patch Available) > Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails > - > > Key: CASSANDRA-17708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17708 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.x > > Time Spent: 50m > Remaining Estimate: 0h > > testOutboundConnectionsAreRejectedWhenAuthFails was introduced in > CASSANDRA-17661 > It seems it was introduced flaky from the very beginning as per this run in a > loop - > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=flaky-testOutboundConnectionsAreRejectedWhenAuthFails&filter=all] > CC [~janaki.manchala] , [~jonmeredith], [~ycai] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17708) Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails
[ https://issues.apache.org/jira/browse/CASSANDRA-17708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690555#comment-17690555 ] Yifan Cai commented on CASSANDRA-17708: --- Left some feedback in the PR and got addressed. +1 on the patch. > Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails > - > > Key: CASSANDRA-17708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17708 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Jyothsna Konisa >Priority: Normal > Fix For: 4.x > > Time Spent: 50m > Remaining Estimate: 0h > > testOutboundConnectionsAreRejectedWhenAuthFails was introduced in > CASSANDRA-17661 > It seems it was introduced flaky from the very beginning as per this run in a > loop - > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=flaky-testOutboundConnectionsAreRejectedWhenAuthFails&filter=all] > CC [~janaki.manchala] , [~jonmeredith], [~ycai] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maulin Vasavada reassigned CASSANDRA-18270:
---
Assignee: Maulin Vasavada
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690527#comment-17690527
]
Maulin Vasavada commented on CASSANDRA-18270:
-
[~smiklosovic] Sure, I should be able to take a look at this in the next week.
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18125) AssertionError on thread MemtableReclaimMemory in MemtablePool$SubPool.released(MemtablePool.java:193)
[
https://issues.apache.org/jira/browse/CASSANDRA-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-18125:
-
Bug Category: Parent values: Correctness(12982)Level 1 values: Recoverable
Corruption / Loss(12986)
Complexity: Challenging
Component/s: Local/Memtable
Discovered By: User Report
Fix Version/s: 4.0.x
4.1.x
4.x
Reviewers: Benjamin Lerer
Severity: Normal
Assignee: Benedict Elliott Smith
Status: Open (was: Triage Needed)
> AssertionError on thread MemtableReclaimMemory in
> MemtablePool$SubPool.released(MemtablePool.java:193)
> --
>
> Key: CASSANDRA-18125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18125
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Memtable
>Reporter: Nicolas Henneaux
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
>
> On two nodes (on a 5 nodes cluster) on the cluster I'm running, I got the
> following exception. It occurred at 3,5 minutes interval.
> {code}
> MemtableReclaimMemory:2625 org.apache.cassandra.service.CassandraDaemon
> uncaughtException - Exception in thread
> Thread[MemtableReclaimMemory:2625,5,main]java.lang.AssertionError: null
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.setDiscarded(SlabAllocator.java:120)
> at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:201)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> 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:829)
> {code}
> {code}
> $ nodetool info
> ID :
> Gossip active : true
> Native Transport active: true
> Load : 204.67 GiB
> Generation No : 1670343179
> Uptime (seconds) : 1110514
> Heap Memory (MB) : 7218.07 / 24576.00
> Off Heap Memory (MB) : 784.06
> Data Center: par
> Rack : e1
> Exceptions : 1
> Key Cache : entries 802712, size 100 MiB, capacity 100 MiB,
> 774541004 hits, 914207516 requests, 0.847 recent hit rate, 14400 save period
> in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0
> requests, NaN recent hit rate, 7200 save period in seconds
> Percent Repaired : 2.3272298419424144E-5%
> Token : (invoke with -T/--tokens to see all 8 tokens)
> $ java -version
> openjdk version "11.0.16" 2022-07-19 LTS
> OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build
> 11.0.16+8-LTS)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS,
> mixed mode, sharing)
> $ nodetool version
> ReleaseVersion: 4.0.6
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18125) AssertionError on thread MemtableReclaimMemory in MemtablePool$SubPool.released(MemtablePool.java:193)
[
https://issues.apache.org/jira/browse/CASSANDRA-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690519#comment-17690519
]
Benedict Elliott Smith commented on CASSANDRA-18125:
/cc [~blerer]
> AssertionError on thread MemtableReclaimMemory in
> MemtablePool$SubPool.released(MemtablePool.java:193)
> --
>
> Key: CASSANDRA-18125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18125
> Project: Cassandra
> Issue Type: Bug
>Reporter: Nicolas Henneaux
>Priority: Normal
>
> On two nodes (on a 5 nodes cluster) on the cluster I'm running, I got the
> following exception. It occurred at 3,5 minutes interval.
> {code}
> MemtableReclaimMemory:2625 org.apache.cassandra.service.CassandraDaemon
> uncaughtException - Exception in thread
> Thread[MemtableReclaimMemory:2625,5,main]java.lang.AssertionError: null
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.setDiscarded(SlabAllocator.java:120)
> at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:201)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> 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:829)
> {code}
> {code}
> $ nodetool info
> ID :
> Gossip active : true
> Native Transport active: true
> Load : 204.67 GiB
> Generation No : 1670343179
> Uptime (seconds) : 1110514
> Heap Memory (MB) : 7218.07 / 24576.00
> Off Heap Memory (MB) : 784.06
> Data Center: par
> Rack : e1
> Exceptions : 1
> Key Cache : entries 802712, size 100 MiB, capacity 100 MiB,
> 774541004 hits, 914207516 requests, 0.847 recent hit rate, 14400 save period
> in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0
> requests, NaN recent hit rate, 7200 save period in seconds
> Percent Repaired : 2.3272298419424144E-5%
> Token : (invoke with -T/--tokens to see all 8 tokens)
> $ java -version
> openjdk version "11.0.16" 2022-07-19 LTS
> OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build
> 11.0.16+8-LTS)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS,
> mixed mode, sharing)
> $ nodetool version
> ReleaseVersion: 4.0.6
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18125) AssertionError on thread MemtableReclaimMemory in MemtablePool$SubPool.released(MemtablePool.java:193)
[
https://issues.apache.org/jira/browse/CASSANDRA-18125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690518#comment-17690518
]
Benedict Elliott Smith commented on CASSANDRA-18125:
Ok, so the simulator has given us a nice reproduction, and has permitted us to
easily trace this back to CASSANDRA-15511. Specifically, we apply the same
{{retain}} calculation erroneously to _not yet inserted_ data, thereby
corrupting the memtable memory usage accounting.
Simple fix [here|https://github.com/apache/cassandra/pull/2169]
> AssertionError on thread MemtableReclaimMemory in
> MemtablePool$SubPool.released(MemtablePool.java:193)
> --
>
> Key: CASSANDRA-18125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18125
> Project: Cassandra
> Issue Type: Bug
>Reporter: Nicolas Henneaux
>Priority: Normal
>
> On two nodes (on a 5 nodes cluster) on the cluster I'm running, I got the
> following exception. It occurred at 3,5 minutes interval.
> {code}
> MemtableReclaimMemory:2625 org.apache.cassandra.service.CassandraDaemon
> uncaughtException - Exception in thread
> Thread[MemtableReclaimMemory:2625,5,main]java.lang.AssertionError: null
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.released(MemtablePool.java:193)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.releaseAll(MemtableAllocator.java:151)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.setDiscarded(MemtableAllocator.java:142)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator.setDiscarded(MemtableAllocator.java:93)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.setDiscarded(SlabAllocator.java:120)
> at org.apache.cassandra.db.Memtable.setDiscarded(Memtable.java:201)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush$1.runMayThrow(ColumnFamilyStore.java:1216)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> 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:829)
> {code}
> {code}
> $ nodetool info
> ID :
> Gossip active : true
> Native Transport active: true
> Load : 204.67 GiB
> Generation No : 1670343179
> Uptime (seconds) : 1110514
> Heap Memory (MB) : 7218.07 / 24576.00
> Off Heap Memory (MB) : 784.06
> Data Center: par
> Rack : e1
> Exceptions : 1
> Key Cache : entries 802712, size 100 MiB, capacity 100 MiB,
> 774541004 hits, 914207516 requests, 0.847 recent hit rate, 14400 save period
> in seconds
> Row Cache : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0
> requests, NaN recent hit rate, 7200 save period in seconds
> Percent Repaired : 2.3272298419424144E-5%
> Token : (invoke with -T/--tokens to see all 8 tokens)
> $ java -version
> openjdk version "11.0.16" 2022-07-19 LTS
> OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build
> 11.0.16+8-LTS)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS,
> mixed mode, sharing)
> $ nodetool version
> ReleaseVersion: 4.0.6
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690517#comment-17690517
]
Josh McKenzie commented on CASSANDRA-18134:
---
bq. can we conclude this discussion with some rules for the future so that we
will not have to go through that again and again whenever someone tries to do
something around the sstable versions?
Agree w/the caveat that I think the dev list is a better forum for this kind of
discussion + putting a bow on things from a UX perspective. Not everyone's
following JIRA notifications and even if you are, tracking these discussions
via JIRA comment updates in email has a very poor signal/noise ratio.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690514#comment-17690514
]
Aleksey Yeschenko commented on CASSANDRA-18134:
---
bq. Let me ask question as simple as possible: Can I merge it to trunk given CI
is OK?
Go for it.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690508#comment-17690508
]
Jacek Lewandowski commented on CASSANDRA-18134:
---
Aside of this ticket - can we conclude this discussion with some rules for the
future so that we will not have to go through that again and again whenever
someone tries to do something around the sstable versions? It can be really
frustrating when having a ticket somebody gets a feedback like "you should look
into discussions in x, y, z, ... (growing)", where each one is not conclusive
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (67005efe -> 3ace8206)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 67005efe generate docs for 8545a889 new 3ace8206 generate docs for 8545a889 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (67005efe) \ N -- N -- N refs/heads/asf-staging (3ace8206) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4796442 -> 4796442 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18271) Centralize all snapshot operations to SnapshotManager
[
https://issues.apache.org/jira/browse/CASSANDRA-18271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18271:
--
Description:
Currently, there is a lot of places where snapshotting logic is in place,
scattered across the codebase. We should centralize snapshotting logic under
SnapshotManager so every place in the code interacts only with that. This
should remove whole class of possible synchronization problems. Merely looking
into the code, all these methods are potentially unsafe.
{code:java}
public Map listSnapshots()
protected TableSnapshot buildSnapshot(String tag, SnapshotManifest manifest,
Set snapshotDirs) {
protected static SnapshotManifest maybeLoadManifest(String keyspace, String
table, String tag, Set snapshotDirs)
public List listEphemeralSnapshots()
private List listAllSnapshots()
protected Map> listSnapshotDirsByTag()
public boolean snapshotExists(String snapshotName)
public static void clearSnapshot(String snapshotName, List
tableDirectories, RateLimiter snapshotRateLimiter)
public static void removeSnapshotDirectory(RateLimiter snapshotRateLimiter,
File snapshotDir)
public long trueSnapshotsSize()
{code}
was:
Currently, there is a lot of places where snapshotting logic is in place,
scattered across the codebase. We should centralize snapshotting logic under
SnapshotManager so every place in the code interacts only with that. This
should remove whole class of possible synchronization problems. Merely looking
into the code, all these methods are potentially unsafe.
{code:java}
public Map listSnapshots()
protected TableSnapshot buildSnapshot(String tag, SnapshotManifest manifest,
Set snapshotDirs) {
protected static SnapshotManifest maybeLoadManifest(String keyspace, String
table, String tag, Set snapshotDirs)
public List listEphemeralSnapshots()
private List listAllSnapshots()
protected Map> listSnapshotDirsByTag()
public boolean snapshotExists(String snapshotName)
public static void clearSnapshot(String snapshotName, List
tableDirectories, RateLimiter snapshotRateLimiter)
public synchronized static void removeSnapshotDirectory(RateLimiter
snapshotRateLimiter, File snapshotDir)
public long trueSnapshotsSize()
{code}
> Centralize all snapshot operations to SnapshotManager
> -
>
> Key: CASSANDRA-18271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18271
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Snapshots
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> Currently, there is a lot of places where snapshotting logic is in place,
> scattered across the codebase. We should centralize snapshotting logic under
> SnapshotManager so every place in the code interacts only with that. This
> should remove whole class of possible synchronization problems. Merely
> looking into the code, all these methods are potentially unsafe.
> {code:java}
> public Map listSnapshots()
> protected TableSnapshot buildSnapshot(String tag, SnapshotManifest manifest,
> Set snapshotDirs) {
> protected static SnapshotManifest maybeLoadManifest(String keyspace, String
> table, String tag, Set snapshotDirs)
> public List listEphemeralSnapshots()
> private List listAllSnapshots()
> protected Map> listSnapshotDirsByTag()
> public boolean snapshotExists(String snapshotName)
> public static void clearSnapshot(String snapshotName, List
> tableDirectories, RateLimiter snapshotRateLimiter)
> public static void removeSnapshotDirectory(RateLimiter snapshotRateLimiter,
> File snapshotDir)
> public long trueSnapshotsSize()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18271) Centralize all snapshot operations to SnapshotManager
[
https://issues.apache.org/jira/browse/CASSANDRA-18271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18271:
--
Description:
Currently, there is a lot of places where snapshotting logic is in place,
scattered across the codebase. We should centralize snapshotting logic under
SnapshotManager so every place in the code interacts only with that. This
should remove whole class of possible synchronization problems. Merely looking
into the code, all these methods are potentially unsafe.
{code:java}
public Map listSnapshots()
protected TableSnapshot buildSnapshot(String tag, SnapshotManifest manifest,
Set snapshotDirs) {
protected static SnapshotManifest maybeLoadManifest(String keyspace, String
table, String tag, Set snapshotDirs)
public List listEphemeralSnapshots()
private List listAllSnapshots()
protected Map> listSnapshotDirsByTag()
public boolean snapshotExists(String snapshotName)
public static void clearSnapshot(String snapshotName, List
tableDirectories, RateLimiter snapshotRateLimiter)
public synchronized static void removeSnapshotDirectory(RateLimiter
snapshotRateLimiter, File snapshotDir)
public long trueSnapshotsSize()
{code}
was:
Currently, there is a lot of places where snapshotting logic is in place,
scattered across the codebase. We should centralize snapshotting logic under
SnapshotManager so every place in the code interacts only with that. This
should remove whole class of possible synchronization problems. Merely looking
into the code, these all methods are in potentially unsafe.
{code}
public Map listSnapshots()
protected TableSnapshot buildSnapshot(String tag, SnapshotManifest manifest,
Set snapshotDirs) {
protected static SnapshotManifest maybeLoadManifest(String keyspace, String
table, String tag, Set snapshotDirs)
public List listEphemeralSnapshots()
private List listAllSnapshots()
protected Map> listSnapshotDirsByTag()
public boolean snapshotExists(String snapshotName)
public static void clearSnapshot(String snapshotName, List
tableDirectories, RateLimiter snapshotRateLimiter)
public synchronized static void removeSnapshotDirectory(RateLimiter
snapshotRateLimiter, File snapshotDir)
public long trueSnapshotsSize()
{code}
> Centralize all snapshot operations to SnapshotManager
> -
>
> Key: CASSANDRA-18271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18271
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Snapshots
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> Currently, there is a lot of places where snapshotting logic is in place,
> scattered across the codebase. We should centralize snapshotting logic under
> SnapshotManager so every place in the code interacts only with that. This
> should remove whole class of possible synchronization problems. Merely
> looking into the code, all these methods are potentially unsafe.
> {code:java}
> public Map listSnapshots()
> protected TableSnapshot buildSnapshot(String tag, SnapshotManifest manifest,
> Set snapshotDirs) {
> protected static SnapshotManifest maybeLoadManifest(String keyspace, String
> table, String tag, Set snapshotDirs)
> public List listEphemeralSnapshots()
> private List listAllSnapshots()
> protected Map> listSnapshotDirsByTag()
> public boolean snapshotExists(String snapshotName)
> public static void clearSnapshot(String snapshotName, List
> tableDirectories, RateLimiter snapshotRateLimiter)
> public synchronized static void removeSnapshotDirectory(RateLimiter
> snapshotRateLimiter, File snapshotDir)
> public long trueSnapshotsSize()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18271) Centralize all snapshot operations to SnapshotManager
[
https://issues.apache.org/jira/browse/CASSANDRA-18271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18271:
--
Change Category: Code Clarity
Complexity: Challenging
Component/s: Local/Snapshots
Fix Version/s: 4.x
Status: Open (was: Triage Needed)
> Centralize all snapshot operations to SnapshotManager
> -
>
> Key: CASSANDRA-18271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18271
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Snapshots
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.x
>
>
> Currently, there is a lot of places where snapshotting logic is in place,
> scattered across the codebase. We should centralize snapshotting logic under
> SnapshotManager so every place in the code interacts only with that. This
> should remove whole class of possible synchronization problems. Merely
> looking into the code, these all methods are in potentially unsafe.
> {code}
> public Map listSnapshots()
> protected TableSnapshot buildSnapshot(String tag, SnapshotManifest manifest,
> Set snapshotDirs) {
> protected static SnapshotManifest maybeLoadManifest(String keyspace, String
> table, String tag, Set snapshotDirs)
> public List listEphemeralSnapshots()
> private List listAllSnapshots()
> protected Map> listSnapshotDirsByTag()
> public boolean snapshotExists(String snapshotName)
> public static void clearSnapshot(String snapshotName, List
> tableDirectories, RateLimiter snapshotRateLimiter)
> public synchronized static void removeSnapshotDirectory(RateLimiter
> snapshotRateLimiter, File snapshotDir)
> public long trueSnapshotsSize()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18271) Centralize all snapshot operations to SnapshotManager
Stefan Miklosovic created CASSANDRA-18271:
-
Summary: Centralize all snapshot operations to SnapshotManager
Key: CASSANDRA-18271
URL: https://issues.apache.org/jira/browse/CASSANDRA-18271
Project: Cassandra
Issue Type: Improvement
Reporter: Stefan Miklosovic
Assignee: Stefan Miklosovic
Currently, there is a lot of places where snapshotting logic is in place,
scattered across the codebase. We should centralize snapshotting logic under
SnapshotManager so every place in the code interacts only with that. This
should remove whole class of possible synchronization problems. Merely looking
into the code, these all methods are in potentially unsafe.
{code}
public Map listSnapshots()
protected TableSnapshot buildSnapshot(String tag, SnapshotManifest manifest,
Set snapshotDirs) {
protected static SnapshotManifest maybeLoadManifest(String keyspace, String
table, String tag, Set snapshotDirs)
public List listEphemeralSnapshots()
private List listAllSnapshots()
protected Map> listSnapshotDirsByTag()
public boolean snapshotExists(String snapshotName)
public static void clearSnapshot(String snapshotName, List
tableDirectories, RateLimiter snapshotRateLimiter)
public synchronized static void removeSnapshotDirectory(RateLimiter
snapshotRateLimiter, File snapshotDir)
public long trueSnapshotsSize()
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690482#comment-17690482
]
Josh McKenzie commented on CASSANDRA-18134:
---
bq. to write compatible stuff if a feature flag is off is more complex than
making sure we can write old version sstables
I've always found our "drop the previous version's ser/deser code like it's hot
and YOLO on to the new thing" stance on our various formats and versions
perplexing. Seems like it'd be minimal effort to keep at least n-1 version
writers around so we can better handle mixed version clusters (to allude to
Yuki's recent comment on CASSANDRA-8110), plus it'd arguably make the downgrade
process Claude's looking into a lot more straightforward and "native".
bq. Medium term, 5 is probably preferable
I agree w/this sentiment; adding a 3rd token to the versioning that we can
increment in minors as needed is the most flexible and "reality-complimentary"
design of the ones listed above IMO.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18012) Remove -l / -m / -h designation and have two options: free or paid tier circle config
[ https://issues.apache.org/jira/browse/CASSANDRA-18012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690476#comment-17690476 ] Josh McKenzie commented on CASSANDRA-18012: --- Left some comments on the PR. There's been some niggling curiosities I've had about file naming, workflow, etc for awhile that intersect w/the changes here; figure it's worth getting some clarity. > Remove -l / -m / -h designation and have two options: free or paid tier > circle config > - > > Key: CASSANDRA-18012 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18012 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Josh McKenzie >Assignee: Andres de la Peña >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Currently the -h designation is wasteful and should not be used, and the -f > designation won't actually successfully run to completion. > We should default to a "free tier" config (probably print a warning that it's > generating config w/subset of full tests that should not be used to validate > commits in big warning letters) that runs a subset of the test suites for > users working on patches to validate their work (unit test only? unit + > in-jvm dtest? TBD), and add a flag to generate a config using larger > containers + parallelization for the "paid" tier for folks w/paid circleci > accounts., > It looks like -p is available right now fwiw. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17561) Diagnostic snapshot service should only snapshot mismatching ranges on preview repair mismatch
[ https://issues.apache.org/jira/browse/CASSANDRA-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690474#comment-17690474 ] Stefan Miklosovic commented on CASSANDRA-17561: --- Why do we want to know what ranges that snapshot covers? What is the use case? > Diagnostic snapshot service should only snapshot mismatching ranges on > preview repair mismatch > -- > > Key: CASSANDRA-17561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17561 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 50m > Remaining Estimate: 0h > > We currently snapshot all sstables in a table when a preview repair mismatch > occurs, we should only snapshot the sstables containing the mismatching ranges -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18270) ssl-factory demo in examples is broken
Stefan Miklosovic created CASSANDRA-18270:
-
Summary: ssl-factory demo in examples is broken
Key: CASSANDRA-18270
URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
Project: Cassandra
Issue Type: Bug
Reporter: Stefan Miklosovic
this fails, it is not happening in cassandra-4.1
{code}
cd examples/ssl-factory
ant build && ant test
{code}
My suspicion is that SSL factory related stuff was recently changed, in trunk,
by (1) and this broke related ssl test.
[~maulin.vasavada] do you have some time to look into that as you are the
author of the tests? I think I fixed the most of it here (2) but one test is
still failing and I can not wrap my head around that one. It gives:
{code}
[junit] Testcase:
buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
Caused an ERROR
[junit] Failed to build key manager store for secure connections
[junit] javax.net.ssl.SSLException: Failed to build key manager store for
secure connections
[junit] at
org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
[junit] at
org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
[junit] at
org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
[junit] at
org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
[junit] Caused by: java.io.IOException: overrun, bytes = 1195
[junit] at
javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
[junit] at
org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
[junit] at
org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
[junit] at
org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
{code}
(1)
https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
(2) https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17561) Diagnostic snapshot service should only snapshot mismatching ranges on preview repair mismatch
[ https://issues.apache.org/jira/browse/CASSANDRA-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690467#comment-17690467 ] Paulo Motta commented on CASSANDRA-17561: - Currently the snapshots semantics is that it will snapshot all ranges for a node. If we're snapshotting a subset of ranges, should we include the ranges snapshotted in the snapshot manifest json? > Diagnostic snapshot service should only snapshot mismatching ranges on > preview repair mismatch > -- > > Key: CASSANDRA-17561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17561 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 50m > Remaining Estimate: 0h > > We currently snapshot all sstables in a table when a preview repair mismatch > occurs, we should only snapshot the sstables containing the mismatching ranges -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690466#comment-17690466
]
Branimir Lambov edited comment on CASSANDRA-18134 at 2/17/23 4:05 PM:
--
Isn't this more difficult than properly dealing with the problem? We have
always had the functionality to read old version sstables, and to write
compatible stuff if a feature flag is off is more complex than making sure we
can write old version sstables. In fact, for this ticket (and anything else
that touches metadata alone) the necessary code is already present.
was (Author: blambov):
Isn't this more difficult than properly dealing with the problem? We have
always had the functionality to read old version sstables, and to write
compatible stuff if a feature flag is off is more complex than making sure we
can write old version sstables. In fact, for this ticket the necessary code is
already present.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690466#comment-17690466
]
Branimir Lambov commented on CASSANDRA-18134:
-
Isn't this more difficult than properly dealing with the problem? We have
always had the functionality to read old version sstables, and to write
compatible stuff if a feature flag is off is more complex than making sure we
can write old version sstables. In fact, for this ticket the necessary code is
already present.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17561) Diagnostic snapshot service should only snapshot mismatching ranges on preview repair mismatch
[ https://issues.apache.org/jira/browse/CASSANDRA-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690465#comment-17690465 ] Stefan Miklosovic commented on CASSANDRA-17561: --- Thanks [~samt], suggested changes are reflected in the PR. I am running the builds here j11 pre-commit https://app.circleci.com/pipelines/github/instaclustr/cassandra/1924/workflows/acdabb89-e938-4e69-bae5-c40285c0d355 j8 pre-commit https://app.circleci.com/pipelines/github/instaclustr/cassandra/1924/workflows/c684507f-259b-4df9-b3d6-c0f8db24b4ab > Diagnostic snapshot service should only snapshot mismatching ranges on > preview repair mismatch > -- > > Key: CASSANDRA-17561 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17561 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 50m > Remaining Estimate: 0h > > We currently snapshot all sstables in a table when a preview repair mismatch > occurs, we should only snapshot the sstables containing the mismatching ranges -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18264) CustomClassLoader does not load jars rendering triggers from JARs broken
[ https://issues.apache.org/jira/browse/CASSANDRA-18264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18264: - Reviewers: Brandon Williams (was: Brandon Williams, Stefan Miklosovic) > CustomClassLoader does not load jars rendering triggers from JARs broken > > > Key: CASSANDRA-18264 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18264 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1.1, 4.2 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > A user had to downgrade to 4.0.7 from 4.1.0 because they hit a problem with > CustomClassLoader for triggers. > User says that in Apache Cassandra 4.1.0 the trigger mechanism does not work, > not their trigger, but the possibility of loading any trigger in Cassandra. > In the Cassandra 4.1.0 version of CustomClassLoader > (https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/triggers/CustomClassLoader.java) > the code is changed in such a way that when copying the JAR Cassandra uses > java.nio.file.Files, while earlier versions (cassandra 4.0.X or 3.X) used > Guava com.google.common.io.Files to copy the JAR file. > The difference between one and the other is that Guava by default overwrites > the file if it already exists and user has permissions to do so, and in Java > by default it does not overwrite. > Copying is done here (1) from inputJar to out. However, the problem is that > we are getting temporary file from here (2) and the implementation loops > unless it succeeds to create an empty file. (3) - But that fails to copy the > file to out because copying does not work when the target file already exists. > (1) > https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/triggers/CustomClassLoader.java#L86 > (2) > https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/triggers/CustomClassLoader.java#L81 > (3) > https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/io/util/FileUtils.java#L152 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18264) CustomClassLoader does not load jars rendering triggers from JARs broken
[ https://issues.apache.org/jira/browse/CASSANDRA-18264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18264: -- Fix Version/s: 4.1.1 4.2 (was: 4.x) (was: 4.1.x) Since Version: 4.1-alpha1 Source Control Link: https://github.com/apache/cassandra/commit/9860c1e9d9fb45342fa674782ecd135cf6875943 Resolution: Fixed Status: Resolved (was: Ready to Commit) > CustomClassLoader does not load jars rendering triggers from JARs broken > > > Key: CASSANDRA-18264 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18264 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1.1, 4.2 > > Time Spent: 1.5h > Remaining Estimate: 0h > > A user had to downgrade to 4.0.7 from 4.1.0 because they hit a problem with > CustomClassLoader for triggers. > User says that in Apache Cassandra 4.1.0 the trigger mechanism does not work, > not their trigger, but the possibility of loading any trigger in Cassandra. > In the Cassandra 4.1.0 version of CustomClassLoader > (https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/triggers/CustomClassLoader.java) > the code is changed in such a way that when copying the JAR Cassandra uses > java.nio.file.Files, while earlier versions (cassandra 4.0.X or 3.X) used > Guava com.google.common.io.Files to copy the JAR file. > The difference between one and the other is that Guava by default overwrites > the file if it already exists and user has permissions to do so, and in Java > by default it does not overwrite. > Copying is done here (1) from inputJar to out. However, the problem is that > we are getting temporary file from here (2) and the implementation loops > unless it succeeds to create an empty file. (3) - But that fails to copy the > file to out because copying does not work when the target file already exists. > (1) > https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/triggers/CustomClassLoader.java#L86 > (2) > https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/triggers/CustomClassLoader.java#L81 > (3) > https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/io/util/FileUtils.java#L152 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (cfe9641fbe -> 9860c1e9d9)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from cfe9641fbe Fix possible NoSuchFileException when removing a snapshot add 9860c1e9d9 Fix copying of JAR of a trigger to temporary file No new revisions were added by this update. Summary of changes: .gitignore | 2 + CHANGES.txt| 1 + examples/ssl-factory/README.adoc | 22 examples/ssl-factory/README.txt| 19 --- .../KubernetesSecretsSslContextFactoryTest.java| 4 +- examples/triggers/README.adoc | 63 ++ examples/triggers/README.txt | 36 - examples/triggers/build.xml| 5 ++ .../apache/cassandra/triggers/AuditTrigger.java| 22 +--- ide/idea/workspace.xml | 1 + .../cassandra/triggers/CustomClassLoader.java | 11 ++-- 11 files changed, 116 insertions(+), 70 deletions(-) create mode 100644 examples/ssl-factory/README.adoc delete mode 100644 examples/ssl-factory/README.txt create mode 100644 examples/triggers/README.adoc delete mode 100644 examples/triggers/README.txt - 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.1' into trunk
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 9a08062f1bf12b745b755f72a290af359d8bfeee Merge: 8d54835d5b 9860c1e9d9 Author: Stefan Miklosovic AuthorDate: Fri Feb 17 16:38:44 2023 +0100 Merge branch 'cassandra-4.1' into trunk .gitignore | 2 + CHANGES.txt| 1 + examples/ssl-factory/README.adoc | 22 examples/ssl-factory/README.txt| 19 --- examples/triggers/README.adoc | 63 ++ examples/triggers/README.txt | 36 - examples/triggers/build.xml| 5 ++ .../apache/cassandra/triggers/AuditTrigger.java| 22 +--- ide/idea/workspace.xml | 2 +- .../cassandra/triggers/CustomClassLoader.java | 11 ++-- 10 files changed, 114 insertions(+), 69 deletions(-) diff --cc CHANGES.txt index 76f6d41c83,1ca7c2f89a..deb3a64a23 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,111 -1,5 +1,112 @@@ -4.1.1 +4.2 + * Prepare for JDK17 experimental support (CASSANDRA-18179) + * Remove Scripted UDFs internals; hooks to be added later in CASSANDRA-17281 (CASSANDRA-18252) + * Update JNA to 5.13.0 (CASSANDRA-18050) + * Make virtual tables decide if they implicitly enable ALLOW FILTERING (CASSANDRA-18238) + * Add row, tombstone, and sstable count to nodetool profileload (CASSANDRA-18022) + * Coordinator level metrics for read response and mutation row and column counts (CASSANDRA-18155) + * Add CQL functions for dynamic data masking (CASSANDRA-17941) + * Print friendly error when nodetool attempts to connect to uninitialized server (CASSANDRA-11537) + * Use G1GC by default, and update default G1GC settings (CASSANDRA-18027) + * SimpleSeedProvider can resolve multiple IP addresses per DNS record (CASSANDRA-14361) + * Remove mocking in InternalNodeProbe spying on StorageServiceMBean (CASSANDRA-18152) + * Add compaction_properties column to system.compaction_history table and nodetool compactionhistory command (CASSANDRA-18061) + * Remove ProtocolVersion entirely from the CollectionSerializer ecosystem (CASSANDRA-18114) + * Fix serialization error in new getsstables --show-levels option (CASSANDRA-18140) + * Use checked casts when reading vints as ints (CASSANDRA-18099) + * Add Mutation Serialization Caching (CASSANDRA-17998) + * Only reload compaction strategies if disk boundaries change (CASSANDRA-17874) + * CEP-10: Simulator Java11 Support (CASSANDRA-17178) + * Set the major compaction type correctly for compactionstats (CASSANDRA-18055) + * Print exception message without stacktrace when nodetool commands fail on probe.getOwnershipWithPort() (CASSANDRA-18079) + * Add option to print level in nodetool getsstables output (CASSANDRA-18023) + * Implement a guardrail for not having zero default_time_to_live on tables with TWCS (CASSANDRA-18042) + * Add CQL scalar functions for collection aggregation (CASSANDRA-18060) + * Make cassandra.replayList property for CommitLogReplayer possible to react on keyspaces only (CASSANDRA-18044) + * Add Mathematical functions (CASSANDRA-17221) + * Make incremental backup configurable per table (CASSANDRA-15402) + * Change shebangs of Python scripts to resolve Python 3 from env command (CASSANDRA-17832) + * Add reasons to guardrail messages and consider guardrails in the error message for needed ALLOW FILTERING (CASSANDRA-17967) + * Add support for CQL functions on collections, tuples and UDTs (CASSANDRA-17811) + * Add flag to exclude nodes from local DC when running nodetool rebuild (CASSANDRA-17870) + * Adding endpoint verification option to client_encryption_options (CASSANDRA-18034) + * Replace 'wcwidth.py' with pypi module (CASSANDRA-17287) + * Add nodetool forcecompact to remove tombstoned or ttl'd data ignoring GC grace for given table and partition keys (CASSANDRA-17711) + * Offer IF (NOT) EXISTS in cqlsh completion for CREATE TYPE, DROP TYPE, CREATE ROLE and DROP ROLE (CASSANDRA-16640) + * Nodetool bootstrap resume will now return an error if the operation fails (CASSANDRA-16491) + * Disable resumable bootstrap by default (CASSANDRA-17679) + * Include Git SHA in --verbose flag for nodetool version (CASSANDRA-17753) + * Update Byteman to 4.0.20 and Jacoco to 0.8.8 (CASSANDRA-16413) + * Add memtable option among possible tab completions for a table (CASSANDRA-17982) + * Adds a trie-based memtable implementation (CASSANDRA-17240) + * Further improves precision of memtable heap tracking (CASSANDRA-17240) + * Fix formatting of metrics documentation (CASSANDRA-17961) + * Keep sstable level when streaming for decommission and move (CASSANDRA-17969) + * Add Unavailables metric for CASWrite in the docs (CASSANDRA-16357) + * Make Cass
[cassandra] branch trunk updated (8d54835d5b -> 9a08062f1b)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 8d54835d5b Merge branch 'cassandra-4.1' into trunk add 9860c1e9d9 Fix copying of JAR of a trigger to temporary file new 9a08062f1b Merge branch 'cassandra-4.1' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .gitignore | 2 + CHANGES.txt| 1 + examples/ssl-factory/README.adoc | 22 examples/ssl-factory/README.txt| 19 --- examples/triggers/README.adoc | 63 ++ examples/triggers/README.txt | 36 - examples/triggers/build.xml| 5 ++ .../apache/cassandra/triggers/AuditTrigger.java| 22 +--- ide/idea/workspace.xml | 2 +- .../cassandra/triggers/CustomClassLoader.java | 11 ++-- 10 files changed, 114 insertions(+), 69 deletions(-) create mode 100644 examples/ssl-factory/README.adoc delete mode 100644 examples/ssl-factory/README.txt create mode 100644 examples/triggers/README.adoc delete mode 100644 examples/triggers/README.txt - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690459#comment-17690459
]
Benedict Elliott Smith commented on CASSANDRA-18134:
It’s 100% compatible until you flip the switch to support longer TTLs. I’d be
fine in that case upgrading to oa for clusters writing incompatible TTLs, but
nc while writing compatible ones
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690455#comment-17690455
]
Branimir Lambov commented on CASSANDRA-18134:
-
Is the current format, after the TTL changes and things like CASSANDRA-17698,
really compatible with 4.1? What if a user is applying a TTL of 20 years that
was capped and immediately becomes an invalid value on upgrade to 5.0?
I see that downgradability is necessary, but the current discussion is one of
whether we can delay dealing with it by introducing serious risks and knowingly
not dealing with problems. We should instead invest in CASSANDRA-8110.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18264) CustomClassLoader does not load jars rendering triggers from JARs broken
[ https://issues.apache.org/jira/browse/CASSANDRA-18264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18264: -- Status: Ready to Commit (was: Review In Progress) > CustomClassLoader does not load jars rendering triggers from JARs broken > > > Key: CASSANDRA-18264 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18264 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1.x, 4.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > A user had to downgrade to 4.0.7 from 4.1.0 because they hit a problem with > CustomClassLoader for triggers. > User says that in Apache Cassandra 4.1.0 the trigger mechanism does not work, > not their trigger, but the possibility of loading any trigger in Cassandra. > In the Cassandra 4.1.0 version of CustomClassLoader > (https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/triggers/CustomClassLoader.java) > the code is changed in such a way that when copying the JAR Cassandra uses > java.nio.file.Files, while earlier versions (cassandra 4.0.X or 3.X) used > Guava com.google.common.io.Files to copy the JAR file. > The difference between one and the other is that Guava by default overwrites > the file if it already exists and user has permissions to do so, and in Java > by default it does not overwrite. > Copying is done here (1) from inputJar to out. However, the problem is that > we are getting temporary file from here (2) and the implementation loops > unless it succeeds to create an empty file. (3) - But that fails to copy the > file to out because copying does not work when the target file already exists. > (1) > https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/triggers/CustomClassLoader.java#L86 > (2) > https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/triggers/CustomClassLoader.java#L81 > (3) > https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/io/util/FileUtils.java#L152 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18264) CustomClassLoader does not load jars rendering triggers from JARs broken
[ https://issues.apache.org/jira/browse/CASSANDRA-18264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18264: -- Reviewers: Brandon Williams, Stefan Miklosovic (was: Brandon Williams) Status: Review In Progress (was: Patch Available) > CustomClassLoader does not load jars rendering triggers from JARs broken > > > Key: CASSANDRA-18264 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18264 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.1.x, 4.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > A user had to downgrade to 4.0.7 from 4.1.0 because they hit a problem with > CustomClassLoader for triggers. > User says that in Apache Cassandra 4.1.0 the trigger mechanism does not work, > not their trigger, but the possibility of loading any trigger in Cassandra. > In the Cassandra 4.1.0 version of CustomClassLoader > (https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/triggers/CustomClassLoader.java) > the code is changed in such a way that when copying the JAR Cassandra uses > java.nio.file.Files, while earlier versions (cassandra 4.0.X or 3.X) used > Guava com.google.common.io.Files to copy the JAR file. > The difference between one and the other is that Guava by default overwrites > the file if it already exists and user has permissions to do so, and in Java > by default it does not overwrite. > Copying is done here (1) from inputJar to out. However, the problem is that > we are getting temporary file from here (2) and the implementation loops > unless it succeeds to create an empty file. (3) - But that fails to copy the > file to out because copying does not work when the target file already exists. > (1) > https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/triggers/CustomClassLoader.java#L86 > (2) > https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/triggers/CustomClassLoader.java#L81 > (3) > https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/io/util/FileUtils.java#L152 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690449#comment-17690449
]
Benedict Elliott Smith commented on CASSANDRA-18134:
You can't just wave that period away, at minimum they were the 3.x series,
which was maintained in a separate track to 3.0.
You missed: (6) we support a flag, either via some boolean or a general bit
flag field, indicating whether the new information is present.
This is my preferred approach in general, as it requires ~zero effort to
support in earlier releases, though by default we should not implement it in
earlier releases.
But I would accept 2, 3 or 5. Medium term, 5 is probably preferable. It should
be able to cleanly track our product release versioning.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690443#comment-17690443
]
Michael Semb Wever commented on CASSANDRA-18134:
[~benedict],
I had indeed forgotten about tick-tocks. But I don't think they serve the
discussion well, as the ticks were not maintained branches off the tocks.
It sounds like you accept either (2), (3), or (5).
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690437#comment-17690437 ] Brandon Williams commented on CASSANDRA-18106: -- Testing on older branches to ensure nothing broke: ||Branch||CI|| |[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18106-3.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/861/workflows/7c29fe94-dbf4-42eb-ab01-f010259f2f2d]| |[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-18106-3.11]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/862/workflows/40e324e2-42b8-49d1-b15a-36d644d306a2]| |[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-18106-4.0]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/859/workflows/d4c4d4e1-72be-426a-b74e-9f67682d4e20], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/859/workflows/8c4a4db1-eae0-43f6-9480-2f118e8988b9]| |[4.1|https://github.com/driftx/cassandra/tree/CASSANDRA-18106-4.1]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/860/workflows/05c06d65-9ae5-461c-a0df-e6f900c5d202], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/860/workflows/b7ebdda7-451a-486c-adb4-8908a8ff9124]| > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18211) NoSuchFileException when removing a snapshot
[
https://issues.apache.org/jira/browse/CASSANDRA-18211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18211:
--
Fix Version/s: 4.1.1
4.2
(was: 4.x)
(was: 4.1.x)
Since Version: 4.1.0
Source Control Link:
https://github.com/apache/cassandra/commit/cfe9641fbec0dc62c9a0f4f156c702e2cfa6ad4e
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> NoSuchFileException when removing a snapshot
> -
>
> Key: CASSANDRA-18211
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18211
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Jacek Lewandowski
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.1, 4.2
>
>
> Automatic deletion of expired snapshots maintained by {{SnapshotManager}} can
> race with manual snapshot removal in a way an exception like
> {{NoSuchFileException}} is thrown.
> It is because the snapshot directory existence is checked and deleted if it
> exists as a non-atomic operation. Since we can potentially have two threads
> attempting to do that at the same time (automatic and manual snapshot
> removal) it may lead to a race in rare situations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18211) NoSuchFileException when removing a snapshot
[
https://issues.apache.org/jira/browse/CASSANDRA-18211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18211:
--
Reviewers: Jacek Lewandowski (was: Jacek Lewandowski, Stefan Miklosovic)
> NoSuchFileException when removing a snapshot
> -
>
> Key: CASSANDRA-18211
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18211
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Jacek Lewandowski
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.1, 4.2
>
>
> Automatic deletion of expired snapshots maintained by {{SnapshotManager}} can
> race with manual snapshot removal in a way an exception like
> {{NoSuchFileException}} is thrown.
> It is because the snapshot directory existence is checked and deleted if it
> exists as a non-atomic operation. Since we can potentially have two threads
> attempting to do that at the same time (automatic and manual snapshot
> removal) it may lead to a race in rare situations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 8d54835d5b84f8afe1e97be65f8cc1897b0a9c5f Merge: d7352209b2 cfe9641fbe Author: Stefan Miklosovic AuthorDate: Fri Feb 17 15:44:17 2023 +0100 Merge branch 'cassandra-4.1' into trunk CHANGES.txt| 1 + src/java/org/apache/cassandra/db/Directories.java | 6 +- .../org/apache/cassandra/io/util/FileUtils.java| 12 ++ .../apache/cassandra/service/StorageService.java | 20 +-- .../cassandra/service/snapshot/SnapshotLoader.java | 152 +++-- .../service/snapshot/SnapshotManager.java | 53 +++ .../cassandra/distributed/impl/Instance.java | 1 + .../cassandra/distributed/test/SnapshotsTest.java | 55 .../service/snapshot/SnapshotLoaderTest.java | 2 +- .../service/snapshot/SnapshotManagerTest.java | 82 +-- 10 files changed, 242 insertions(+), 142 deletions(-) diff --cc CHANGES.txt index 1b90fee599,decc10dd72..76f6d41c83 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,111 -1,5 +1,112 @@@ -4.1.1 +4.2 + * Prepare for JDK17 experimental support (CASSANDRA-18179) + * Remove Scripted UDFs internals; hooks to be added later in CASSANDRA-17281 (CASSANDRA-18252) + * Update JNA to 5.13.0 (CASSANDRA-18050) + * Make virtual tables decide if they implicitly enable ALLOW FILTERING (CASSANDRA-18238) + * Add row, tombstone, and sstable count to nodetool profileload (CASSANDRA-18022) + * Coordinator level metrics for read response and mutation row and column counts (CASSANDRA-18155) + * Add CQL functions for dynamic data masking (CASSANDRA-17941) + * Print friendly error when nodetool attempts to connect to uninitialized server (CASSANDRA-11537) + * Use G1GC by default, and update default G1GC settings (CASSANDRA-18027) + * SimpleSeedProvider can resolve multiple IP addresses per DNS record (CASSANDRA-14361) + * Remove mocking in InternalNodeProbe spying on StorageServiceMBean (CASSANDRA-18152) + * Add compaction_properties column to system.compaction_history table and nodetool compactionhistory command (CASSANDRA-18061) + * Remove ProtocolVersion entirely from the CollectionSerializer ecosystem (CASSANDRA-18114) + * Fix serialization error in new getsstables --show-levels option (CASSANDRA-18140) + * Use checked casts when reading vints as ints (CASSANDRA-18099) + * Add Mutation Serialization Caching (CASSANDRA-17998) + * Only reload compaction strategies if disk boundaries change (CASSANDRA-17874) + * CEP-10: Simulator Java11 Support (CASSANDRA-17178) + * Set the major compaction type correctly for compactionstats (CASSANDRA-18055) + * Print exception message without stacktrace when nodetool commands fail on probe.getOwnershipWithPort() (CASSANDRA-18079) + * Add option to print level in nodetool getsstables output (CASSANDRA-18023) + * Implement a guardrail for not having zero default_time_to_live on tables with TWCS (CASSANDRA-18042) + * Add CQL scalar functions for collection aggregation (CASSANDRA-18060) + * Make cassandra.replayList property for CommitLogReplayer possible to react on keyspaces only (CASSANDRA-18044) + * Add Mathematical functions (CASSANDRA-17221) + * Make incremental backup configurable per table (CASSANDRA-15402) + * Change shebangs of Python scripts to resolve Python 3 from env command (CASSANDRA-17832) + * Add reasons to guardrail messages and consider guardrails in the error message for needed ALLOW FILTERING (CASSANDRA-17967) + * Add support for CQL functions on collections, tuples and UDTs (CASSANDRA-17811) + * Add flag to exclude nodes from local DC when running nodetool rebuild (CASSANDRA-17870) + * Adding endpoint verification option to client_encryption_options (CASSANDRA-18034) + * Replace 'wcwidth.py' with pypi module (CASSANDRA-17287) + * Add nodetool forcecompact to remove tombstoned or ttl'd data ignoring GC grace for given table and partition keys (CASSANDRA-17711) + * Offer IF (NOT) EXISTS in cqlsh completion for CREATE TYPE, DROP TYPE, CREATE ROLE and DROP ROLE (CASSANDRA-16640) + * Nodetool bootstrap resume will now return an error if the operation fails (CASSANDRA-16491) + * Disable resumable bootstrap by default (CASSANDRA-17679) + * Include Git SHA in --verbose flag for nodetool version (CASSANDRA-17753) + * Update Byteman to 4.0.20 and Jacoco to 0.8.8 (CASSANDRA-16413) + * Add memtable option among possible tab completions for a table (CASSANDRA-17982) + * Adds a trie-based memtable implementation (CASSANDRA-17240) + * Further improves precision of memtable heap tracking (CASSANDRA-17240) + * Fix formatting of metrics documentation (CASSANDRA-17961) + * Keep sstable level when streaming for decommission and move (CASSANDRA-17969) + * Add Unavailables metric for CASWrite in the docs (CASSANDRA-16357) + * Make Cas
[cassandra] branch trunk updated (d7352209b2 -> 8d54835d5b)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from d7352209b2 ninja-fix: compile and use JdkProperties add cfe9641fbe Fix possible NoSuchFileException when removing a snapshot new 8d54835d5b Merge branch 'cassandra-4.1' into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + src/java/org/apache/cassandra/db/Directories.java | 6 +- .../org/apache/cassandra/io/util/FileUtils.java| 12 ++ .../apache/cassandra/service/StorageService.java | 20 +-- .../cassandra/service/snapshot/SnapshotLoader.java | 152 +++-- .../service/snapshot/SnapshotManager.java | 53 +++ .../cassandra/distributed/impl/Instance.java | 1 + .../cassandra/distributed/test/SnapshotsTest.java | 55 .../service/snapshot/SnapshotLoaderTest.java | 2 +- .../service/snapshot/SnapshotManagerTest.java | 82 +-- 10 files changed, 242 insertions(+), 142 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (b728a0011b -> cfe9641fbe)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git from b728a0011b Merge branch 'cassandra-4.0' into cassandra-4.1 add cfe9641fbe Fix possible NoSuchFileException when removing a snapshot No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + src/java/org/apache/cassandra/db/Directories.java | 6 +- .../org/apache/cassandra/io/util/FileUtils.java| 12 ++ .../apache/cassandra/service/StorageService.java | 12 +- .../cassandra/service/snapshot/SnapshotLoader.java | 152 +++-- .../service/snapshot/SnapshotManager.java | 51 --- .../cassandra/distributed/impl/Instance.java | 1 + .../cassandra/distributed/test/SnapshotsTest.java | 55 .../service/snapshot/SnapshotLoaderTest.java | 2 +- .../service/snapshot/SnapshotManagerTest.java | 106 +- 10 files changed, 237 insertions(+), 161 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690435#comment-17690435
]
Benedict Elliott Smith commented on CASSANDRA-18134:
During tick-tock, the 3.x series where x > 0 were considered (at least) one
"major" version ahead of the 3.0 line, and format changes did not trigger a
change in major format version.
All prior format changes that coincided with a major version bump were
_incompatible_ changes. This is the relevant pattern: a major format bump may
_only_ happen across a major version, and _must_ happen when an incompatible
format change is made. This is our "current practice" and it therefore supports
maintaining the n series of versions here, as the change is not incompatible.
Regarding your concerns, there is a simple solution: write a boolean to the end
of the relevant file indicating if the additional metadata is there. When
necessary, 4.x can write "no" and continue to produce valid -n?- files, should
we have to release a patch.
Or, we can support patch versions in the sstable format - there's literally
nothing stopping us doing this today, the patterns we use already support it.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690434#comment-17690434
]
Benedict Elliott Smith commented on CASSANDRA-18134:
bq. Can I merge it to trunk given CI is OK?
I've no qualms merging with NC.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690433#comment-17690433
]
Jacek Lewandowski edited comment on CASSANDRA-18134 at 2/17/23 2:52 PM:
# Branimir reviewed that, I got +1 from him
# Applied the changes to make this NC, so all 4.x will be able to read it
regardless whether it lands in 4.x or trunk
# I want to merge it to trunk - if we decide to use OA, we can make that
decision right before releasing trunk
Let me ask question as simple as possible: Can I merge it to trunk given CI is
OK?
was (Author: jlewandowski):
Let me ask question as simple as possible:
1. Branimir reviewed that, I got +1 from him
2. Applied the changes to make this NC, so all 4.x will be able to read it
regardless whether it lands in 4.x or trunk
3. I want to merge it to trunk - if we decide to use OA, we can make that
decision right before releasing trunk
4. Can I merge given CI is OK?
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690433#comment-17690433
]
Jacek Lewandowski commented on CASSANDRA-18134:
---
Let me ask question as simple as possible:
1. Branimir reviewed that, I got +1 from him
2. Applied the changes to make this NC, so all 4.x will be able to read it
regardless whether it lands in 4.x or trunk
3. I want to merge it to trunk - if we decide to use OA, we can make that
decision right before releasing trunk
4. Can I merge given CI is OK?
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690430#comment-17690430
]
Michael Semb Wever edited comment on CASSANDRA-18134 at 2/17/23 2:46 PM:
-
So, for the sake of discussion: because the only precedence we have today (look
at BigFormat's history) is any format bump in a major version has always been a
major format change; if we are to bump trunk to {{\-nc\-}} the problem scenario
I raise has (at least) the five following possibilities:
1. Release branches for 4.0 and 4.1 are fixed to {{\-nb\-}}. No format changes
are permitted.
2. Any eventual format change on 4.0 or 4.1 requires first back-porting (all or
some minimal support of) the {{\-nc\-}} change, with the new change happening
in {{\-nd\-}}. (Aleksey's comment directly above.)
3. Some minimal version of the {{\-nc\-}} is committed to 4.0 and 4.1 branches
now. (Aleksey's comment two above.)
4. Reserve some sequence of minor versions for 4.0 and 4.1 branches, e.g. this
change goes into trunk as {{\-nn\-}}
5. Introduce double-character minor formats. So an eventual format change in
4.0 or 4.1 would be {{\-nba\-}}
All of these are painful IMHO. (1) shoots our foot off. (2) is tech debt and
introduces risk on release branches (think about needing a CVE patch quickly
and this getting in the way). It is unclear if (4) is currently possible
(though we do something similar with verbs). And (5) is just yuck, introducing
something new on a release branch, which itself is an API breakage.
I'm still in favour of this patch landing in trunk with {{\-oa\-}} as the
simplest solution. A major format change (even if superficial) aligned with a
major release is our current practice and what user's expect and know to deal
with. We can do better, and [~yukim] proposes a solution that is much aligned
with [~cscotta] in CASSANDRA-8110, but let's not block this ticket on that work.
was (Author: michaelsembwever):
So, for the sake of discussion: because the only precedence we have today (look
at BigFormat's history) is any format bump in a major version has always been a
major format change; if we are to bump trunk to {{\-nc\-}} the problem scenario
I raise has (at least) the five following possibilities:
1. Release branches for 4.0 and 4.1 are fixed to {{\-nb\-}}. No format changes
are permitted.
2. Any eventual format change on 4.0 or 4.1 requires first back-porting (all or
some minimal support of) the {{\-nc\-}} change, with the new change happening
in {{\-nd\-}}. (Aleksey's comment directly above.)
3. Some minimal version of the {{\-nc\-}} is committed to 4.0 and 4.1 branches
now. (Aleksey's comment two above.)
4. Reserve some sequence of minor versions for 4.0 and 4.1 branches, e.g. this
change goes into trunk as {{\-nn\-}}
5. Introduce double-character minor formats. So an eventual format change in
4.0 or 4.1 would be {{\-nba\-}}
All of these are painful IMHO. (1) shoots our foot off. (2) is tech debt and
introduces risk on release branches (think about needing a CVE patch quickly
and this getting in the way). It is unclear if (4) is currently possible
(though we do something similar with verbs). And (5) is just yuck, introducing
something new on a past release, which itself is an API breakage.
I'm still in favour of this patch landing in trunk with {{\-oa\-}} as the
simplest solution. A major format change (even if superficial) aligned with a
major release is our current practice and what user's expect and know to deal
with. We can do better, and [~yukim] proposes a solution that is much aligned
with [~cscotta] in CASSANDRA-8110, but let's not block this ticket on that work.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a
[jira] [Comment Edited] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690430#comment-17690430
]
Michael Semb Wever edited comment on CASSANDRA-18134 at 2/17/23 2:45 PM:
-
So, for the sake of discussion: because the only precedence we have today (look
at BigFormat's history) is any format bump in a major version has always been a
major format change; if we are to bump trunk to {{\-nc\-}} the problem scenario
I raise has (at least) the five following possibilities:
1. Release branches for 4.0 and 4.1 are fixed to {{\-nb\-}}. No format changes
are permitted.
2. Any eventual format change on 4.0 or 4.1 requires first back-porting (all or
some minimal support of) the {{\-nc\-}} change, with the new change happening
in {{\-nd\-}}. (Aleksey's comment directly above.)
3. Some minimal version of the {{\-nc\-}} is committed to 4.0 and 4.1 branches
now. (Aleksey's comment two above.)
4. Reserve some sequence of minor versions for 4.0 and 4.1 branches, e.g. this
change goes into trunk as {{\-nn\-}}
5. Introduce double-character minor formats. So an eventual format change in
4.0 or 4.1 would be {{\-nba\-}}
All of these are painful IMHO. (1) shoots our foot off. (2) is tech debt and
introduces risk on release branches (think about needing a CVE patch quickly
and this getting in the way). It is unclear if (4) is currently possible
(though we do something similar with verbs). And (5) is just yuck, introducing
something new on a past release, which itself is an API breakage.
I'm still in favour of this patch landing in trunk with {{\-oa\-}} as the
simplest solution. A major format change (even if superficial) aligned with a
major release is our current practice and what user's expect and know to deal
with. We can do better, and [~yukim] proposes a solution that is much aligned
with [~cscotta] in CASSANDRA-8110, but let's not block this ticket on that work.
was (Author: michaelsembwever):
So, for the sake of discussion: because the only precedence we have today (look
at BigFormat's history) is any format bump in a major version has always been a
major format change; if we are to bump trunk to {{\-nc\-}} the problem scenario
I raise has (at least) the four following possibility:
1. Release branches for 4.0 and 4.1 are fixed to {{\-nb\-}}. No format changes
are permitted.
2. Any eventual format change on 4.0 or 4.1 requires first back-porting (all or
some minimal support of) the {{\-nc\-}} change, with the new change happening
in {{\-nd\-}}. (Aleksey's comment directly above.)
3. Some minimal version of the {{\-nc\-}} is committed to 4.0 and 4.1 branches
now. (Aleksey's comment two above.)
4. Reserve some sequence of minor versions for 4.0 and 4.1 branches, e.g. this
change goes into trunk as {{\-nn\-}}
All of these are painful IMHO. (1) shoots our foot off. (2) is tech debt and
introduces risk on release branches (think about needing a CVE patch quickly
and this getting in the way). It is unclear if (4) is currently possible
(though we do something similar with verbs).
I'm still in favour of this patch landing in trunk with {{\-oa\-}} as the
simplest solution. A major format change (even if superficial) aligned with a
major release is our current practice and what user's expect and know to deal
with. We can do better, and [~yukim] proposes a solution that is much aligned
with [~cscotta] in CASSANDRA-8110, but let's not block this ticket on that work.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key rang
[jira] [Comment Edited] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690430#comment-17690430
]
Michael Semb Wever edited comment on CASSANDRA-18134 at 2/17/23 2:41 PM:
-
So, for the sake of discussion: because the only precedence we have today (look
at BigFormat's history) is any format bump in a major version has always been a
major format change; if we are to bump trunk to {{\-nc\-}} the problem scenario
I raise has (at least) the four following possibility:
1. Release branches for 4.0 and 4.1 are fixed to {{\-nb\-}}. No format changes
are permitted.
2. Any eventual format change on 4.0 or 4.1 requires first back-porting (all or
some minimal support of) the {{\-nc\-}} change, with the new change happening
in {{\-nd\-}}. (Aleksey's comment directly above.)
3. Some minimal version of the {{\-nc\-}} is committed to 4.0 and 4.1 branches
now. (Aleksey's comment two above.)
4. Reserve some sequence of minor versions for 4.0 and 4.1 branches, e.g. this
change goes into trunk as {{\-nn\-}}
All of these are painful IMHO. (1) shoots our foot off. (2) is tech debt and
introduces risk on release branches (think about needing a CVE patch quickly
and this getting in the way). It is unclear if (4) is currently possible
(though we do something similar with verbs).
I'm still in favour of this patch landing in trunk with {{\-oa\-}} as the
simplest solution. A major format change (even if superficial) aligned with a
major release is our current practice and what user's expect and know to deal
with. We can do better, and [~yukim] proposes a solution that is much aligned
with [~cscotta] in CASSANDRA-8110, but let's not block this ticket on that work.
was (Author: michaelsembwever):
So, for the sake of discussion: because the only precedence we have today (look
at BigFormat's history) is any format bump in a major version has always been a
major format change; if we are to bump trunk to {{\-nc\-}} the problem scenario
I raise has (at least) the four following possibility:
1. Release branches for 4.0 and 4.1 are fixed to {{\-nb\-}}. No format changes
are permitted.
2. Any eventual format change on 4.0 or 4.1 requires first back-porting (all or
some minimal support of) the {{\-nc\-}} change, with the new change happening
in {{\-nd\-}}. (Aleksey's comment directly above.)
3. Some minimal version of the {{\-nc\-}} is committed to 4.0 and 4.1 branches
now. (Aleksey's comment two above.)
4. Reserve some sequence of minor versions for 4.0 and 4.1 branches, e.g. this
change goes into trunk as {{\-nn\-}}
All of these are painful IMHO. (1) is shoots our foot off. (2) is tech debt and
introduces risk on release branches (think about needing a CVE patch quickly
and this getting in the way). It is unclear if (4) is currently possible
(though we do something similar with verbs).
I'm still in favour of this patch landing in trunk with {{\-oa\-}} as the
simplest solution. A major format change (even if superficial) aligned with a
major release is our current practice and what user's expect and know to deal
with. We can do better, and [~yukim] proposes a solution that is much aligned
with [~cscotta] in CASSANDRA-8110, but let's not block this ticket on that work.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particu
[jira] [Updated] (CASSANDRA-18106) Update CCM for JDK17 and revise current JDK detection strategy
[ https://issues.apache.org/jira/browse/CASSANDRA-18106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18106: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > Update CCM for JDK17 and revise current JDK detection strategy > -- > > Key: CASSANDRA-18106 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18106 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.x > > > As part of CASSANDRA-16895 initial POC an initial version of CCM patch was > created. This needs to be revisited and reviewed > Recently we closed CASSANDRA-18039 which brought questions, probably we need > to revise how we detect JDK versions in CCM and whether it is correct. To the > best of my knowledge there are certain tests in the repo around that and they > pass so my guess is we need to revise just the strategy and maybe document it > explicitly or consider if we want any changes to be applied. Also, we need to > be careful with breaking changes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690430#comment-17690430
]
Michael Semb Wever commented on CASSANDRA-18134:
So, for the sake of discussion: because the only precedence we have today (look
at BigFormat's history) is any format bump in a major version has always been a
major format change; if we are to bump trunk to {{\-nc\-}} the problem scenario
I raise has (at least) the four following possibility:
1. Release branches for 4.0 and 4.1 are fixed to {{\-nb\-}}. No format changes
are permitted.
2. Any eventual format change on 4.0 or 4.1 requires first back-porting (all or
some minimal support of) the {{\-nc\-}} change, with the new change happening
in {{\-nd\-}}. (Aleksey's comment directly above.)
3. Some minimal version of the {{\-nc\-}} is committed to 4.0 and 4.1 branches
now. (Aleksey's comment two above.)
4. Reserve some sequence of minor versions for 4.0 and 4.1 branches, e.g. this
change goes into trunk as {{\-nn\-}}
All of these are painful IMHO. (1) is shoots our foot off. (2) is tech debt and
introduces risk on release branches (think about needing a CVE patch quickly
and this getting in the way). It is unclear if (4) is currently possible
(though we do something similar with verbs).
I'm still in favour of this patch landing in trunk with {{\-oa\-}} as the
simplest solution. A major format change (even if superficial) aligned with a
major release is our current practice and what user's expect and know to deal
with. We can do better, and [~yukim] proposes a solution that is much aligned
with [~cscotta] in CASSANDRA-8110, but let's not block this ticket on that work.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690429#comment-17690429
]
Jacek Lewandowski commented on CASSANDRA-18134:
---
As I've said - I don't insist on merging to 4.0 family. All in all this is not
a bug fix.
BTW. I'm in favour of taking the discussion about the versioning rules out of
this ticket. If somebody wants to learn about this particular ticket they will
be forced to dig through a lot of loosely related comments.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18134) Improve handling of min/max clustering in sstable
[
https://issues.apache.org/jira/browse/CASSANDRA-18134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690393#comment-17690393
]
Aleksey Yeschenko commented on CASSANDRA-18134:
---
You can also defer committing -nc- support to 4.0.x until something else
warrants an sstable version change on 4.0.x - if that ever happens.
> Improve handling of min/max clustering in sstable
> -
>
> Key: CASSANDRA-18134
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18134
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 5.x
>
>
> This patch improves the following things:
> # SSTable metadata will store a covered slice in addition min/max
> clusterings. The difference is that for slices there is available the type of
> a bound rather than just a clustering. In particular it will provide the
> information whether the lower and upper bound of an sstable is opened or
> closed. The legacy min/max clustering will be stored until a new major format
> {{o}} to ensure backward compatibility
> # SSTable metadata will store a flag whether the SSTable contains any
> partition level deletions or not
> # SSTable metadata will store the first and the last keys of the sstable.
> This is mostly for consistency - key range is logically a part of stats
> metadata. So far it is stored at the end of the index summary. After this
> change, index summary will be no longer needed to read key range of an
> sstable (although we will keep storing key range as before for compatibility
> reasons)
> # The above two changes required to introduce a new minor format for SSTables
> - {{nc}}
> # Single partition read command makes use of the above changes. In particular
> an sstable can be skipped when it does not intersect with the column filter,
> does not have partition level deletions and does not have statics; In case
> there are partition level deletions, but the other conditions are satisfied,
> only the partition header needs to be accessed (tests attached)
> # Skipping sstables assuming those three conditions are satisfied has been
> implemented also for partition range queries (tests attached). Also added
> minor separate statistics to record the number of accessed sstables in
> partition reads because now not all of them need to be accessed. That
> statistics is also needed in tests to confirm skipping.
> # Artificial lower bound marker is now an object on its own and is not
> implemented as a special case of range tombstone bound. Instead it sorts
> right before the lowest available bound in the data
> # Extended the lower bound optimization usage due the 1 and 2
> # Do not initialize iterator just to get a cached partition and associated
> columns index. The purpose of using lower bound optimization was to avoid
> opening an iterator of an sstable if possible.
> See also CASSANDRA-14861
> The changes in this patch include work of [~blambov], [~slebresne],
> [~jakubzytka] and [~jlewandowski]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
