[jira] [Commented] (CASSANDRA-15954) When compaction gets interrupted, the exception should include the compactionId
[
https://issues.apache.org/jira/browse/CASSANDRA-15954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190968#comment-17190968
]
Caleb Rackliffe commented on CASSANDRA-15954:
-
+1 after the latest changes
> When compaction gets interrupted, the exception should include the
> compactionId
> ---
>
> Key: CASSANDRA-15954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15954
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction
>Reporter: David Capwell
>Assignee: Yifan Cai
>Priority: Normal
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> When we log in compaction we use the compactionId (or taskId), because of
> this we can figure out the start and end log lines for compaction. The issue
> is, when you interrupt a compaction task, we don’t log the compactionId, we
> instead log the tableId; for this reason it is much harder to attribute the
> interrupt to a single compactionId
> Examples
> {code}
> INFO 2020-07-15T18:04:51,670 [CompactionExecutor:144057]
> org.apache.cassandra.db.compaction.CompactionTask:158 - Compacting
> (5a463760-c700-11ea-8982-13c71a558319) [data/ks/table/ma-27-Data.db:level=0,
> data/ks/table/
> ma-24-Data.db:level=0, ]
> INFO 2020-07-15T18:33:47,550 [CompactionExecutor:144057]
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor:1942 -
> Compaction interrupted: Compaction@057aa994-c35b-39ec-b74d-33fba2d13bbc(ks,
> table, 3105436904/8658590553)bytes
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15386) Use multiple data directories in the in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-15386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15386: -- Reviewers: Alex Petrov, David Capwell, David Capwell (was: Alex Petrov, David Capwell) Alex Petrov, David Capwell, David Capwell (was: Alex Petrov) Status: Review In Progress (was: Patch Available) > Use multiple data directories in the in-jvm dtests > -- > > Key: CASSANDRA-15386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15386 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Test/dtest/java >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Labels: pull-request-available > Fix For: 3.11.x, 4.x > > > We should default to using 3 data directories when running the in-jvm dtests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15386) Use multiple data directories in the in-jvm dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-15386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190960#comment-17190960 ] David Capwell commented on CASSANDRA-15386: --- LGTM +1 > Use multiple data directories in the in-jvm dtests > -- > > Key: CASSANDRA-15386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15386 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Test/dtest/java >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Labels: pull-request-available > Fix For: 3.11.x, 4.x > > > We should default to using 3 data directories when running the in-jvm dtests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15954) When compaction gets interrupted, the exception should include the compactionId
[
https://issues.apache.org/jira/browse/CASSANDRA-15954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190945#comment-17190945
]
David Capwell commented on CASSANDRA-15954:
---
spoke in slack, this broke a dtest so will need dtest to be updated.
> When compaction gets interrupted, the exception should include the
> compactionId
> ---
>
> Key: CASSANDRA-15954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15954
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction
>Reporter: David Capwell
>Assignee: Yifan Cai
>Priority: Normal
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> When we log in compaction we use the compactionId (or taskId), because of
> this we can figure out the start and end log lines for compaction. The issue
> is, when you interrupt a compaction task, we don’t log the compactionId, we
> instead log the tableId; for this reason it is much harder to attribute the
> interrupt to a single compactionId
> Examples
> {code}
> INFO 2020-07-15T18:04:51,670 [CompactionExecutor:144057]
> org.apache.cassandra.db.compaction.CompactionTask:158 - Compacting
> (5a463760-c700-11ea-8982-13c71a558319) [data/ks/table/ma-27-Data.db:level=0,
> data/ks/table/
> ma-24-Data.db:level=0, ]
> INFO 2020-07-15T18:33:47,550 [CompactionExecutor:144057]
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor:1942 -
> Compaction interrupted: Compaction@057aa994-c35b-39ec-b74d-33fba2d13bbc(ks,
> table, 3105436904/8658590553)bytes
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16082) Add a new jmxtool which can dump what JMX objects exist and diff
[ https://issues.apache.org/jira/browse/CASSANDRA-16082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-16082: - Reviewers: Berenguer Blasi, Jon Meredith, Jon Meredith (was: Berenguer Blasi, Jon Meredith) Berenguer Blasi, Jon Meredith, Jon Meredith (was: Berenguer Blasi) Status: Review In Progress (was: Patch Available) > Add a new jmxtool which can dump what JMX objects exist and diff > > > Key: CASSANDRA-16082 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16082 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Time Spent: 3h 50m > Remaining Estimate: 0h > > In order to help validate metric upgrade we first need to know what is new, > what was removed, and what was changed. To help with this, we should add a > new jmxtool which can dump the objects from JMX and diff them. > Once we have this, we can also add a gold list of expected metrics and add > tests to validate these metrics don’t change. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15954) When compaction gets interrupted, the exception should include the compactionId
[
https://issues.apache.org/jira/browse/CASSANDRA-15954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190932#comment-17190932
]
David Capwell commented on CASSANDRA-15954:
---
latest logic LGTM, can we run through dtests?
> When compaction gets interrupted, the exception should include the
> compactionId
> ---
>
> Key: CASSANDRA-15954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15954
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction
>Reporter: David Capwell
>Assignee: Yifan Cai
>Priority: Normal
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> When we log in compaction we use the compactionId (or taskId), because of
> this we can figure out the start and end log lines for compaction. The issue
> is, when you interrupt a compaction task, we don’t log the compactionId, we
> instead log the tableId; for this reason it is much harder to attribute the
> interrupt to a single compactionId
> Examples
> {code}
> INFO 2020-07-15T18:04:51,670 [CompactionExecutor:144057]
> org.apache.cassandra.db.compaction.CompactionTask:158 - Compacting
> (5a463760-c700-11ea-8982-13c71a558319) [data/ks/table/ma-27-Data.db:level=0,
> data/ks/table/
> ma-24-Data.db:level=0, ]
> INFO 2020-07-15T18:33:47,550 [CompactionExecutor:144057]
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor:1942 -
> Compaction interrupted: Compaction@057aa994-c35b-39ec-b74d-33fba2d13bbc(ks,
> table, 3105436904/8658590553)bytes
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15854) Truncation should fail any ongoing repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-15854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15854: -- Status: Changes Suggested (was: Review In Progress) > Truncation should fail any ongoing repairs > -- > > Key: CASSANDRA-15854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15854 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta > > > Truncation may race with ongoing repairs, making it possible to clear data on > one node but then stream data its truncation would have deleted from another > node. We should abort any ongoing preview repairs if we get a truncation > request. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15854) Truncation should fail any ongoing repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-15854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190923#comment-17190923 ] David Capwell commented on CASSANDRA-15854: --- Left my comments on https://github.com/krummas/cassandra/commit/614b8da34660cc86305a26d33c47883cb5f603e7; my main comments are on the test. > Truncation should fail any ongoing repairs > -- > > Key: CASSANDRA-15854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15854 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta > > > Truncation may race with ongoing repairs, making it possible to clear data on > one node but then stream data its truncation would have deleted from another > node. We should abort any ongoing preview repairs if we get a truncation > request. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15854) Truncation should fail any ongoing repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-15854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15854: -- Reviewers: Caleb Rackliffe, David Capwell (was: Caleb Rackliffe) > Truncation should fail any ongoing repairs > -- > > Key: CASSANDRA-15854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15854 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-beta > > > Truncation may race with ongoing repairs, making it possible to clear data on > one node but then stream data its truncation would have deleted from another > node. We should abort any ongoing preview repairs if we get a truncation > request. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15934) In-jvm dtests use -1 as timestamp for all writes that don't specify 'USING TIMESTAMP'
[ https://issues.apache.org/jira/browse/CASSANDRA-15934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15934: -- Fix Version/s: (was: 3.11.x) (was: 4.x) (was: 3.0.x) (was: 2.2.x) 4.0-beta3 3.11.9 3.0.23 2.2.19 Since Version: 2.2.18 Source Control Link: https://github.com/apache/cassandra/commit/3a29f77743e57d0fb5abd21fc03f9591f51a08ef Resolution: Fixed Status: Resolved (was: Ready to Commit) CI results: 2.2: https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-15934-cassandra-2.2-64E27C2E-C7A3-44A8-8AB7-A6B61A886E54 3.0: https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-15934-cassandra-3.0-64E27C2E-C7A3-44A8-8AB7-A6B61A886E54 3.11: https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-15934-cassandra-3.11-64E27C2E-C7A3-44A8-8AB7-A6B61A886E54 trunk: https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=commit_remote_branch%2FCASSANDRA-15934-trunk-64E27C2E-C7A3-44A8-8AB7-A6B61A886E54 The added tests didn't fail in any branch so ignored 3.0+ test failures as they are unrelated. 2.2 has a lot of test failures but all look to be the cql tests, which are known broken in 2.2 > In-jvm dtests use -1 as timestamp for all writes that don't specify 'USING > TIMESTAMP' > - > > Key: CASSANDRA-15934 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15934 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 2.2.19, 3.0.23, 3.11.9, 4.0-beta3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (9b6e54e -> 691720e)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 9b6e54e Avoid trying to keep track of RTs for endpoints we won't write to during read repair new 3642d55 In-jvm dtests use -1 as timestamp for all writes that don't specify 'USING TIMESTAMP' new ad00162 Merge branch 'cassandra-2.2' into cassandra-3.0 new 5cb3ad3 Merge branch 'cassandra-3.0' into cassandra-3.11 new 691720e Merge branch 'cassandra-3.11' into trunk The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../cassandra/distributed/test/JVMDTestTest.java | 53 ++ 1 file changed, 53 insertions(+) create mode 100644 test/distributed/org/apache/cassandra/distributed/test/JVMDTestTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
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.git commit 691720ef3986e67a21c2f67caeef4090aa077f88 Merge: 9b6e54e 5cb3ad3 Author: David Capwell AuthorDate: Fri Sep 4 13:41:42 2020 -0700 Merge branch 'cassandra-3.11' into trunk .../cassandra/distributed/test/JVMDTestTest.java | 53 ++ 1 file changed, 53 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (ca37de0 -> 5cb3ad3)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from ca37de0 Merge branch 'cassandra-3.0' into cassandra-3.11 new 3642d55 In-jvm dtests use -1 as timestamp for all writes that don't specify 'USING TIMESTAMP' new ad00162 Merge branch 'cassandra-2.2' into cassandra-3.0 new 5cb3ad3 Merge branch 'cassandra-3.0' into cassandra-3.11 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../cassandra/distributed/test/JVMDTestTest.java | 53 ++ 1 file changed, 53 insertions(+) create mode 100644 test/distributed/org/apache/cassandra/distributed/test/JVMDTestTest.java - 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-2.2' into cassandra-3.0
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit ad001626807be211189ba695b2b831c53ad27f07 Merge: 0eaed71 3642d55 Author: David Capwell AuthorDate: Fri Sep 4 13:39:55 2020 -0700 Merge branch 'cassandra-2.2' into cassandra-3.0 .../cassandra/distributed/test/JVMDTestTest.java | 53 ++ 1 file changed, 53 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-2.2 updated: In-jvm dtests use -1 as timestamp for all writes that don't specify 'USING TIMESTAMP'
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch cassandra-2.2
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-2.2 by this push:
new 3642d55 In-jvm dtests use -1 as timestamp for all writes that don't
specify 'USING TIMESTAMP'
3642d55 is described below
commit 3642d55886f3115530266b53a95d53ecd136bf9a
Author: Marcus Eriksson
AuthorDate: Fri Sep 4 10:57:47 2020 -0700
In-jvm dtests use -1 as timestamp for all writes that don't specify 'USING
TIMESTAMP'
patch by Marcus Eriksson; reviewed by David Capwell for CASSANDRA-15934
---
.../org/apache/cassandra/cql3/QueryOptions.java| 2 +-
.../cassandra/distributed/test/JVMDTestTest.java | 53 ++
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/src/java/org/apache/cassandra/cql3/QueryOptions.java
b/src/java/org/apache/cassandra/cql3/QueryOptions.java
index da705e0..93d6c9b 100644
--- a/src/java/org/apache/cassandra/cql3/QueryOptions.java
+++ b/src/java/org/apache/cassandra/cql3/QueryOptions.java
@@ -88,7 +88,7 @@ public abstract class QueryOptions
public static QueryOptions create(ConsistencyLevel consistency,
List values, boolean skipMetadata, int pageSize, PagingState
pagingState, ConsistencyLevel serialConsistency, int protocolVersion)
{
-return new DefaultQueryOptions(consistency, values, skipMetadata, new
SpecificOptions(pageSize, pagingState, serialConsistency, -1L),
protocolVersion);
+return new DefaultQueryOptions(consistency, values, skipMetadata, new
SpecificOptions(pageSize, pagingState, serialConsistency, Long.MIN_VALUE),
protocolVersion);
}
public static QueryOptions addColumnSpecifications(QueryOptions options,
List columnSpecs)
diff --git
a/test/distributed/org/apache/cassandra/distributed/test/JVMDTestTest.java
b/test/distributed/org/apache/cassandra/distributed/test/JVMDTestTest.java
new file mode 100644
index 000..795b4ea
--- /dev/null
+++ b/test/distributed/org/apache/cassandra/distributed/test/JVMDTestTest.java
@@ -0,0 +1,53 @@
+/*
+ * 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
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * 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.
+ */
+
+package org.apache.cassandra.distributed.test;
+
+import java.io.IOException;
+
+import org.junit.Test;
+
+import org.apache.cassandra.distributed.Cluster;
+import org.apache.cassandra.distributed.api.ConsistencyLevel;
+import org.apache.cassandra.utils.FBUtilities;
+
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertTrue;
+
+public class JVMDTestTest extends TestBaseImpl
+{
+@Test
+public void insertTimestampTest() throws IOException
+{
+try (Cluster cluster = init(Cluster.build(1).start()))
+{
+long now = FBUtilities.timestampMicros();
+cluster.schemaChange("CREATE TABLE "+KEYSPACE+".tbl (id int
primary key, i int)");
+cluster.coordinator(1).execute("INSERT INTO "+KEYSPACE+".tbl (id,
i) VALUES (1,1)", ConsistencyLevel.ALL);
+cluster.coordinator(1).execute("INSERT INTO "+KEYSPACE+".tbl (id,
i) VALUES (2,2) USING TIMESTAMP 1000", ConsistencyLevel.ALL);
+
+Object [][] res = cluster.coordinator(1).execute("SELECT
writetime(i) FROM "+KEYSPACE+".tbl WHERE id = 1", ConsistencyLevel.ALL);
+assertEquals(1, res.length);
+assertTrue("ts="+res[0][0], (long)res[0][0] >= now);
+
+res = cluster.coordinator(1).execute("SELECT writetime(i) FROM
"+KEYSPACE+".tbl WHERE id = 2", ConsistencyLevel.ALL);
+assertEquals(1, res.length);
+assertEquals(1000, (long) res[0][0]);
+}
+}
+}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 5cb3ad3d08a99fc7152096e6ff3d8b3f3a7b5e5f Merge: ca37de0 ad00162 Author: David Capwell AuthorDate: Fri Sep 4 13:40:48 2020 -0700 Merge branch 'cassandra-3.0' into cassandra-3.11 .../cassandra/distributed/test/JVMDTestTest.java | 53 ++ 1 file changed, 53 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (0eaed71 -> ad00162)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 0eaed71 Merge branch 'cassandra-2.2' into cassandra-3.0 new 3642d55 In-jvm dtests use -1 as timestamp for all writes that don't specify 'USING TIMESTAMP' new ad00162 Merge branch 'cassandra-2.2' into cassandra-3.0 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../cassandra/distributed/test/JVMDTestTest.java | 53 ++ 1 file changed, 53 insertions(+) create mode 100644 test/distributed/org/apache/cassandra/distributed/test/JVMDTestTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15977) 4.0 quality testing: Read Repair
[ https://issues.apache.org/jira/browse/CASSANDRA-15977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-15977: Reviewers: Caleb Rackliffe, David Capwell (was: Caleb Rackliffe) > 4.0 quality testing: Read Repair > > > Key: CASSANDRA-15977 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15977 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java, Test/unit >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 2h 10m > Remaining Estimate: 0h > > This is a subtask of CASSANDRA-15579 focusing on read repair. > [This > document|https://docs.google.com/document/d/1-gldHcdLSMRbDhhI8ahs_tPeAZsjurjXr38xABVjWHE/edit?usp=sharing] > lists and describes the existing functional tests for read repair, so we can > have a broad view of what is currently covered. We can comment on this > document and add ideas for new cases/tests, so it can gradually evolve to a > more or less detailed test plan. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15954) When compaction gets interrupted, the exception should include the compactionId
[
https://issues.apache.org/jira/browse/CASSANDRA-15954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190868#comment-17190868
]
Caleb Rackliffe commented on CASSANDRA-15954:
-
Dropped a couple minor comments, but LGTM otherwise.
> When compaction gets interrupted, the exception should include the
> compactionId
> ---
>
> Key: CASSANDRA-15954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15954
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction
>Reporter: David Capwell
>Assignee: Yifan Cai
>Priority: Normal
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When we log in compaction we use the compactionId (or taskId), because of
> this we can figure out the start and end log lines for compaction. The issue
> is, when you interrupt a compaction task, we don’t log the compactionId, we
> instead log the tableId; for this reason it is much harder to attribute the
> interrupt to a single compactionId
> Examples
> {code}
> INFO 2020-07-15T18:04:51,670 [CompactionExecutor:144057]
> org.apache.cassandra.db.compaction.CompactionTask:158 - Compacting
> (5a463760-c700-11ea-8982-13c71a558319) [data/ks/table/ma-27-Data.db:level=0,
> data/ks/table/
> ma-24-Data.db:level=0, ]
> INFO 2020-07-15T18:33:47,550 [CompactionExecutor:144057]
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor:1942 -
> Compaction interrupted: Compaction@057aa994-c35b-39ec-b74d-33fba2d13bbc(ks,
> table, 3105436904/8658590553)bytes
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15934) In-jvm dtests use -1 as timestamp for all writes that don't specify 'USING TIMESTAMP'
[ https://issues.apache.org/jira/browse/CASSANDRA-15934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190857#comment-17190857 ] David Capwell commented on CASSANDRA-15934: --- starting commit now, will retest to make sure its clean merge. > In-jvm dtests use -1 as timestamp for all writes that don't specify 'USING > TIMESTAMP' > - > > Key: CASSANDRA-15934 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15934 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15977) 4.0 quality testing: Read Repair
[ https://issues.apache.org/jira/browse/CASSANDRA-15977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-15977: Reviewers: Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe) Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe) Status: Review In Progress (was: Patch Available) > 4.0 quality testing: Read Repair > > > Key: CASSANDRA-15977 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15977 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java, Test/unit >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 40m > Remaining Estimate: 0h > > This is a subtask of CASSANDRA-15579 focusing on read repair. > [This > document|https://docs.google.com/document/d/1-gldHcdLSMRbDhhI8ahs_tPeAZsjurjXr38xABVjWHE/edit?usp=sharing] > lists and describes the existing functional tests for read repair, so we can > have a broad view of what is currently covered. We can comment on this > document and add ideas for new cases/tests, so it can gradually evolve to a > more or less detailed test plan. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15934) In-jvm dtests use -1 as timestamp for all writes that don't specify 'USING TIMESTAMP'
[ https://issues.apache.org/jira/browse/CASSANDRA-15934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15934: -- Reviewers: David Capwell, David Capwell (was: David Capwell) David Capwell, David Capwell (was: David Capwell) Status: Review In Progress (was: Patch Available) > In-jvm dtests use -1 as timestamp for all writes that don't specify 'USING > TIMESTAMP' > - > > Key: CASSANDRA-15934 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15934 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15934) In-jvm dtests use -1 as timestamp for all writes that don't specify 'USING TIMESTAMP'
[ https://issues.apache.org/jira/browse/CASSANDRA-15934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15934: -- Status: Ready to Commit (was: Review In Progress) +1 > In-jvm dtests use -1 as timestamp for all writes that don't specify 'USING > TIMESTAMP' > - > > Key: CASSANDRA-15934 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15934 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15934) In-jvm dtests use -1 as timestamp for all writes that don't specify 'USING TIMESTAMP'
[ https://issues.apache.org/jira/browse/CASSANDRA-15934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190852#comment-17190852 ] David Capwell commented on CASSANDRA-15934: --- reviewing now > In-jvm dtests use -1 as timestamp for all writes that don't specify 'USING > TIMESTAMP' > - > > Key: CASSANDRA-15934 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15934 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15954) When compaction gets interrupted, the exception should include the compactionId
[
https://issues.apache.org/jira/browse/CASSANDRA-15954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190851#comment-17190851
]
David Capwell commented on CASSANDRA-15954:
---
LGTM +1. Will wait for [~maedhroz] review
> When compaction gets interrupted, the exception should include the
> compactionId
> ---
>
> Key: CASSANDRA-15954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15954
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction
>Reporter: David Capwell
>Assignee: Yifan Cai
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When we log in compaction we use the compactionId (or taskId), because of
> this we can figure out the start and end log lines for compaction. The issue
> is, when you interrupt a compaction task, we don’t log the compactionId, we
> instead log the tableId; for this reason it is much harder to attribute the
> interrupt to a single compactionId
> Examples
> {code}
> INFO 2020-07-15T18:04:51,670 [CompactionExecutor:144057]
> org.apache.cassandra.db.compaction.CompactionTask:158 - Compacting
> (5a463760-c700-11ea-8982-13c71a558319) [data/ks/table/ma-27-Data.db:level=0,
> data/ks/table/
> ma-24-Data.db:level=0, ]
> INFO 2020-07-15T18:33:47,550 [CompactionExecutor:144057]
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor:1942 -
> Compaction interrupted: Compaction@057aa994-c35b-39ec-b74d-33fba2d13bbc(ks,
> table, 3105436904/8658590553)bytes
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15954) When compaction gets interrupted, the exception should include the compactionId
[
https://issues.apache.org/jira/browse/CASSANDRA-15954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15954:
--
Reviewers: Caleb Rackliffe, David Capwell, David Capwell (was: Caleb
Rackliffe, David Capwell)
Caleb Rackliffe, David Capwell, David Capwell (was: Caleb
Rackliffe)
Status: Review In Progress (was: Patch Available)
> When compaction gets interrupted, the exception should include the
> compactionId
> ---
>
> Key: CASSANDRA-15954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15954
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction
>Reporter: David Capwell
>Assignee: Yifan Cai
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When we log in compaction we use the compactionId (or taskId), because of
> this we can figure out the start and end log lines for compaction. The issue
> is, when you interrupt a compaction task, we don’t log the compactionId, we
> instead log the tableId; for this reason it is much harder to attribute the
> interrupt to a single compactionId
> Examples
> {code}
> INFO 2020-07-15T18:04:51,670 [CompactionExecutor:144057]
> org.apache.cassandra.db.compaction.CompactionTask:158 - Compacting
> (5a463760-c700-11ea-8982-13c71a558319) [data/ks/table/ma-27-Data.db:level=0,
> data/ks/table/
> ma-24-Data.db:level=0, ]
> INFO 2020-07-15T18:33:47,550 [CompactionExecutor:144057]
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor:1942 -
> Compaction interrupted: Compaction@057aa994-c35b-39ec-b74d-33fba2d13bbc(ks,
> table, 3105436904/8658590553)bytes
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15954) When compaction gets interrupted, the exception should include the compactionId
[
https://issues.apache.org/jira/browse/CASSANDRA-15954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-15954:
Reviewers: Caleb Rackliffe
> When compaction gets interrupted, the exception should include the
> compactionId
> ---
>
> Key: CASSANDRA-15954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15954
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction
>Reporter: David Capwell
>Assignee: Yifan Cai
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When we log in compaction we use the compactionId (or taskId), because of
> this we can figure out the start and end log lines for compaction. The issue
> is, when you interrupt a compaction task, we don’t log the compactionId, we
> instead log the tableId; for this reason it is much harder to attribute the
> interrupt to a single compactionId
> Examples
> {code}
> INFO 2020-07-15T18:04:51,670 [CompactionExecutor:144057]
> org.apache.cassandra.db.compaction.CompactionTask:158 - Compacting
> (5a463760-c700-11ea-8982-13c71a558319) [data/ks/table/ma-27-Data.db:level=0,
> data/ks/table/
> ma-24-Data.db:level=0, ]
> INFO 2020-07-15T18:33:47,550 [CompactionExecutor:144057]
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor:1942 -
> Compaction interrupted: Compaction@057aa994-c35b-39ec-b74d-33fba2d13bbc(ks,
> table, 3105436904/8658590553)bytes
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15949) NPE thrown while updating speculative execution time if table is removed during task execution
[ https://issues.apache.org/jira/browse/CASSANDRA-15949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190427#comment-17190427 ] Caleb Rackliffe edited comment on CASSANDRA-15949 at 9/4/20, 5:08 PM: -- [trunk|https://github.com/apache/cassandra/pull/733] [j8 tests|https://app.circleci.com/pipelines/github/maedhroz/cassandra/105/workflows/36eededa-b5bc-4ecc-b3fa-592f12109884] [j11 tests|https://app.circleci.com/pipelines/github/maedhroz/cassandra/105/workflows/940fb0c2-7881-40fa-9daa-dc29859d27ec] UPDATE: Tests are clean outside a couple already identified as flaky. was (Author: maedhroz): [trunk|https://github.com/apache/cassandra/pull/733] [j8 tests|https://app.circleci.com/pipelines/github/maedhroz/cassandra/105/workflows/36eededa-b5bc-4ecc-b3fa-592f12109884] [j11 tests|https://app.circleci.com/pipelines/github/maedhroz/cassandra/105/workflows/940fb0c2-7881-40fa-9daa-dc29859d27ec] > NPE thrown while updating speculative execution time if table is removed > during task execution > -- > > Key: CASSANDRA-15949 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15949 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Jon Meredith >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 20m > Remaining Estimate: 0h > > CASSANDRA-14338 fixed the scheduling the speculation retry threshold > calculation, but if the task happens to be scheduled while a table is being > dropped, it triggers an NPE. > ERROR 2020-07-14T11:34:55,762 [OptionalTasks:1] > org.apache.cassandra.service.CassandraDaemon:446 - Exception in thread > Thread[OptionalTasks:1,5,main] > java.lang.NullPointerException: null > at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:444) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.(Keyspace.java:346) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.open(Keyspace.java:139) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace.open(Keyspace.java:116) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:102) > ~[cassandra-4.0.0.jar:4.0.0] > at org.apache.cassandra.db.Keyspace$1.apply(Keyspace.java:99) > ~[cassandra-4.0.0.jar:4.0.0] > at > com.google.common.collect.Iterables$5.lambda$forEach$0(Iterables.java:704) > ~[guava-27.0-jre.jar:?] > at > com.google.common.collect.IndexedImmutableSet.forEach(IndexedImmutableSet.java:45) > ~[guava-27.0-jre.jar:?] > at com.google.common.collect.Iterables$5.forEach(Iterables.java:704) > ~[guava-27.0-jre.jar:?] > at > org.apache.cassandra.service.CassandraDaemon.lambda$setup$2(CassandraDaemon.java:412) > ~[cassandra-4.0.0.jar:4.0.0] > at > org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118) > [cassandra-4.0.0.jar:4.0.0] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?] > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > [?:?] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > [?:?] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > [?:?] > at > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > [netty-all-4.1.37.Final.jar:4.1.37.Final] > at java.lang.Thread.run(Thread.java:834) [?:?] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15938) Fix support for adding UDT fields to clustering keys
[ https://issues.apache.org/jira/browse/CASSANDRA-15938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190815#comment-17190815 ] Caleb Rackliffe commented on CASSANDRA-15938: - [~ifesdjeen] I don't see any new failures in the unit tests or in-JVM dtests, but we probably need to switch to the HIGHRES CircleCI config for the python dtests... > Fix support for adding UDT fields to clustering keys > > > Key: CASSANDRA-15938 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15938 > Project: Cassandra > Issue Type: Bug > Components: Feature/UDT >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0-beta > > > Adding UDT fields to clustering keys is broken in all versions, however > slightly differently. > In 4.0, there will be a brief moment while schema changes are propagated > during which we won’t be able to decode and compare byte sequences. > Unfortunately, it is unclear what we should do in such cases, since we can’t > just come up with a comparator, and we can’t ignore non-null trailing values, > since this will lead to cases where compare for tuples `a;1` and `a;2` would > return 0, effectively making them equal, and we don’t know how to compare > unknown trailing values. Probably we should reject such query since we can’t > sort correctly, but we should make the error message more descriptive than > just "Index 1 out of bounds for length 1”. The only problem is that we get > this exception only on flush right now, so data already propagates to the > node by that time. > In 3.0, the problem is a bit worse than that, since in 3.0 we do not ignore > trailing nulls, so some of the values, written before `ALTER TYPE .. ADD` > become inaccessible. Both old values, and the new ones should always be > accessible. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15899) Dropping a column can break queries until the schema is fully propagated
[
https://issues.apache.org/jira/browse/CASSANDRA-15899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15899:
Status: Ready to Commit (was: Review In Progress)
+1 LGTM
One tiny nit if you don't mind fixing on commit: in the 3.0 & 3.11 branches,
there are a couple of stray semicolons in {{SimpleReadWriteTest}} (lines 137 &
148).
> Dropping a column can break queries until the schema is fully propagated
>
>
> Key: CASSANDRA-15899
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15899
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Marcus Eriksson
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 3.0.x
>
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[main/:na]
> ...
> {code}
> Note that it doesn't matter if we {{SELECT *}} or {{SELECT id, v1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15899) Dropping a column can break queries until the schema is fully propagated
[
https://issues.apache.org/jira/browse/CASSANDRA-15899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-15899:
Reviewers: Sam Tunnicliffe, Sam Tunnicliffe (was: Sam Tunnicliffe)
Sam Tunnicliffe, Sam Tunnicliffe (was: Sam Tunnicliffe)
Status: Review In Progress (was: Patch Available)
> Dropping a column can break queries until the schema is fully propagated
>
>
> Key: CASSANDRA-15899
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15899
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Marcus Eriksson
>Assignee: Blake Eggleston
>Priority: Normal
> Fix For: 3.0.x
>
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[main/:na]
> ...
> {code}
> Note that it doesn't matter if we {{SELECT *}} or {{SELECT id, v1}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16066) Update and rework cassandra-website material to work with Antora
[ https://issues.apache.org/jira/browse/CASSANDRA-16066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17190746#comment-17190746 ] Rahul Singh commented on CASSANDRA-16066: - >From my understanding, this is what I think lorina is suggesting. * cassandra / docs / intree docs - have a dockerfile so that the the asciidocs can be used to create artifacts related just for documentation. * cassandra-website - have a docker file so that the asciidocs can be used to create artifacts just for the site both of them will refer to the same ui package (referenced in git) * When a release is cut, the in tree build process would generate HTML/PDF whatever to be tarred up (we should make a "lite" version without the docs) with the .tar.gz * when the website is published, the website build process would build the static site content and may need to rely on the dockerfile from cassandra.git to produce a full website release** *I propose this (or this is what the intention may have been all along)* * build process for cassandra ** uses docs/dockerfile as needed on releases to include in release ** uses docs/dockerfile as needed on releases to *publish* only /docs/ section of the site ( separate public path to push docs content to) * build process for cassandra-website ** uses /dockerfile as needed on *publish* blog/ etc. to / section of the site ( separate public path to push site content to) > Update and rework cassandra-website material to work with Antora > > > Key: CASSANDRA-16066 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16066 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Anthony Grasso >Priority: Normal > > *We want to modernise the way the website is built* > Rework the cassandra-website repository to generate a UI bundle containing > resources that Antora will use when generating the Cassandra documents and > website. > *The existing method is starting to become dated* > The documentation and website templates are currently in markdown format. > Sphinx is used to generate the Cassandra documentation and Jekyll generates > the website content. One of the major issues with the existing website > tooling is that the live preview server (render site as it is being updated) > is really slow. There is a preview server that is really fast, however it is > unable to detect changes to the content and render automatically. > *We are migrating the docs to be rendered with Antora* > The work in CASSANDRA-16029 is converting the document templates to AsciiDoc > format. Sphinx is being replaced by Antora to generate the documentation > content. This change has two advantages: > * More flexibility if the Apache Cassandra documentation look and feel needs > to be updated or redesigned. > * More modern look and feel to the documentation. > *We can use Antora to generate the website as well* > Antora could also be used to generate the Cassandra website content. As > suggested on the [mailing > list|https://www.mail-archive.com/dev@cassandra.apache.org/msg15577.html] > this would require the existing markdown templates to be converted to > AsciiDoc as well. > *Antora needs a UI bundle to style content* > For Antora to generate the document content and potentially the website > content it requires a UI bundle (ui-bundle.zip). The UI bundle contains the > HTML templates (layouts, partials, and helpers), CSS, JavaScript, fonts, and > (site-wide) images. As such, it provides both the visual theme and user > interactions for the documentation. Effectively the UI bundle is the > templates and styling that are applied to the documentation and website > content. > *The [cassandra-website|https://github.com/apache/cassandra-website] > repository can be used to generate the UI bundle* > All the resources associated with templating and styling the documentation > and website can be placed in the > [cassandra-website|https://github.com/apache/cassandra-website] repository. > In this case the repository would serve two purposes; > * Generation of the UI bundle resources. > * Serve the production website content. > *The [cassandra|https://github.com/apache/cassandra] repository would contain > the documentation material, while the rest of the non-versioned pages would > contain that material* > * All other material that is used to generate documentation would live in > the [cassandra|https://github.com/apache/cassandra] repository. In this case > Antora would run on the > [cassandra/doc|https://github.com/apache/cassandra/doc] directory and pull in > a UI bundle released on the GitHub > [cassandra-website|https://github.com/apache/cassandra-website] repository. > The content generated by Antora using the
