[jira] [Updated] (CASSANDRA-18104) Major Performance degradation of Casandara 4.0.7 against Casandra 3.11.14
[ https://issues.apache.org/jira/browse/CASSANDRA-18104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sreedhar J updated CASSANDRA-18104: --- Resolution: Invalid Status: Resolved (was: Triage Needed) This is no longer an issue. It's environmental issue, > Major Performance degradation of Casandara 4.0.7 against Casandra 3.11.14 > > > Key: CASSANDRA-18104 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18104 > Project: Cassandra > Issue Type: Bug >Reporter: Sreedhar J >Priority: Urgent > Attachments: 3.11.14.txt, 4.0.7.txt, > cassandra-4x-test-1.0-jar-with-dependencies.jar, mailboxes_snapshot.zip, > query30.txt, screenshot-1.png, screenshot-2.png > > > Our application uses Casandra 3.11.x and has lot of security vulnerabilities > which are addressed in 4.0.x. So we have upgraded the Casandra to 4.0.7 > and our performance tests have shown aorund 20% degradation compare to > 3.11.x > We are now able to reproduce the same performance degradation using the > standalone queries. Here are the steps. > 1. Expand Cassandra 3.11.14 tarball and 4.0.7 tarball to different folders > 2. Import the attached data from the snapshot (mailboxes_snapshot.zip) into > each Cassandra instance, see schema.cql for CQL for creating the required > table and indexes before import > 3. With CQLSH run the following query several times with TRACING ON and > PAGING OFF against both versions of Cassandra: select * from > mailbox.mailboxes where mbx_id= 6c57da2e-7ddd-4984-be62-105415e6b48a; > 4. Compare results > IWe ran the target query 30 times. Here's the average times to run the query: > 3.11.14 - 19400.77 > 4.0.7 - 34906.03 -- 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-18104) Major Performance degradation of Casandara 4.0.7 against Casandra 3.11.14
[ https://issues.apache.org/jira/browse/CASSANDRA-18104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17650133#comment-17650133 ] Sreedhar J commented on CASSANDRA-18104: Thanks [~brandon.williams] We are now able to see the good performance with Cassandra 4.x. issue is with the latency. From the application to Cassandra server latency was around 300 ms, So we deployed our application to different VMs where latency between our application to Cassandra was <10 ms. > Major Performance degradation of Casandara 4.0.7 against Casandra 3.11.14 > > > Key: CASSANDRA-18104 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18104 > Project: Cassandra > Issue Type: Bug >Reporter: Sreedhar J >Priority: Urgent > Attachments: 3.11.14.txt, 4.0.7.txt, > cassandra-4x-test-1.0-jar-with-dependencies.jar, mailboxes_snapshot.zip, > query30.txt, screenshot-1.png, screenshot-2.png > > > Our application uses Casandra 3.11.x and has lot of security vulnerabilities > which are addressed in 4.0.x. So we have upgraded the Casandra to 4.0.7 > and our performance tests have shown aorund 20% degradation compare to > 3.11.x > We are now able to reproduce the same performance degradation using the > standalone queries. Here are the steps. > 1. Expand Cassandra 3.11.14 tarball and 4.0.7 tarball to different folders > 2. Import the attached data from the snapshot (mailboxes_snapshot.zip) into > each Cassandra instance, see schema.cql for CQL for creating the required > table and indexes before import > 3. With CQLSH run the following query several times with TRACING ON and > PAGING OFF against both versions of Cassandra: select * from > mailbox.mailboxes where mbx_id= 6c57da2e-7ddd-4984-be62-105415e6b48a; > 4. Compare results > IWe ran the target query 30 times. Here's the average times to run the query: > 3.11.14 - 19400.77 > 4.0.7 - 34906.03 -- 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-14013) Data loss in snapshots keyspace after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17650130#comment-17650130
]
Stefan Miklosovic commented on CASSANDRA-14013:
---
I think there is a regression in the trunk patch (1)
(1)
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2125/testReport/junit/org.apache.cassandra.io.sstable/LegacySSTableTest/testStreamLegacyCqlTables_compression_2/
> Data loss in snapshots keyspace after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17112) CEP-15: (C*) Strict Serializability verification
[ https://issues.apache.org/jira/browse/CASSANDRA-17112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17112: -- Fix Version/s: 4.x (was: NA) > CEP-15: (C*) Strict Serializability verification > > > Key: CASSANDRA-17112 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17112 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > -- 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-17112) CEP-15: (C*) Strict Serializability verification
[ https://issues.apache.org/jira/browse/CASSANDRA-17112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17112: -- Test and Documentation Plan: added tests Status: Patch Available (was: In Progress) > CEP-15: (C*) Strict Serializability verification > > > Key: CASSANDRA-17112 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17112 > Project: Cassandra > Issue Type: New Feature > Components: Accord >Reporter: Benedict Elliott Smith >Assignee: David Capwell >Priority: Normal > Fix For: NA > > Time Spent: 10m > Remaining Estimate: 0h > -- 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-18077) Add SpotBugs to the build
[ https://issues.apache.org/jira/browse/CASSANDRA-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18077: -- Status: Patch Available (was: Review In Progress) > Add SpotBugs to the build > - > > Key: CASSANDRA-18077 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18077 > Project: Cassandra > Issue Type: Improvement > Components: Build, CI >Reporter: David Capwell >Priority: Normal > Fix For: 4.x > > Attachments: spotbugs.html > > Time Spent: 50m > Remaining Estimate: 0h > > When working on CASSANDRA-17178 I found that several classes were being > reported by the Simulator for not defining serializer version when they are > Serializable; this may cause issues for the Simulator so felt it would be > best to detect these earlier on before merging new ones. > SpotBugs has a large set of checks, some more valuable than others for the > project; so we should maintain a curated list of issues to fail the build on, > and others to warn on. > This topic was discussed in the following mail threads: > * Should we add?: > https://lists.apache.org/thread/1ro1mvkpvt4vr24nw7dbpdlxo82mq3hz > * Should we fix UTF-8 issues? > https://lists.apache.org/thread/sokxf46s7hyoxr9q4wm7dv3q2nm19nt3 -- 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-18077) Add SpotBugs to the build
[ https://issues.apache.org/jira/browse/CASSANDRA-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-18077: -- Status: Open (was: Patch Available) > Add SpotBugs to the build > - > > Key: CASSANDRA-18077 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18077 > Project: Cassandra > Issue Type: Improvement > Components: Build, CI >Reporter: David Capwell >Priority: Normal > Fix For: 4.x > > Attachments: spotbugs.html > > Time Spent: 50m > Remaining Estimate: 0h > > When working on CASSANDRA-17178 I found that several classes were being > reported by the Simulator for not defining serializer version when they are > Serializable; this may cause issues for the Simulator so felt it would be > best to detect these earlier on before merging new ones. > SpotBugs has a large set of checks, some more valuable than others for the > project; so we should maintain a curated list of issues to fail the build on, > and others to warn on. > This topic was discussed in the following mail threads: > * Should we add?: > https://lists.apache.org/thread/1ro1mvkpvt4vr24nw7dbpdlxo82mq3hz > * Should we fix UTF-8 issues? > https://lists.apache.org/thread/sokxf46s7hyoxr9q4wm7dv3q2nm19nt3 -- 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-18077) Add SpotBugs to the build
[ https://issues.apache.org/jira/browse/CASSANDRA-18077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell reassigned CASSANDRA-18077: - Assignee: (was: David Capwell) > Add SpotBugs to the build > - > > Key: CASSANDRA-18077 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18077 > Project: Cassandra > Issue Type: Improvement > Components: Build, CI >Reporter: David Capwell >Priority: Normal > Fix For: 4.x > > Attachments: spotbugs.html > > Time Spent: 50m > Remaining Estimate: 0h > > When working on CASSANDRA-17178 I found that several classes were being > reported by the Simulator for not defining serializer version when they are > Serializable; this may cause issues for the Simulator so felt it would be > best to detect these earlier on before merging new ones. > SpotBugs has a large set of checks, some more valuable than others for the > project; so we should maintain a curated list of issues to fail the build on, > and others to warn on. > This topic was discussed in the following mail threads: > * Should we add?: > https://lists.apache.org/thread/1ro1mvkpvt4vr24nw7dbpdlxo82mq3hz > * Should we fix UTF-8 issues? > https://lists.apache.org/thread/sokxf46s7hyoxr9q4wm7dv3q2nm19nt3 -- 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: Refactor AccordTestBase to block retries on non-idempotent transactions. Some tests may be flaky now due to Preempted being thrown.
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 8d8283b909 Refactor AccordTestBase to block retries on non-idempotent
transactions. Some tests may be flaky now due to Preempted being thrown.
8d8283b909 is described below
commit 8d8283b90935b1436aeb3245fa671e5b6a93be3e
Author: David Capwell
AuthorDate: Mon Dec 19 16:07:20 2022 -0800
Refactor AccordTestBase to block retries on non-idempotent transactions.
Some tests may be flaky now due to Preempted being thrown.
---
.../cql3/statements/ModificationStatement.java | 12
.../cql3/statements/TransactionStatement.java | 5 ++
.../cql3/transactions/ReferenceOperation.java | 10 +++
.../distributed/test/accord/AccordCQLTest.java | 10 +--
.../distributed/test/accord/AccordTestBase.java| 71 --
5 files changed, 97 insertions(+), 11 deletions(-)
diff --git
a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
index 83f52a4a0b..89519df844 100644
--- a/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java
@@ -809,6 +809,18 @@ public abstract class ModificationStatement implements
CQLStatement.SingleKeyspa
return new TxnReferenceOperations(metadata, clustering, regularOps,
staticOps);
}
+@VisibleForTesting
+public void migrateReadRequiredOperations()
+{
+operations.migrateReadRequiredOperations();
+}
+
+@VisibleForTesting
+public List getSubstitutions()
+{
+return operations.allSubstitutions();
+}
+
public TxnWrite.Fragment getTxnWriteFragment(int index, ClientState state,
QueryOptions options)
{
// When an Operation requires a read, this cannot be done right away
and must be done by the transaction itself,
diff --git
a/src/java/org/apache/cassandra/cql3/statements/TransactionStatement.java
b/src/java/org/apache/cassandra/cql3/statements/TransactionStatement.java
index baead627dc..4d3c732da0 100644
--- a/src/java/org/apache/cassandra/cql3/statements/TransactionStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/TransactionStatement.java
@@ -131,6 +131,11 @@ public class TransactionStatement implements CQLStatement
this.bindVariables = bindVariables;
}
+public List getUpdates()
+{
+return updates;
+}
+
@Override
public List getBindVariables()
{
diff --git
a/src/java/org/apache/cassandra/cql3/transactions/ReferenceOperation.java
b/src/java/org/apache/cassandra/cql3/transactions/ReferenceOperation.java
index e89e616545..d4858eec8e 100644
--- a/src/java/org/apache/cassandra/cql3/transactions/ReferenceOperation.java
+++ b/src/java/org/apache/cassandra/cql3/transactions/ReferenceOperation.java
@@ -76,6 +76,16 @@ public class ReferenceOperation
return new ReferenceOperation(receiver, kind, key, field, value);
}
+public TxnReferenceOperation.Kind getKind()
+{
+return kind;
+}
+
+public ReferenceValue getValue()
+{
+return value;
+}
+
public ColumnMetadata getReceiver()
{
return receiver;
diff --git
a/test/distributed/org/apache/cassandra/distributed/test/accord/AccordCQLTest.java
b/test/distributed/org/apache/cassandra/distributed/test/accord/AccordCQLTest.java
index 50318a00d1..1315bed14f 100644
---
a/test/distributed/org/apache/cassandra/distributed/test/accord/AccordCQLTest.java
+++
b/test/distributed/org/apache/cassandra/distributed/test/accord/AccordCQLTest.java
@@ -400,7 +400,7 @@ public class AccordCQLTest extends AccordTestBase
" SELECT row1.v;\n" +
" UPDATE " + currentTable + " SET v " +
operation + " 1 WHERE k = 1;\n" +
"COMMIT TRANSACTION";
- assertRowEqualsWithPreemptedRetry(cluster, new Object[] {
startingValue }, update);
+ assertRowEquals(cluster, new Object[] { startingValue },
update);
String check = "BEGIN TRANSACTION\n" +
" SELECT v FROM " + currentTable + " WHERE k
= 1;\n" +
@@ -1424,7 +1424,7 @@ public class AccordCQLTest extends AccordTestBase
" SELECT row0.counter,
row0.other_counter;\n" +
" UPDATE " + currentTable + " SET
other_counter += 1, counter += row0.counter WHERE k = 0 AND c = 1;\n" +
"COMMIT TRANSACTION";
- assertRowEqualsWithPreemptedRetry(cluster, new Object[] { 1,
1 }, update);
+ assertRowEquals(cluster, new
[jira] [Comment Edited] (CASSANDRA-18099) Use checked casts when reading vints as ints
[ https://issues.apache.org/jira/browse/CASSANDRA-18099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649985#comment-17649985 ] Ariel Weisberg edited comment on CASSANDRA-18099 at 12/20/22 9:07 PM: -- Have +1s from [~maedhroz] and [~dcapwell] , [waiting on tests|https://app.circleci.com/pipelines/github/aweisberg/cassandra/71]. was (Author: aweisberg): Have +1s from [~maedhroz] and [~dcapwell] , [waiting on tests|[https://app.circleci.com/pipelines/github/aweisberg/cassandra/71]]. > Use checked casts when reading vints as ints > > > Key: CASSANDRA-18099 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18099 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client, Messaging/Internode, Messaging/Thrift >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > Add some safety and a new convenience method to make clear that getting an > int can be done using a checked method. No need to import a separate class. -- 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-18099) Use checked casts when reading vints as ints
[ https://issues.apache.org/jira/browse/CASSANDRA-18099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-18099: --- Status: Ready to Commit (was: Review In Progress) Have +1s from [~maedhroz] and [~dcapwell] , [waiting on tests|[https://app.circleci.com/pipelines/github/aweisberg/cassandra/71]]. > Use checked casts when reading vints as ints > > > Key: CASSANDRA-18099 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18099 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client, Messaging/Internode, Messaging/Thrift >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Normal > > Add some safety and a new convenience method to make clear that getting an > int can be done using a checked method. No need to import a separate class. -- 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 (60cb37eb1 -> 65a7d2516)
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 60cb37eb1 generate docs for b072ce0a new 65a7d2516 generate docs for b072ce0a 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 (60cb37eb1) \ N -- N -- N refs/heads/asf-staging (65a7d2516) 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 4970898 -> 4970898 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
[cassandra-website] branch asf-staging updated (cc8aa0356 -> 60cb37eb1)
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 cc8aa0356 generate docs for b072ce0a new 60cb37eb1 generate docs for b072ce0a 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 (cc8aa0356) \ N -- N -- N refs/heads/asf-staging (60cb37eb1) 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 4970898 -> 4970898 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] [Comment Edited] (CASSANDRA-14013) Data loss in snapshots keyspace after service restart
[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649434#comment-17649434
]
Paulo Motta edited comment on CASSANDRA-14013 at 12/20/22 7:16 PM:
---
{quote} In that case, could you add a test in SSTableLoaderTest as it was, that
it is loading it just fine without uuid as well?
{quote}
done
[here|https://github.com/pauloricardomg/cassandra/commit/9cc0f63171c60e927af18eb3256eb63a29916a43].
During a [CI
run|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2114/testReport/]
of the trunk patch, I realized the original regex was only accepting ".db"
sstable files, so it was failing to correctly parse other extensions (such as
.txt or .crc32). So I updated the regex to accept any extension on [this
commit|https://github.com/pauloricardomg/cassandra/commit/345222a3e2504a84ef91eb25e35ae23762c34178].
We could make the regex more prescriptive with only supported extensions, but
I don't think this is needed for now.
I prepared 4.0/4.1 patches with the less disruptive fix, and the trunk patch
with the improved regex-based fix:
|branch||CI||
|[CASSANDRA-14013-4.0|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-14013-4.0]|[#2115|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2115/]
(finished)|
|[CASSANDRA-14013-4.1|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-14013-4.1]|[#2121|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2121/]
(finished)|
|[CASSANDRA-14013-trunk|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-14013-trunk]|[#2125|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2125/]
(running)|
(will update state when CI is finished)
Are you ok with the improved regex fix to trunk [~blerer], while having the
simpler fix on 4.x to reduce risk on released versions?
was (Author: paulo):
{quote} In that case, could you add a test in SSTableLoaderTest as it was, that
it is loading it just fine without uuid as well?
{quote}
done
[here|https://github.com/pauloricardomg/cassandra/commit/9cc0f63171c60e927af18eb3256eb63a29916a43].
During a [CI
run|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2114/testReport/]
of the trunk patch, I realized the original regex was only accepting ".db"
sstable files, so it was failing to correctly parse other extensions (such as
.txt or .crc32). So I updated the regex to accept any extension on [this
commit|https://github.com/pauloricardomg/cassandra/commit/345222a3e2504a84ef91eb25e35ae23762c34178].
We could make the regex more prescriptive with only supported extensions, but
I don't think this is needed for now.
I prepared 4.0/4.1 patches with the less disruptive fix, and the trunk patch
with the improved regex-based fix:
|branch||CI||
|[CASSANDRA-14013-4.0|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-14013-4.0]|[#2115|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2115/]
(finished)|
|[CASSANDRA-14013-4.1|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-14013-4.1]|[#2121|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2122/]
(running)|
|[CASSANDRA-14013-trunk|https://github.com/pauloricardomg/cassandra/tree/CASSANDRA-14013-trunk]|[#2122|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2122/]
(running)|
(will update state when CI is finished)
Are you ok with the improved regex fix to trunk [~blerer], while having the
simpler fix on 4.x to reduce risk on released versions?
> Data loss in snapshots keyspace after service restart
> -
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Local/Snapshots
>Reporter: Gregor Uhlenheuer
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
>
[cassandra-website] branch asf-staging updated (6e775b57d -> cc8aa0356)
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 6e775b57d generate docs for b072ce0a new cc8aa0356 generate docs for b072ce0a 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 (6e775b57d) \ N -- N -- N refs/heads/asf-staging (cc8aa0356) 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 4970898 -> 4970898 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-17797) All system properties and environment variables should be accessed via the new CassandraRelevantProperties and CassandraRelevantEnv classes
[ https://issues.apache.org/jira/browse/CASSANDRA-17797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17797: -- Status: Changes Suggested (was: Review In Progress) > All system properties and environment variables should be accessed via the > new CassandraRelevantProperties and CassandraRelevantEnv classes > --- > > Key: CASSANDRA-17797 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17797 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Low > Fix For: 4.x > > Time Spent: 6h 10m > Remaining Estimate: 0h > > Follow up ticket for CASSANDRA-15876 - > "Always access system properties and environment variables via the new > CassandraRelevantProperties and CassandraRelevantEnv classes" > As part of that ticket we moved to the two new classes only > properties/variables that were currently listed in System Properties Virtual > Table. > We have to move to those classes the rest of the properties around the code > and start using those classes to access all of them. > +Additional information for newcomers:+ > You might want to start by getting acquainted with > CassandraRelevantProperties and CassandraRelevantEnv classes. Also, you might > want to check what changes were done and how the first batch was transferred > to this new framework as part of > [CASSANDRA-15876|https://github.com/apache/cassandra/commit/7694c1d191531ac152db55e83bc0db6864a5441e] > We are interested into the properties accessed currently through > getProperties around the code. > As part of CASSANDRA-15876 relevant unit tests were added > (CassandraRelevantPropertiesTest). To verify the new patch we need to ensure > that all tests Cassandra pass and also to think about potential update of the > mentioned test class. -- 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-17797) All system properties and environment variables should be accessed via the new CassandraRelevantProperties and CassandraRelevantEnv classes
[ https://issues.apache.org/jira/browse/CASSANDRA-17797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649895#comment-17649895 ] Stefan Miklosovic commented on CASSANDRA-17797: --- Hi [~mmuzaf], I did the review and I went through all stuff in src. I will continue with tests next year, I think I have enough for now, it is a big patch. > All system properties and environment variables should be accessed via the > new CassandraRelevantProperties and CassandraRelevantEnv classes > --- > > Key: CASSANDRA-17797 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17797 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Low > Fix For: 4.x > > Time Spent: 6h 10m > Remaining Estimate: 0h > > Follow up ticket for CASSANDRA-15876 - > "Always access system properties and environment variables via the new > CassandraRelevantProperties and CassandraRelevantEnv classes" > As part of that ticket we moved to the two new classes only > properties/variables that were currently listed in System Properties Virtual > Table. > We have to move to those classes the rest of the properties around the code > and start using those classes to access all of them. > +Additional information for newcomers:+ > You might want to start by getting acquainted with > CassandraRelevantProperties and CassandraRelevantEnv classes. Also, you might > want to check what changes were done and how the first batch was transferred > to this new framework as part of > [CASSANDRA-15876|https://github.com/apache/cassandra/commit/7694c1d191531ac152db55e83bc0db6864a5441e] > We are interested into the properties accessed currently through > getProperties around the code. > As part of CASSANDRA-15876 relevant unit tests were added > (CassandraRelevantPropertiesTest). To verify the new patch we need to ensure > that all tests Cassandra pass and also to think about potential update of the > mentioned test class. -- 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 (83759f049 -> 6e775b57d)
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 83759f049 generate docs for b072ce0a new 6e775b57d generate docs for b072ce0a 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 (83759f049) \ N -- N -- N refs/heads/asf-staging (6e775b57d) 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 4970898 -> 4970898 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-17797) All system properties and environment variables should be accessed via the new CassandraRelevantProperties and CassandraRelevantEnv classes
[ https://issues.apache.org/jira/browse/CASSANDRA-17797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17797: -- Status: Review In Progress (was: Needs Committer) > All system properties and environment variables should be accessed via the > new CassandraRelevantProperties and CassandraRelevantEnv classes > --- > > Key: CASSANDRA-17797 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17797 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Maxim Muzafarov >Priority: Low > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Follow up ticket for CASSANDRA-15876 - > "Always access system properties and environment variables via the new > CassandraRelevantProperties and CassandraRelevantEnv classes" > As part of that ticket we moved to the two new classes only > properties/variables that were currently listed in System Properties Virtual > Table. > We have to move to those classes the rest of the properties around the code > and start using those classes to access all of them. > +Additional information for newcomers:+ > You might want to start by getting acquainted with > CassandraRelevantProperties and CassandraRelevantEnv classes. Also, you might > want to check what changes were done and how the first batch was transferred > to this new framework as part of > [CASSANDRA-15876|https://github.com/apache/cassandra/commit/7694c1d191531ac152db55e83bc0db6864a5441e] > We are interested into the properties accessed currently through > getProperties around the code. > As part of CASSANDRA-15876 relevant unit tests were added > (CassandraRelevantPropertiesTest). To verify the new patch we need to ensure > that all tests Cassandra pass and also to think about potential update of the > mentioned test class. -- 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-18035) Add quick start development guide and docker ant targets
[
https://issues.apache.org/jira/browse/CASSANDRA-18035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649717#comment-17649717
]
Stefan Miklosovic edited comment on CASSANDRA-18035 at 12/20/22 12:31 PM:
--
I found some time to test this already, couldnt resist! I put some comments to
PR as well.
All looks good, the only thing which might be improved is this, check the
output. What I would expect that when docker-start target is finished, I can
truly execute nodetool's commands against that. I am not sure how the start of
the container is evaluated but I would do it in such a way that unless nodetool
status does not return 0 exit code, it will be still "starting".
Also, there are language constructs used when we are not compatible with POSIX
sh. I am not sure what agreement we have here. I _think_ that scripts which are
not used in production may be based on bash(isms). Nevertheless there are still
some micro-improvements in these script to be made.
{code:java}
✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:12 $ ant docker-start
Buildfile: /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/build.xml
docker-start:
[exec] 9c68a50bcc260c1c1ce8af5cfb9ce9f2e634cadaeda50688c52b9206ba8ab4b3
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] cassandra-test container started with id
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0
[exec]
[exec] Use 'docker-exec -it cassandra-test ' to execute commands on
this container.
[exec] ie. docker exec -it cassandra-test nodetool status
[exec] ie. docker exec -it cassandra-test cqlsh
BUILD SUCCESSFUL
Total time: 31 seconds
✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:12 $ docker exec -it cassandra-test nodetool status
Error: No nodes present in the cluster. Has this node finished starting up?
✘-1 ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:12 $ docker exec -it cassandra-test nodetool status
Error: No nodes present in the cluster. Has this node finished starting up?
✘-1 ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:13 $ docker exec -it cassandra-test nodetool status
Error: No nodes present in the cluster. Has this node finished starting up?
✘-1 ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:13 $ docker exec -it cassandra-test nodetool status
Error: No nodes present in the cluster. Has this node finished starting up?
✘-1 ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:13 $ docker exec -it cassandra-test nodetool status
Datacenter: datacenter1
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address LoadTokens Owns (effective) Host ID
Rack
UN 172.20.0.2 130.46 KiB 16 100.0%
e966c776-351b-422e-aa05-4c21091eabd2 rack1
{code}
was (Author: smiklosovic):
I found some time to test this already, couldnt resist! I put some comments to
PR as well.
All looks good, the only thing which might be improved is this, check the
output. What I would expect that when docker-start target is finished, I can
truly execute nodetool's commands against that. I am not sure how the start of
the container is evaluated but I would do it in such a way that unless nodetool
status does not return 0 exit code, it will be still "starting".
{code:java}
✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:12 $ ant docker-start
Buildfile: /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/build.xml
docker-start:
[exec] 9c68a50bcc260c1c1ce8af5cfb9ce9f2e634cadaeda50688c52b9206ba8ab4b3
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
[jira] [Updated] (CASSANDRA-17970) Avoid anticompaction mixing data from two different time windows with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-17970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17970: -- Status: Ready to Commit (was: Review In Progress) +1, with one ignorable test nit in PR comments. > Avoid anticompaction mixing data from two different time windows with TWCS > -- > > Key: CASSANDRA-17970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17970 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/TWCS >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Time Spent: 40m > Remaining Estimate: 0h > > When grouping sstables for anticompaction we can currently get sstables from > different time windows when running TWCS -- 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-17970) Avoid anticompaction mixing data from two different time windows with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-17970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17970: -- Reviewers: Aleksey Yeschenko, Aleksey Yeschenko (was: Aleksey Yeschenko) Aleksey Yeschenko, Aleksey Yeschenko (was: Aleksey Yeschenko) Status: Review In Progress (was: Patch Available) > Avoid anticompaction mixing data from two different time windows with TWCS > -- > > Key: CASSANDRA-17970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17970 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/TWCS >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Time Spent: 40m > Remaining Estimate: 0h > > When grouping sstables for anticompaction we can currently get sstables from > different time windows when running TWCS -- 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-17970) Avoid anticompaction mixing data from two different time windows with TWCS
[ https://issues.apache.org/jira/browse/CASSANDRA-17970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Yeschenko updated CASSANDRA-17970: -- Reviewers: Aleksey Yeschenko (was: Jon Meredith) > Avoid anticompaction mixing data from two different time windows with TWCS > -- > > Key: CASSANDRA-17970 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17970 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/TWCS >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Time Spent: 40m > Remaining Estimate: 0h > > When grouping sstables for anticompaction we can currently get sstables from > different time windows when running TWCS -- 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-18035) Add quick start development guide and docker ant targets
[
https://issues.apache.org/jira/browse/CASSANDRA-18035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649717#comment-17649717
]
Stefan Miklosovic edited comment on CASSANDRA-18035 at 12/20/22 12:18 PM:
--
I found some time to test this already, couldnt resist! I put some comments to
PR as well.
All looks good, the only thing which might be improved is this, check the
output. What I would expect that when docker-start target is finished, I can
truly execute nodetool's commands against that. I am not sure how the start of
the container is evaluated but I would do it in such a way that unless nodetool
status does not return 0 exit code, it will be still "starting".
{code:java}
✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:12 $ ant docker-start
Buildfile: /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/build.xml
docker-start:
[exec] 9c68a50bcc260c1c1ce8af5cfb9ce9f2e634cadaeda50688c52b9206ba8ab4b3
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] cassandra-test container started with id
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0
[exec]
[exec] Use 'docker-exec -it cassandra-test ' to execute commands on
this container.
[exec] ie. docker exec -it cassandra-test nodetool status
[exec] ie. docker exec -it cassandra-test cqlsh
BUILD SUCCESSFUL
Total time: 31 seconds
✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:12 $ docker exec -it cassandra-test nodetool status
Error: No nodes present in the cluster. Has this node finished starting up?
✘-1 ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:12 $ docker exec -it cassandra-test nodetool status
Error: No nodes present in the cluster. Has this node finished starting up?
✘-1 ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:13 $ docker exec -it cassandra-test nodetool status
Error: No nodes present in the cluster. Has this node finished starting up?
✘-1 ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:13 $ docker exec -it cassandra-test nodetool status
Error: No nodes present in the cluster. Has this node finished starting up?
✘-1 ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:13 $ docker exec -it cassandra-test nodetool status
Datacenter: datacenter1
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address LoadTokens Owns (effective) Host ID
Rack
UN 172.20.0.2 130.46 KiB 16 100.0%
e966c776-351b-422e-aa05-4c21091eabd2 rack1
{code}
was (Author: smiklosovic):
I found some time to test this already, couldnt resist!
All looks good, the only thing which might be improved is this, check the
output. What I would expect that when docker-start target is finished, I can
truly execute nodetool's commands against that. I am not sure how the start of
the container is evaluated but I would do it in such a way that unless nodetool
status does not return 0 exit code, it will be still "starting".
{code}
✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:12 $ ant docker-start
Buildfile: /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/build.xml
docker-start:
[exec] 9c68a50bcc260c1c1ce8af5cfb9ce9f2e634cadaeda50688c52b9206ba8ab4b3
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] cassandra-test
[jira] [Updated] (CASSANDRA-18035) Add quick start development guide and docker ant targets
[
https://issues.apache.org/jira/browse/CASSANDRA-18035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18035:
--
Status: Changes Suggested (was: Review In Progress)
> Add quick start development guide and docker ant targets
>
>
> Key: CASSANDRA-18035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18035
> Project: Cassandra
> Issue Type: Task
> Components: Documentation
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I propose adding a new {{QUICKSTART.md}} guide that provides instructions to
> beginner contributors on how to:
> a) Setup a development environment and IDE from scratch on WSL/Ubuntu/Debian
> environments
> b) Run a simple unit test from the IDE
> c) Create a simple patch that prints "Hello World" during Cassandra
> initialization
> d) Test the patch on a local docker instance
> A new {{docker/}} directory is added along with the guide with the following
> utilities:
> a) Dockerfile: unoptimized vanilla docker image manifest suitable only for
> local dev testing.
> b) build.sh: build a cassandra artifact and cassandra-test image.
> c) start.sh: start local cassandra-test container.
> d) stop.sh: stop local-cassandra test container.
> A couple of follow-up improvements that come to mind:
> - Add ant targets to build/start/stop cassandra-test container.
> - Add OSX instructions.
> - More IDE setup instructions (ie. Eclipse/VScode).
> - A more involved Hello World example, perhaps creating a dummy VirtualTable
> with unit/dtests.
> - Update Dockerfile to point to build/ instead of creating an artifact.
> A DEV mailing list message was sent to gather community feedback on this
> proposal: https://lists.apache.org/thread/gmb0q5yb2bzbs0cjw7mlcz1vwk2l23g2
--
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-18035) Add quick start development guide and docker ant targets
[
https://issues.apache.org/jira/browse/CASSANDRA-18035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18035:
--
Status: Review In Progress (was: Patch Available)
> Add quick start development guide and docker ant targets
>
>
> Key: CASSANDRA-18035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18035
> Project: Cassandra
> Issue Type: Task
> Components: Documentation
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I propose adding a new {{QUICKSTART.md}} guide that provides instructions to
> beginner contributors on how to:
> a) Setup a development environment and IDE from scratch on WSL/Ubuntu/Debian
> environments
> b) Run a simple unit test from the IDE
> c) Create a simple patch that prints "Hello World" during Cassandra
> initialization
> d) Test the patch on a local docker instance
> A new {{docker/}} directory is added along with the guide with the following
> utilities:
> a) Dockerfile: unoptimized vanilla docker image manifest suitable only for
> local dev testing.
> b) build.sh: build a cassandra artifact and cassandra-test image.
> c) start.sh: start local cassandra-test container.
> d) stop.sh: stop local-cassandra test container.
> A couple of follow-up improvements that come to mind:
> - Add ant targets to build/start/stop cassandra-test container.
> - Add OSX instructions.
> - More IDE setup instructions (ie. Eclipse/VScode).
> - A more involved Hello World example, perhaps creating a dummy VirtualTable
> with unit/dtests.
> - Update Dockerfile to point to build/ instead of creating an artifact.
> A DEV mailing list message was sent to gather community feedback on this
> proposal: https://lists.apache.org/thread/gmb0q5yb2bzbs0cjw7mlcz1vwk2l23g2
--
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-18035) Add quick start development guide and docker ant targets
[
https://issues.apache.org/jira/browse/CASSANDRA-18035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649717#comment-17649717
]
Stefan Miklosovic commented on CASSANDRA-18035:
---
I found some time to test this already, couldnt resist!
All looks good, the only thing which might be improved is this, check the
output. What I would expect that when docker-start target is finished, I can
truly execute nodetool's commands against that. I am not sure how the start of
the container is evaluated but I would do it in such a way that unless nodetool
status does not return 0 exit code, it will be still "starting".
{code}
✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:12 $ ant docker-start
Buildfile: /home/fermat/dev/cassandra/cassandra-instaclustr/cassandra/build.xml
docker-start:
[exec] 9c68a50bcc260c1c1ce8af5cfb9ce9f2e634cadaeda50688c52b9206ba8ab4b3
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] Waiting for cassandra-test container
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0 to start.
[exec] cassandra-test container started with id
b434586cdf88600cbc4d231fb6baf4131aa96acb536969b9b7c5f2bb7938b8e0
[exec]
[exec] Use 'docker-exec -it cassandra-test ' to execute commands on
this container.
[exec] ie. docker exec -it cassandra-test nodetool status
[exec] ie. docker exec -it cassandra-test cqlsh
BUILD SUCCESSFUL
Total time: 31 seconds
✔ ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:12 $ docker exec -it cassandra-test nodetool status
Error: No nodes present in the cluster. Has this node finished starting up?
✘-1 ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:12 $ docker exec -it cassandra-test nodetool status
Error: No nodes present in the cluster. Has this node finished starting up?
✘-1 ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:13 $ docker exec -it cassandra-test nodetool status
Error: No nodes present in the cluster. Has this node finished starting up?
✘-1 ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:13 $ docker exec -it cassandra-test nodetool status
Error: No nodes present in the cluster. Has this node finished starting up?
✘-1 ~/dev/cassandra/cassandra-instaclustr/cassandra [CASSANDRA-18035 L|● 1]
13:13 $ docker exec -it cassandra-test nodetool status
Datacenter: datacenter1
===
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address LoadTokens Owns (effective) Host ID
Rack
UN 172.20.0.2 130.46 KiB 16 100.0%
e966c776-351b-422e-aa05-4c21091eabd2 rack1
{code}
> Add quick start development guide and docker ant targets
>
>
> Key: CASSANDRA-18035
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18035
> Project: Cassandra
> Issue Type: Task
> Components: Documentation
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I propose adding a new {{QUICKSTART.md}} guide that provides instructions to
> beginner contributors on how to:
> a) Setup a development environment and IDE from scratch on WSL/Ubuntu/Debian
> environments
> b) Run a simple unit test from the IDE
> c) Create a simple patch that prints "Hello World" during Cassandra
> initialization
> d) Test the patch on a local docker instance
> A new {{docker/}} directory is added along with the guide with the following
> utilities:
> a) Dockerfile: unoptimized vanilla docker image manifest suitable only for
> local dev testing.
> b) build.sh: build a cassandra artifact and cassandra-test image.
> c) start.sh: start local cassandra-test container.
> d) stop.sh: stop local-cassandra test container.
> A couple of follow-up improvements that come to mind:
> - Add ant targets to build/start/stop cassandra-test container.
> - Add OSX instructions.
> - More IDE setup instructions (ie. Eclipse/VScode).
> - A more involved Hello World example, perhaps creating a dummy VirtualTable
> with unit/dtests.
> - Update Dockerfile to point to build/ instead of creating an
[jira] [Comment Edited] (CASSANDRA-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[
https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649711#comment-17649711
]
Andres de la Peña edited comment on CASSANDRA-14361 at 12/20/22 12:09 PM:
--
[~smiklosovic] being an improvement I think it should go to trunk only.
[~jkoppenhofer] as mentioned above, there are still a few nits to resolve on
[the PR|https://github.com/apache/cassandra/pull/599], and the suggestion about
the {{seed_provider}} section. We will also need a rebase and a CI run, given
that this has been inactive for a while.
was (Author: adelapena):
[~smiklosovic] being an improvement I think it should go to trunk only.
[~jkoppenhofer] as mentioned above, there are still a few nits to resolve on
[the PR|https://github.com/apache/cassandra/pull/599], and the suggestion about
the {{seed_provider}} section.
> Allow SimpleSeedProvider to resolve multiple IPs per DNS name
> -
>
> Key: CASSANDRA-14361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14361
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ben Bromhead
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 4.0.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently SimpleSeedProvider can accept a comma separated string of IPs or
> hostnames as the set of Cassandra seeds. hostnames are resolved via
> InetAddress.getByName, which will only return the first IP associated with an
> A, or CNAME record.
> By changing to InetAddress.getAllByName, existing behavior is preserved, but
> now Cassandra can discover multiple IP address per record, allowing seed
> discovery by DNS to be a little easier.
> Some examples of improved workflows with this change include:
> * specify the DNS name of a headless service in Kubernetes which will
> resolve to all IP addresses of pods within that service.
> * seed discovery for multi-region clusters via AWS route53, AzureDNS etc
> * Other common DNS service discovery mechanisms.
> The only behavior this is likely to impact would be where users are relying
> on the fact that getByName only returns a single IP address.
> I can't imagine any scenario where that is a sane choice. Even when that
> choice has been made, it only impacts the first startup of Cassandra and
> would not be on any critical path.
--
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-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[
https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649711#comment-17649711
]
Andres de la Peña edited comment on CASSANDRA-14361 at 12/20/22 12:08 PM:
--
[~smiklosovic] being an improvement I think it should go to trunk only.
[~jkoppenhofer] as mentioned above, there are still a few nits to resolve on
[the PR|https://github.com/apache/cassandra/pull/599], and the suggestion about
the {{seed_provider}} section.
was (Author: adelapena):
[~smiklosovic] being an improvement I think it should go to trunk only.
[~jkoppenhofer] as mentioned above, there are still a few nits to resolve on
[the PR|https://github.com/apache/cassandra/pull/599], and the suggestion about
the {{seed_provider}} section.
> Allow SimpleSeedProvider to resolve multiple IPs per DNS name
> -
>
> Key: CASSANDRA-14361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14361
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ben Bromhead
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 4.0.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently SimpleSeedProvider can accept a comma separated string of IPs or
> hostnames as the set of Cassandra seeds. hostnames are resolved via
> InetAddress.getByName, which will only return the first IP associated with an
> A, or CNAME record.
> By changing to InetAddress.getAllByName, existing behavior is preserved, but
> now Cassandra can discover multiple IP address per record, allowing seed
> discovery by DNS to be a little easier.
> Some examples of improved workflows with this change include:
> * specify the DNS name of a headless service in Kubernetes which will
> resolve to all IP addresses of pods within that service.
> * seed discovery for multi-region clusters via AWS route53, AzureDNS etc
> * Other common DNS service discovery mechanisms.
> The only behavior this is likely to impact would be where users are relying
> on the fact that getByName only returns a single IP address.
> I can't imagine any scenario where that is a sane choice. Even when that
> choice has been made, it only impacts the first startup of Cassandra and
> would not be on any critical path.
--
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-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[
https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649711#comment-17649711
]
Andres de la Peña commented on CASSANDRA-14361:
---
[~smiklosovic] being an improvement I think it should go to trunk only.
[~jkoppenhofer] as mentioned above, there are still a few nits to resolve on
[the PR|https://github.com/apache/cassandra/pull/599], and the suggestion about
the {{seed_provider}} section.
> Allow SimpleSeedProvider to resolve multiple IPs per DNS name
> -
>
> Key: CASSANDRA-14361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14361
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ben Bromhead
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 4.0.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently SimpleSeedProvider can accept a comma separated string of IPs or
> hostnames as the set of Cassandra seeds. hostnames are resolved via
> InetAddress.getByName, which will only return the first IP associated with an
> A, or CNAME record.
> By changing to InetAddress.getAllByName, existing behavior is preserved, but
> now Cassandra can discover multiple IP address per record, allowing seed
> discovery by DNS to be a little easier.
> Some examples of improved workflows with this change include:
> * specify the DNS name of a headless service in Kubernetes which will
> resolve to all IP addresses of pods within that service.
> * seed discovery for multi-region clusters via AWS route53, AzureDNS etc
> * Other common DNS service discovery mechanisms.
> The only behavior this is likely to impact would be where users are relying
> on the fact that getByName only returns a single IP address.
> I can't imagine any scenario where that is a sane choice. Even when that
> choice has been made, it only impacts the first startup of Cassandra and
> would not be on any critical path.
--
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-18126) Add to the IntelliJ Git Window issue navigation links to Cassandra's Jira
[
https://issues.apache.org/jira/browse/CASSANDRA-18126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18126:
--
Status: Ready to Commit (was: Review In Progress)
+1, nifty, works as advertised.
> Add to the IntelliJ Git Window issue navigation links to Cassandra's Jira
> -
>
> Key: CASSANDRA-18126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18126
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 4.x
>
> Attachments: Cassandra Apache Jira Link.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is possible to navigate from the IntelliJ IDEA Git window to a
> corresponding Cassandra issue, the Apache Jira if mentioned in the git
> message. The example in the attachments shows how _CASSANDRA-*_ letters are
> turned on in the commit message to an appropriate Cassandra Jira link.
> We should update the IntelliJ IDEA configuration and make this behaviour a
> default for the {{ant generate-idea-files}} process.
> To achieve this manually you can update your {{.idea/vcs.xml}} file in the
> Cassandra project with the following:
> {code:java}
>
>
>
>
>
>
>
>
>
>
> name="linkRegexp"value="https://issues.apache.org/jira/browse/CASSANDRA-$1"/>
>
>
>
>
>
> {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-18126) Add to the IntelliJ Git Window issue navigation links to Cassandra's Jira
[
https://issues.apache.org/jira/browse/CASSANDRA-18126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-18126:
--
Reviewers: Aleksey Yeschenko, David Capwell (was: David Capwell)
> Add to the IntelliJ Git Window issue navigation links to Cassandra's Jira
> -
>
> Key: CASSANDRA-18126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18126
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Normal
> Fix For: 4.x
>
> Attachments: Cassandra Apache Jira Link.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is possible to navigate from the IntelliJ IDEA Git window to a
> corresponding Cassandra issue, the Apache Jira if mentioned in the git
> message. The example in the attachments shows how _CASSANDRA-*_ letters are
> turned on in the commit message to an appropriate Cassandra Jira link.
> We should update the IntelliJ IDEA configuration and make this behaviour a
> default for the {{ant generate-idea-files}} process.
> To achieve this manually you can update your {{.idea/vcs.xml}} file in the
> Cassandra project with the following:
> {code:java}
>
>
>
>
>
>
>
>
>
>
> name="linkRegexp"value="https://issues.apache.org/jira/browse/CASSANDRA-$1"/>
>
>
>
>
>
> {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
[cassandra-website] branch asf-staging updated (bfb0ab0f5 -> 83759f049)
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 bfb0ab0f5 generate docs for b072ce0a new 83759f049 generate docs for b072ce0a 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 (bfb0ab0f5) \ N -- N -- N refs/heads/asf-staging (83759f049) 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 4970898 -> 4970898 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
[cassandra-website] branch asf-staging updated (f81006fa3 -> bfb0ab0f5)
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 f81006fa3 generate docs for b072ce0a new bfb0ab0f5 generate docs for b072ce0a 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 (f81006fa3) \ N -- N -- N refs/heads/asf-staging (bfb0ab0f5) 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 4970898 -> 4970898 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-18096) Do not spam the logs with MigrationCoordinator not able to pull schemas
[
https://issues.apache.org/jira/browse/CASSANDRA-18096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18096:
--
Summary: Do not spam the logs with MigrationCoordinator not able to pull
schemas (was: Do not spam the logs with MigrationCoordinator not able to pull
schemas on bootstrap)
> Do not spam the logs with MigrationCoordinator not able to pull schemas
> ---
>
> Key: CASSANDRA-18096
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18096
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a node is joining a cluster, there is this output upon startup:
> {code}
> cassandra_node_6 | INFO [GossipStage:1] 2022-12-06 12:48:07,187
> Gossiper.java:1413 - Node /172.19.0.5:7000 is now part of the cluster
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> {code}
> This is there for a lot of already existing nodes. You got the idea. This log
> is misleading, it indeed can not pull requests because "node is down" but it
> is not down, it just thinks it is because Gossiper has not had a chance to
> receive any gossip about these nodes _yet_.
> I put there more logs and it writes this:
> {code}
> MigrationCoordinator.java:655 - Can't send schema pull request: node
> /172.19.0.5:7000 is down: NORMAL, isAlive: false
> {code}
> When I do this:
> {code}
> if (!gossiper.hasEndpointState(endpoint))
> return;
> if (!gossiper.isAlive(endpoint))
> {
> EndpointState endpointStateForEndpoint =
> gossiper.getEndpointStateForEndpoint(endpoint);
> String status =
> Gossiper.getGossipStatus(endpointStateForEndpoint);
> logger.warn("Can't send schema pull request: node {} is down: {},
> isAlive: {}", endpoint, status, endpointStateForEndpoint.isAlive());
> callback.onFailure(endpoint, RequestFailureReason.UNKNOWN);
> return;
> }
> {code}
> So it is in NORMAL but it is not alive yet which is quite strange.
> The fix is to still return prematurely but we would not skip the logging on
> WARN only in case isAlive is false and status is _not_NORMAL. We would
> however still log on TRACE at least.
> (1)
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/MigrationCoordinator.java#L648-L653
--
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-17773) Incorrect cassandra.logdir on Debian systems
[ https://issues.apache.org/jira/browse/CASSANDRA-17773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17773: -- Fix Version/s: 4.x > Incorrect cassandra.logdir on Debian systems > > > Key: CASSANDRA-17773 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17773 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Eric Evans >Assignee: Claude Warren >Priority: Normal > Labels: lhf > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 1h 50m > Remaining Estimate: 0h > > The Debian packaging patches bin/cassandra to use /var/log/cassandra for > logs, it does so conditionally however, only if CASSANDRA_LOG_DIR is unset. > This occurs _after_ cassandra-env.sh is sourced though, which also sets > CASSANDRA_LOG_DIR if unset (to $CASSANDRA_HOME/logs). The result is that > -Dcassandra.lodir is set to /usr/share/cassandra/logs on Debian systems. -- 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-17964) Some tests are never executed due to naming violation - fix it and add checkstyle where applicable
[ https://issues.apache.org/jira/browse/CASSANDRA-17964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649682#comment-17649682 ] Stefan Miklosovic commented on CASSANDRA-17964: --- I ll return to this next year. No rush. > Some tests are never executed due to naming violation - fix it and add > checkstyle where applicable > -- > > Key: CASSANDRA-17964 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17964 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Ruslan Fomkin >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 40m > Remaining Estimate: 0h > > [BatchTests|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/BatchTests.java] > doesn't follow naming convention to be run as unit tests and, thus, is never > run. > The rule in build expects names as `*Test`. -- 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-18096) Do not spam the logs with MigrationCoordinator not able to pull schemas on bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-18096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18096:
--
Fix Version/s: 3.0.29
3.11.15
4.0.8
4.1.1
4.2
(was: 3.0.x)
(was: 4.x)
(was: 3.11.x)
(was: 4.0.x)
(was: 4.1.x)
Source Control Link:
https://github.com/apache/cassandra/commit/f55b2fb1b3a8af03a3424abfe7afa2ac60ac9dff
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Do not spam the logs with MigrationCoordinator not able to pull schemas on
> bootstrap
>
>
> Key: CASSANDRA-18096
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18096
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 3.0.29, 3.11.15, 4.0.8, 4.1.1, 4.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a node is joining a cluster, there is this output upon startup:
> {code}
> cassandra_node_6 | INFO [GossipStage:1] 2022-12-06 12:48:07,187
> Gossiper.java:1413 - Node /172.19.0.5:7000 is now part of the cluster
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> {code}
> This is there for a lot of already existing nodes. You got the idea. This log
> is misleading, it indeed can not pull requests because "node is down" but it
> is not down, it just thinks it is because Gossiper has not had a chance to
> receive any gossip about these nodes _yet_.
> I put there more logs and it writes this:
> {code}
> MigrationCoordinator.java:655 - Can't send schema pull request: node
> /172.19.0.5:7000 is down: NORMAL, isAlive: false
> {code}
> When I do this:
> {code}
> if (!gossiper.hasEndpointState(endpoint))
> return;
> if (!gossiper.isAlive(endpoint))
> {
> EndpointState endpointStateForEndpoint =
> gossiper.getEndpointStateForEndpoint(endpoint);
> String status =
> Gossiper.getGossipStatus(endpointStateForEndpoint);
> logger.warn("Can't send schema pull request: node {} is down: {},
> isAlive: {}", endpoint, status, endpointStateForEndpoint.isAlive());
> callback.onFailure(endpoint, RequestFailureReason.UNKNOWN);
> return;
> }
> {code}
> So it is in NORMAL but it is not alive yet which is quite strange.
> The fix is to still return prematurely but we would not skip the logging on
> WARN only in case isAlive is false and status is _not_NORMAL. We would
> however still log on TRACE at least.
> (1)
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/MigrationCoordinator.java#L648-L653
--
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-18096) Do not spam the logs with MigrationCoordinator not able to pull schemas on bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-18096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18096:
--
Status: Ready to Commit (was: Review In Progress)
> Do not spam the logs with MigrationCoordinator not able to pull schemas on
> bootstrap
>
>
> Key: CASSANDRA-18096
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18096
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a node is joining a cluster, there is this output upon startup:
> {code}
> cassandra_node_6 | INFO [GossipStage:1] 2022-12-06 12:48:07,187
> Gossiper.java:1413 - Node /172.19.0.5:7000 is now part of the cluster
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> {code}
> This is there for a lot of already existing nodes. You got the idea. This log
> is misleading, it indeed can not pull requests because "node is down" but it
> is not down, it just thinks it is because Gossiper has not had a chance to
> receive any gossip about these nodes _yet_.
> I put there more logs and it writes this:
> {code}
> MigrationCoordinator.java:655 - Can't send schema pull request: node
> /172.19.0.5:7000 is down: NORMAL, isAlive: false
> {code}
> When I do this:
> {code}
> if (!gossiper.hasEndpointState(endpoint))
> return;
> if (!gossiper.isAlive(endpoint))
> {
> EndpointState endpointStateForEndpoint =
> gossiper.getEndpointStateForEndpoint(endpoint);
> String status =
> Gossiper.getGossipStatus(endpointStateForEndpoint);
> logger.warn("Can't send schema pull request: node {} is down: {},
> isAlive: {}", endpoint, status, endpointStateForEndpoint.isAlive());
> callback.onFailure(endpoint, RequestFailureReason.UNKNOWN);
> return;
> }
> {code}
> So it is in NORMAL but it is not alive yet which is quite strange.
> The fix is to still return prematurely but we would not skip the logging on
> WARN only in case isAlive is false and status is _not_NORMAL. We would
> however still log on TRACE at least.
> (1)
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/MigrationCoordinator.java#L648-L653
--
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-18096) Do not spam the logs with MigrationCoordinator not able to pull schemas on bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-18096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18096:
--
Reviewers: Michael Semb Wever
Status: Review In Progress (was: Patch Available)
> Do not spam the logs with MigrationCoordinator not able to pull schemas on
> bootstrap
>
>
> Key: CASSANDRA-18096
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18096
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a node is joining a cluster, there is this output upon startup:
> {code}
> cassandra_node_6 | INFO [GossipStage:1] 2022-12-06 12:48:07,187
> Gossiper.java:1413 - Node /172.19.0.5:7000 is now part of the cluster
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> {code}
> This is there for a lot of already existing nodes. You got the idea. This log
> is misleading, it indeed can not pull requests because "node is down" but it
> is not down, it just thinks it is because Gossiper has not had a chance to
> receive any gossip about these nodes _yet_.
> I put there more logs and it writes this:
> {code}
> MigrationCoordinator.java:655 - Can't send schema pull request: node
> /172.19.0.5:7000 is down: NORMAL, isAlive: false
> {code}
> When I do this:
> {code}
> if (!gossiper.hasEndpointState(endpoint))
> return;
> if (!gossiper.isAlive(endpoint))
> {
> EndpointState endpointStateForEndpoint =
> gossiper.getEndpointStateForEndpoint(endpoint);
> String status =
> Gossiper.getGossipStatus(endpointStateForEndpoint);
> logger.warn("Can't send schema pull request: node {} is down: {},
> isAlive: {}", endpoint, status, endpointStateForEndpoint.isAlive());
> callback.onFailure(endpoint, RequestFailureReason.UNKNOWN);
> return;
> }
> {code}
> So it is in NORMAL but it is not alive yet which is quite strange.
> The fix is to still return prematurely but we would not skip the logging on
> WARN only in case isAlive is false and status is _not_NORMAL. We would
> however still log on TRACE at least.
> (1)
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/MigrationCoordinator.java#L648-L653
--
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-18096) Do not spam the logs with MigrationCoordinator not able to pull schemas on bootstrap
[
https://issues.apache.org/jira/browse/CASSANDRA-18096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649675#comment-17649675
]
Michael Semb Wever commented on CASSANDRA-18096:
+1
> Do not spam the logs with MigrationCoordinator not able to pull schemas on
> bootstrap
>
>
> Key: CASSANDRA-18096
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18096
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Schema
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Low
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a node is joining a cluster, there is this output upon startup:
> {code}
> cassandra_node_6 | INFO [GossipStage:1] 2022-12-06 12:48:07,187
> Gossiper.java:1413 - Node /172.19.0.5:7000 is now part of the cluster
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> cassandra_node_6 | WARN MigrationCoordinator.java:650 - Can't send schema
> pull request: node /172.19.0.5:7000 is down.
> {code}
> This is there for a lot of already existing nodes. You got the idea. This log
> is misleading, it indeed can not pull requests because "node is down" but it
> is not down, it just thinks it is because Gossiper has not had a chance to
> receive any gossip about these nodes _yet_.
> I put there more logs and it writes this:
> {code}
> MigrationCoordinator.java:655 - Can't send schema pull request: node
> /172.19.0.5:7000 is down: NORMAL, isAlive: false
> {code}
> When I do this:
> {code}
> if (!gossiper.hasEndpointState(endpoint))
> return;
> if (!gossiper.isAlive(endpoint))
> {
> EndpointState endpointStateForEndpoint =
> gossiper.getEndpointStateForEndpoint(endpoint);
> String status =
> Gossiper.getGossipStatus(endpointStateForEndpoint);
> logger.warn("Can't send schema pull request: node {} is down: {},
> isAlive: {}", endpoint, status, endpointStateForEndpoint.isAlive());
> callback.onFailure(endpoint, RequestFailureReason.UNKNOWN);
> return;
> }
> {code}
> So it is in NORMAL but it is not alive yet which is quite strange.
> The fix is to still return prematurely but we would not skip the logging on
> WARN only in case isAlive is false and status is _not_NORMAL. We would
> however still log on TRACE at least.
> (1)
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/MigrationCoordinator.java#L648-L653
--
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.0 updated (f01d2b4a3c -> ace3920239)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from f01d2b4a3c Restore custom param types over messaging system add f55b2fb1b3 Do not spam the logs with MigrationCoordinator not being able to pull schemas add baa9d0327f Merge branch 'cassandra-3.0' into cassandra-3.11 add ace3920239 Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + src/java/org/apache/cassandra/schema/MigrationCoordinator.java | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (227409d920 -> b171b4ba29)
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 227409d920 Add Mutation Serialization Caching add f55b2fb1b3 Do not spam the logs with MigrationCoordinator not being able to pull schemas add baa9d0327f Merge branch 'cassandra-3.0' into cassandra-3.11 add ace3920239 Merge branch 'cassandra-3.11' into cassandra-4.0 add 97f9ff7da3 Merge branch 'cassandra-4.0' into cassandra-4.1 new b171b4ba29 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/schema/MigrationCoordinator.java | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) - 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 b171b4ba294126e985d0ee629744516f19c8644e Merge: 227409d920 97f9ff7da3 Author: Stefan Miklosovic AuthorDate: Tue Dec 20 10:17:54 2022 +0100 Merge branch 'cassandra-4.1' into trunk CHANGES.txt| 1 + src/java/org/apache/cassandra/schema/MigrationCoordinator.java | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --cc CHANGES.txt index 11de4309e8,16ed8a33c2..ec620e06db --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -165,12 -96,6 +165,13 @@@ Merged from 3.11 * Creating of a keyspace on insufficient number of replicas should filter out gosspping-only members (CASSANDRA-17759) * Suppress CVE-2022-25857 and other snakeyaml CVEs (CASSANDRA-17907) Merged from 3.0: ++ * Do not spam the logs with MigrationCoordinator not being able to pull schemas (CASSANDRA-18096) + * Fix incorrect resource name in LIST PERMISSION output (CASSANDRA-17848) + * Suppress CVE-2022-41854 and similar (CASSANDRA-18083) + * Fix running Ant rat targets without git (CASSANDRA-17974) + * Harden JMX by resolving beanshooter issues (CASSANDRA-17921) + * Suppress CVE-2019-2684 (CASSANDRA-17965) + * Fix auto-completing "WITH" when creating a materialized view (CASSANDRA-17879) * Improve libjemalloc resolution in bin/cassandra (CASSANDRA-15767) * Fix restarting of services on gossipping-only member (CASSANDRA-17752) * Fix scrubber falling into infinite loop when the last partition is broken (CASSANDRA-17862) diff --cc src/java/org/apache/cassandra/schema/MigrationCoordinator.java index fb592010c6,61ef4c8cde..a1af1c0445 --- a/src/java/org/apache/cassandra/schema/MigrationCoordinator.java +++ b/src/java/org/apache/cassandra/schema/MigrationCoordinator.java @@@ -67,6 -68,6 +67,7 @@@ import org.apache.cassandra.net.Request import org.apache.cassandra.net.Verb; import org.apache.cassandra.service.StorageService; import org.apache.cassandra.utils.FBUtilities; ++import org.apache.cassandra.utils.NoSpamLogger; import org.apache.cassandra.utils.Pair; import org.apache.cassandra.utils.Simulate; import org.apache.cassandra.utils.concurrent.Future; - 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 (eb91e2c354 -> baa9d0327f)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git from eb91e2c354 Merge branch 'cassandra-3.0' into cassandra-3.11 add f55b2fb1b3 Do not spam the logs with MigrationCoordinator not being able to pull schemas add baa9d0327f Merge branch 'cassandra-3.0' into cassandra-3.11 No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + src/java/org/apache/cassandra/service/MigrationCoordinator.java | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) - 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 (f869a2bb59 -> 97f9ff7da3)
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 f869a2bb59 Merge branch 'cassandra-4.0' into cassandra-4.1 add f55b2fb1b3 Do not spam the logs with MigrationCoordinator not being able to pull schemas add baa9d0327f Merge branch 'cassandra-3.0' into cassandra-3.11 add ace3920239 Merge branch 'cassandra-3.11' into cassandra-4.0 add 97f9ff7da3 Merge branch 'cassandra-4.0' into cassandra-4.1 No new revisions were added by this update. Summary of changes: CHANGES.txt| 2 +- src/java/org/apache/cassandra/schema/MigrationCoordinator.java | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) - 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 (473656c1d5 -> f55b2fb1b3)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from 473656c1d5 Fix incorrect resource name in LIST PERMISSION output add f55b2fb1b3 Do not spam the logs with MigrationCoordinator not being able to pull schemas No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + src/java/org/apache/cassandra/service/MigrationCoordinator.java | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
