[jira] [Commented] (CASSANDRA-16073) cql_tracing_test.py failing repeatedly on jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-16073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184961#comment-17184961 ] Berenguer Blasi commented on CASSANDRA-16073: - [~blerer] did you fire another CI run in the end? I am curious to see the results... > cql_tracing_test.py failing repeatedly on jenkins > - > > Key: CASSANDRA-16073 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16073 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 20m > Remaining Estimate: 0h > > Jenkins has been failing tracing tests repeatedly -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15988) Add nodetool getfullquerylog
[ https://issues.apache.org/jira/browse/CASSANDRA-15988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-15988: -- Test and Documentation Plan: The code is tested via standard unit tests. Status: Patch Available (was: Open) https://github.com/apache/cassandra/pull/721 > Add nodetool getfullquerylog > - > > Key: CASSANDRA-15988 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15988 > Project: Cassandra > Issue Type: Improvement > Components: Tool/fql >Reporter: Ekaterina Dimitrova >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-rc > > > This ticket is raised based on CASSANDRA-15791 and valuable feedback provided > by [~jshook]. > There are two outstanding questions: > * forming the exact shape of such a command and how it can benefit the > users; to be discussed in detail in this ticket > * Is this a thing we as a project can add to 4.0 beta or it should be > considered in 4.1 for example > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16064) Add test which validates that Message serializedSize(version) == serialize(out, version).length
[ https://issues.apache.org/jira/browse/CASSANDRA-16064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184815#comment-17184815 ] Caleb Rackliffe commented on CASSANDRA-16064: - Ouch. Sorry. > Add test which validates that Message serializedSize(version) == > serialize(out, version).length > --- > > Key: CASSANDRA-16064 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16064 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-beta > > > In 4.0 we require serializedSize(version) == serialize(out, version).length > for correctness in post40 message format as we write it into the message > header. Given that this is a strong requirement for correct deserialization > of the message, we should have tests which help enforce this property. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated: add default wipe action to circle pip3
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-3.0 by this push: new 035dc65 add default wipe action to circle pip3 035dc65 is described below commit 035dc65716865b7314357aa9e2f168e71a815ebb Author: Brandon Williams AuthorDate: Tue Aug 25 18:48:46 2020 -0500 add default wipe action to circle pip3 --- .circleci/config.yml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/.circleci/config.yml b/.circleci/config.yml index f8526be..1fb2fcb 100644 --- a/.circleci/config.yml +++ b/.circleci/config.yml @@ -196,7 +196,7 @@ jobs: # rebuild the docker image! (it automatically pulls the latest requirements.txt on build) source ~/env/bin/activate export PATH=$JAVA_HOME/bin:$PATH - pip3 install --upgrade -r ~/cassandra-dtest/requirements.txt + pip3 install --exists-action w --upgrade -r ~/cassandra-dtest/requirements.txt pip3 freeze - run: name: Determine Tests to Run (j8_without_vnodes) @@ -254,7 +254,7 @@ jobs: # rebuild the docker image! (it automatically pulls the latest requirements.txt on build) source ~/env/bin/activate export PATH=$JAVA_HOME/bin:$PATH - pip3 install --upgrade -r ~/cassandra-dtest/requirements.txt + pip3 install --exists-action w --upgrade -r ~/cassandra-dtest/requirements.txt pip3 freeze - run: name: Determine Tests to Run (j8_upgradetests_without_vnodes) @@ -445,7 +445,7 @@ jobs: # rebuild the docker image! (it automatically pulls the latest requirements.txt on build) source ~/env/bin/activate export PATH=$JAVA_HOME/bin:$PATH - pip3 install --upgrade -r ~/cassandra-dtest/requirements.txt + pip3 install --exists-action w --upgrade -r ~/cassandra-dtest/requirements.txt pip3 freeze - run: name: Determine Tests to Run (j8_with_vnodes) - 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 (116e9c1 -> 97cb2ba)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 116e9c1 Correctly interpret SASI's `max_compaction_flush_memory_in_mb` setting in megabytes not bytes new 035dc65 add default wipe action to circle pip3 new 97cb2ba Merge branch 'cassandra-3.0' into cassandra-3.11 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .circleci/config.yml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (c343175 -> 3375e14)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from c343175 Add addition incremental repair visibility to nodetool repair_admin new 035dc65 add default wipe action to circle pip3 new 97cb2ba Merge branch 'cassandra-3.0' into cassandra-3.11 new 3375e14 Merge branch 'cassandra-3.11' into trunk The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 97cb2ba7a365b03f48115fea9ae17e77d5598217 Merge: 116e9c1 035dc65 Author: Brandon Williams AuthorDate: Tue Aug 25 18:49:07 2020 -0500 Merge branch 'cassandra-3.0' into cassandra-3.11 .circleci/config.yml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 3375e148c5036e03ab6448505c28f8c19850358d Merge: c343175 97cb2ba Author: Brandon Williams AuthorDate: Tue Aug 25 18:49:34 2020 -0500 Merge branch 'cassandra-3.11' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16064) Add test which validates that Message serializedSize(version) == serialize(out, version).length
[ https://issues.apache.org/jira/browse/CASSANDRA-16064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184782#comment-17184782 ] Brandon Williams commented on CASSANDRA-16064: -- David can commit, heh. > Add test which validates that Message serializedSize(version) == > serialize(out, version).length > --- > > Key: CASSANDRA-16064 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16064 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-beta > > > In 4.0 we require serializedSize(version) == serialize(out, version).length > for correctness in post40 message format as we write it into the message > header. Given that this is a strong requirement for correct deserialization > of the message, we should have tests which help enforce this property. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16064) Add test which validates that Message serializedSize(version) == serialize(out, version).length
[ https://issues.apache.org/jira/browse/CASSANDRA-16064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184779#comment-17184779 ] Caleb Rackliffe commented on CASSANDRA-16064: - Do we have a committer lined up? Perhaps [~aleksey], given the minor involvement? > Add test which validates that Message serializedSize(version) == > serialize(out, version).length > --- > > Key: CASSANDRA-16064 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16064 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-beta > > > In 4.0 we require serializedSize(version) == serialize(out, version).length > for correctness in post40 message format as we write it into the message > header. Given that this is a strong requirement for correct deserialization > of the message, we should have tests which help enforce this property. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14939) fix some operational holes in incremental repair
[ https://issues.apache.org/jira/browse/CASSANDRA-14939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Eggleston updated CASSANDRA-14939: Since Version: 4.0-alpha1 Source Control Link: https://github.com/apache/cassandra/commit/c34317526fc6dbe559beb36cf44e24278656bdf2 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed to trunk as [c34317526fc6dbe559beb36cf44e24278656bdf2 |https://github.com/apache/cassandra/commit/c34317526fc6dbe559beb36cf44e24278656bdf2], thanks! > fix some operational holes in incremental repair > > > Key: CASSANDRA-14939 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14939 > Project: Cassandra > Issue Type: Bug >Reporter: Blake Eggleston >Assignee: Blake Eggleston >Priority: Normal > Fix For: 4.0 > > > Incremental repair has a few operational rough spots that make it more > difficult to fully automate and operate at scale than it should be. > * Visibility into whether pending repair data exists for a given token range. > * Ability to force promotion/demotion of data for completed sessions instead > of waiting for compaction. > * Get the most recent repairedAt timestamp for a given token range. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Add addition incremental repair visibility to nodetool repair_admin
This is an automated email from the ASF dual-hosted git repository.
bdeggleston pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new c343175 Add addition incremental repair visibility to nodetool
repair_admin
c343175 is described below
commit c34317526fc6dbe559beb36cf44e24278656bdf2
Author: Blake Eggleston
AuthorDate: Tue Aug 4 16:38:33 2020 -0700
Add addition incremental repair visibility to nodetool repair_admin
Patch by Blake Eggleston; Reviewed by Marcus Eriksson for CASSANDRA-14939
---
CHANGES.txt| 1 +
.../org/apache/cassandra/db/ColumnFamilyStore.java | 48 +++
.../db/compaction/CompactionStrategyManager.java | 25 ++
.../db/compaction/PendingRepairManager.java| 70 -
src/java/org/apache/cassandra/dht/Range.java | 17 ++
.../repair/consistent/ConsistentSession.java | 5 +
.../cassandra/repair/consistent/LocalSession.java | 6 +-
.../cassandra/repair/consistent/LocalSessions.java | 145 -
.../cassandra/repair/consistent/RepairedState.java | 339 +
.../repair/consistent/admin/CleanupSummary.java| 143 +
.../repair/consistent/admin/PendingStat.java | 143 +
.../repair/consistent/admin/PendingStats.java | 104 +++
.../repair/consistent/admin/RepairStats.java | 187
.../repair/consistent/admin/SchemaArgsParser.java | 117 +++
.../cassandra/repair/messages/RepairOption.java| 48 +--
.../cassandra/service/ActiveRepairService.java | 81 -
.../service/ActiveRepairServiceMBean.java | 7 +-
src/java/org/apache/cassandra/tools/NodeTool.java | 10 +-
.../cassandra/tools/nodetool/RepairAdmin.java | 322 ++-
test/unit/org/apache/cassandra/dht/RangeTest.java | 17 ++
.../cassandra/repair/AbstractRepairTest.java | 5 +
.../repair/consistent/LocalSessionTest.java| 22 +-
.../repair/consistent/PendingRepairStatTest.java | 184 +++
.../repair/consistent/RepairStateTest.java | 168 ++
.../consistent/admin/SchemaArgsParserTest.java | 91 ++
25 files changed, 2198 insertions(+), 107 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index b8ace5b..123efdf 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-beta2
+ * Add addition incremental repair visibility to nodetool repair_admin
(CASSANDRA-14939)
* Always access system properties and environment variables via the new
CassandraRelevantProperties and CassandraRelevantEnv classes (CASSANDRA-15876)
* Remove deprecated HintedHandOffManager (CASSANDRA-15939)
* Prevent repair from overrunning compaction (CASSANDRA-15817)
diff --git a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
index 77a8cdd..824005b 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
@@ -75,6 +75,8 @@ import org.apache.cassandra.metrics.Sampler.Sample;
import org.apache.cassandra.metrics.Sampler.SamplerType;
import org.apache.cassandra.metrics.TableMetrics;
import org.apache.cassandra.repair.TableRepairManager;
+import org.apache.cassandra.repair.consistent.admin.CleanupSummary;
+import org.apache.cassandra.repair.consistent.admin.PendingStat;
import org.apache.cassandra.schema.*;
import org.apache.cassandra.schema.CompactionParams.TombstoneOption;
import org.apache.cassandra.service.CacheService;
@@ -1555,6 +1557,52 @@ public class ColumnFamilyStore implements
ColumnFamilyStoreMBean
return data.getUncompacting();
}
+public Map getPendingRepairStats()
+{
+Map builders = new HashMap<>();
+for (SSTableReader sstable : getLiveSSTables())
+{
+UUID session = sstable.getPendingRepair();
+if (session == null)
+continue;
+
+if (!builders.containsKey(session))
+builders.put(session, new PendingStat.Builder());
+
+builders.get(session).addSSTable(sstable);
+}
+
+Map stats = new HashMap<>();
+for (Map.Entry entry : builders.entrySet())
+{
+stats.put(entry.getKey(), entry.getValue().build());
+}
+return stats;
+}
+
+/**
+ * promotes (or demotes) data attached to an incremental repair session
that has either completed successfully,
+ * or failed
+ *
+ * @return session ids whose data could not be released
+ */
+public CleanupSummary releaseRepairData(Collection sessions, boolean
force)
+{
+if (force)
+{
+Predicate predicate = sst -> {
+UUID session = sst.getPendingRepair();
+return session != null && sessions.contains(session);
+};
+return
[jira] [Commented] (CASSANDRA-15861) Mutating sstable component may race with entire-sstable-streaming(ZCS) causing checksum validation failure
[
https://issues.apache.org/jira/browse/CASSANDRA-15861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184714#comment-17184714
]
Blake Eggleston commented on CASSANDRA-15861:
-
[~jasonstack] it looks like the original commits and some of the review fixes
have been squashed together. Can you un-squash them? Squashing like that makes
it much more difficult to review incrementally.
> Mutating sstable component may race with entire-sstable-streaming(ZCS)
> causing checksum validation failure
> --
>
> Key: CASSANDRA-15861
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15861
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair, Consistency/Streaming,
> Local/Compaction
>Reporter: ZhaoYang
>Assignee: ZhaoYang
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Flaky dtest: [test_dead_sync_initiator -
> repair_tests.repair_test.TestRepair|https://ci-cassandra.apache.org/view/all/job/Cassandra-devbranch-dtest/143/testReport/junit/dtest.repair_tests.repair_test/TestRepair/test_dead_sync_initiator/]
> {code:java|title=stacktrace}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [Stream-Deserializer-127.0.0.1:7000-570871f3] 2020-06-03 04:05:19,081
> CassandraEntireSSTableStreamReader.java:145 - [Stream
> 6f1c3360-a54f-11ea-a808-2f23710fdc90] Error while reading sstable from stream
> for table = keyspace1.standard1
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-te4ty0r9/test/node3/data0/keyspace1/standard1-5f5ab140a54f11eaa8082f23710fdc90/na-2-big-Statistics.db
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.maybeValidateChecksum(MetadataSerializer.java:219)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:198)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:129)
> at
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.mutate(MetadataSerializer.java:226)
> at
> org.apache.cassandra.db.streaming.CassandraEntireSSTableStreamReader.read(CassandraEntireSSTableStreamReader.java:140)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.read(CassandraIncomingFile.java:78)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:49)
> at
> org.apache.cassandra.streaming.messages.IncomingStreamMessage$1.deserialize(IncomingStreamMessage.java:36)
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:49)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:181)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: Checksums do not match for
> /home/cassandra/cassandra/cassandra-dtest/tmp/dtest-te4ty0r9/test/node3/data0/keyspace1/standard1-5f5ab140a54f11eaa8082f23710fdc90/na-2-big-Statistics.db
> {code}
>
> In the above test, it executes "nodetool repair" on node1 and kills node2
> during repair. At the end, node3 reports checksum validation failure on
> sstable transferred from node1.
> {code:java|title=what happened}
> 1. When repair started on node1, it performs anti-compaction which modifies
> sstable's repairAt to 0 and pending repair id to session-id.
> 2. Then node1 creates {{ComponentManifest}} which contains file lengths to be
> transferred to node3.
> 3. Before node1 actually sends the files to node3, node2 is killed and node1
> starts to broadcast repair-failure-message to all participants in
> {{CoordinatorSession#fail}}
> 4. Node1 receives its own repair-failure-message and fails its local repair
> sessions at {{LocalSessions#failSession}} which triggers async background
> compaction.
> 5. Node1's background compaction will mutate sstable's repairAt to 0 and
> pending repair id to null via
> {{PendingRepairManager#getNextRepairFinishedTask}}, as there is no more
> in-progress repair.
> 6. Node1 actually sends the sstable to node3 where the sstable's STATS
> component size is different from the original size recorded in the manifest.
> 7. At the end, node3 reports checksum validation failure when it tries to
> mutate sstable level and "isTransient" attribute in
> {{CassandraEntireSSTableStreamReader#read}}.
> {code}
> Currently, entire-sstable-streaming requires sstable components to be
> immutable, because \{{ComponentManifest}}
> with component sizes a
[jira] [Updated] (CASSANDRA-16071) max_compaction_flush_memory_in_mb is interpreted as bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-16071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16071:
---
Fix Version/s: 4.0
> max_compaction_flush_memory_in_mb is interpreted as bytes
> -
>
> Key: CASSANDRA-16071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16071
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0, 3.11.8, 4.0-beta2
>
>
> In CASSANDRA-12662, [~scottcarey]
> [reported|https://issues.apache.org/jira/browse/CASSANDRA-12662?focusedCommentId=17070055&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17070055]
> that the {{max_compaction_flush_memory_in_mb}} setting gets incorrectly
> interpreted in bytes rather than megabytes as its name implies.
> {quote}
> 1. the setting 'max_compaction_flush_memory_in_mb' is a misnomer, it is
> actually memory in BYTES. If you take it at face value, and set it to say,
> '512' thinking that means 512MB, you will produce a million temp files
> rather quickly in a large compaction, which will exhaust even large values of
> max_map_count rapidly, and get the OOM: Map Error issue above and possibly
> have a very difficult situation to get a cluster back into a place where
> nodes aren't crashing while initilaizing or soon after. This issue is minor
> if you know about it in advance and set the value IN BYTES.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15937) JMX output inconsistencies from CASSANDRA-7544 storage-port-configurable-per-node
[
https://issues.apache.org/jira/browse/CASSANDRA-15937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184693#comment-17184693
]
David Capwell commented on CASSANDRA-15937:
---
Great,
https://app.circleci.com/pipelines/github/dcapwell/cassandra/433/workflows/f52b094c-61a8-4465-a03d-d997d590c2e8
is green again...
Going to test the dtest changes on older branches...
> JMX output inconsistencies from CASSANDRA-7544
> storage-port-configurable-per-node
> -
>
> Key: CASSANDRA-15937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15937
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> CASSANDRA-7544 introduced changes to allow the storage port number to be
> configured per-node. As part of that work it introduces new MBeans for
> MessagingService, FailureDetector providing new 'WithPort' versions that
> include the new port information, however there are some mistakes and
> inconsistencies.
> {code:java}
> 3.11.6 trunk trunk
> w/Port Notes
>
> AllEndpointStates /127.0.0.1\n... /127.0.0.3\n...
> 127.0.0.3:7000\n (trunk /w port different)
> SimpleStates /127.0.0.2=UP /127.0.0.2=UP
> 127.0.0.3:7000=UP (trunk /w port different)
> LargeMessagePendingTasks /127.0.0.1=0 /127.0.0.1=0
> 127.0.0.3:7000=0 (trunk /w port different)
> TimeoutsPerHost 127.0.0.1=0 /127.0.0.1=0
> 127.0.0.3:7000=0 3.0/3.11.6 & trunk differ.
> BackPressurePerHost 127.0.0.1=Infinity /127.0.0.2=Infinity
> /127.0.0.2=Infinity 3.11 & trunk differ, missing port number for
> BackPressurePerHostWithPort
> SchemaVersions {...=[127.0.0.1,...]} {...=[127.0.0.1,...]}
> {...=[127.0.0.1:7000,...]
>
> TokenToEndpointMap {-92...8=127.0.0.1, -92...8=127.0.0.1
> -92..8=127.0.0.1:7000
> HostIdMap 127.0.0.1=1ee..6f0af 127.0.0.1=e06...7e MISSING
> Deprecated for EndpointToHostId
> EndpointToHostId 127.0.0.1=1ee..6f0a 127.0.0.1=e06...7e
> 127.0.0.1:7000=e0..7e
> HostIdToEndpoint 1ee..6f0a=127.0.0.1 e06..7e=127.0.0.1
> e06..7e=127.0.0.1:7000
> LoadMap 127.0.0.1=185.01 KiB 127.0.0.1:7000=106.08 KiB
> 127.0.0.1=106.08 Ki LoadMap and LoadMapWithPort are flipped.
> LiveNodes 127.0.0.1 127.0.0.1
> 127.0.0.1:7000
> Ownership /127.0.0.1=0.33 /127.0.0.1=0.33
> 127.0.0.1:7000=0.33
> Scores /127.0.0.1=0.0 /127.0.0.1=0.0
> 127.0.0.1:7000=0.0
> {code}
>
> Proposed changes
>
> 1) AllEndpointStats, SimpleStates, Connection message tracking,
> TimeoutsPerHost - include the host/ip:port in the WithPort version
> 2) Add port number to BackPressurePerHostWithPort
> 3) Correct LoadMap to omit port / LoadMapWithPort to include port
> 4) Ownership - update with port to host/ip:port version
> 5) Scores - update with port to host/ip:port version
>
>
> Additionally while dumping out all of the JMX info with `sjk mxdump`
>
> 6) DynamicEndpointSnitch.getScoresWithPort now returns an InetAddressAndPort
> which should just be a String
> 7) ClientMetrics.clientsByProtocolVersion returns a Guava Immutable map
> 8) StorageService.getIdealConsistencyLevel fails if none set (as we try and
> call ConsistencyLevel.toString on a null pointer).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15876) Accessors for SystemProperties
[ https://issues.apache.org/jira/browse/CASSANDRA-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15876: --- Fix Version/s: (was: 4.0-beta) 4.0-beta2 Source Control Link: https://github.com/apache/cassandra/commit/7694c1d191531ac152db55e83bc0db6864a5441e Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed as [|https://github.com/apache/cassandra/commit/7694c1d191531ac152db55e83bc0db6864a5441e] > Accessors for SystemProperties > -- > > Key: CASSANDRA-15876 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15876 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0, 4.0-beta2 > > > As part of CASSANDRA-15234, it was suggested a class of accessors for System > properties to be created for better clarity and maintainability. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Always access system properties and environment variables via the new CassandraRelevantProperties and CassandraRelevantEnv classes
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 7694c1d Always access system properties and environment variables via
the new CassandraRelevantProperties and CassandraRelevantEnv classes
7694c1d is described below
commit 7694c1d191531ac152db55e83bc0db6864a5441e
Author: Ekaterina Dimitrova
AuthorDate: Sun Mar 22 15:35:33 2020 -0400
Always access system properties and environment variables via the new
CassandraRelevantProperties and CassandraRelevantEnv classes
patch by Ekaterina Dimitrova; reviewed by David Capwell, Mick Semb Wever
for CASSANDRA-15876
---
CHANGES.txt| 1 +
.../cassandra/config/CassandraRelevantEnv.java | 44
.../config/CassandraRelevantProperties.java| 240 +
.../cassandra/config/DatabaseDescriptor.java | 8 +-
.../db/virtual/SystemPropertiesTable.java | 63 ++
.../org/apache/cassandra/gms/FailureDetector.java | 4 +-
.../cassandra/hadoop/cql3/CqlBulkRecordWriter.java | 4 +-
.../org/apache/cassandra/io/util/FileUtils.java| 3 +-
.../apache/cassandra/locator/PendingRangeMaps.java | 5 +-
.../apache/cassandra/locator/TokenMetadata.java| 18 +-
.../apache/cassandra/service/CassandraDaemon.java | 19 +-
.../apache/cassandra/service/StartupChecks.java| 11 +-
.../org/apache/cassandra/utils/Architecture.java | 4 +-
.../org/apache/cassandra/utils/FBUtilities.java| 30 +--
.../org/apache/cassandra/utils/GuidGenerator.java | 4 +-
src/java/org/apache/cassandra/utils/HeapUtils.java | 5 +-
.../org/apache/cassandra/utils/JMXServerUtils.java | 26 ++-
.../org/apache/cassandra/utils/MBeanWrapper.java | 7 +-
src/java/org/apache/cassandra/utils/Mx4jTool.java | 9 +-
.../org/apache/cassandra/utils/NativeLibrary.java | 6 +-
.../config/CassandraRelevantPropertiesTest.java| 145 +
21 files changed, 546 insertions(+), 110 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 1e2c64a..b8ace5b 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-beta2
+ * Always access system properties and environment variables via the new
CassandraRelevantProperties and CassandraRelevantEnv classes (CASSANDRA-15876)
* Remove deprecated HintedHandOffManager (CASSANDRA-15939)
* Prevent repair from overrunning compaction (CASSANDRA-15817)
* fix cqlsh COPY functions in Python 3.8 on Mac (CASSANDRA-16053)
diff --git a/src/java/org/apache/cassandra/config/CassandraRelevantEnv.java
b/src/java/org/apache/cassandra/config/CassandraRelevantEnv.java
new file mode 100644
index 000..4960374
--- /dev/null
+++ b/src/java/org/apache/cassandra/config/CassandraRelevantEnv.java
@@ -0,0 +1,44 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.cassandra.config;
+
+public enum CassandraRelevantEnv
+{
+/**
+ * Searching in the JAVA_HOME is safer than searching into
System.getProperty("java.home") as the Oracle
+ * JVM might use the JRE which do not contains jmap.
+ */
+JAVA_HOME ("JAVA_HOME");
+
+CassandraRelevantEnv(String key)
+{
+this.key = key;
+}
+
+private final String key;
+
+public String getString()
+{
+return System.getenv(key);
+}
+
+public String getKey() {
+return key;
+}
+}
diff --git
a/src/java/org/apache/cassandra/config/CassandraRelevantProperties.java
b/src/java/org/apache/cassandra/config/CassandraRelevantProperties.java
new file mode 100644
index 000..881b7d9
--- /dev/null
+++ b/src/java/org/apache/cassandra/config/CassandraRelevantProperties.java
@@ -0,0 +1,240 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License
[jira] [Updated] (CASSANDRA-15876) Accessors for SystemProperties
[ https://issues.apache.org/jira/browse/CASSANDRA-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15876: --- Status: Ready to Commit (was: Review In Progress) > Accessors for SystemProperties > -- > > Key: CASSANDRA-15876 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15876 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0, 4.0-beta > > > As part of CASSANDRA-15234, it was suggested a class of accessors for System > properties to be created for better clarity and maintainability. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15876) Accessors for SystemProperties
[ https://issues.apache.org/jira/browse/CASSANDRA-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184664#comment-17184664 ] Michael Semb Wever commented on CASSANDRA-15876: +1 > Accessors for SystemProperties > -- > > Key: CASSANDRA-15876 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15876 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0, 4.0-beta > > > As part of CASSANDRA-15234, it was suggested a class of accessors for System > properties to be created for better clarity and maintainability. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15876) Accessors for SystemProperties
[ https://issues.apache.org/jira/browse/CASSANDRA-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184663#comment-17184663 ] Ekaterina Dimitrova commented on CASSANDRA-15876: - Everything squashed [here | https://github.com/ekaterinadimitrova2/cassandra/commit/96b3da53640412f571b1615cdd7127ccdfd1c925] The unit tests were cherry-picked and passing. > Accessors for SystemProperties > -- > > Key: CASSANDRA-15876 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15876 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0, 4.0-beta > > > As part of CASSANDRA-15234, it was suggested a class of accessors for System > properties to be created for better clarity and maintainability. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16071) max_compaction_flush_memory_in_mb is interpreted as bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-16071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16071:
---
Fix Version/s: (was: 4.0-beta)
(was: 3.11.x)
4.0-beta2
3.11.8
> max_compaction_flush_memory_in_mb is interpreted as bytes
> -
>
> Key: CASSANDRA-16071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16071
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.11.8, 4.0-beta2
>
>
> In CASSANDRA-12662, [~scottcarey]
> [reported|https://issues.apache.org/jira/browse/CASSANDRA-12662?focusedCommentId=17070055&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17070055]
> that the {{max_compaction_flush_memory_in_mb}} setting gets incorrectly
> interpreted in bytes rather than megabytes as its name implies.
> {quote}
> 1. the setting 'max_compaction_flush_memory_in_mb' is a misnomer, it is
> actually memory in BYTES. If you take it at face value, and set it to say,
> '512' thinking that means 512MB, you will produce a million temp files
> rather quickly in a large compaction, which will exhaust even large values of
> max_map_count rapidly, and get the OOM: Map Error issue above and possibly
> have a very difficult situation to get a cluster back into a place where
> nodes aren't crashing while initilaizing or soon after. This issue is minor
> if you know about it in advance and set the value IN BYTES.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16071) max_compaction_flush_memory_in_mb is interpreted as bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-16071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16071:
---
Reviewers: ZhaoYang (was: Michael Semb Wever, ZhaoYang)
> max_compaction_flush_memory_in_mb is interpreted as bytes
> -
>
> Key: CASSANDRA-16071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16071
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.11.8, 4.0-beta2
>
>
> In CASSANDRA-12662, [~scottcarey]
> [reported|https://issues.apache.org/jira/browse/CASSANDRA-12662?focusedCommentId=17070055&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17070055]
> that the {{max_compaction_flush_memory_in_mb}} setting gets incorrectly
> interpreted in bytes rather than megabytes as its name implies.
> {quote}
> 1. the setting 'max_compaction_flush_memory_in_mb' is a misnomer, it is
> actually memory in BYTES. If you take it at face value, and set it to say,
> '512' thinking that means 512MB, you will produce a million temp files
> rather quickly in a large compaction, which will exhaust even large values of
> max_map_count rapidly, and get the OOM: Map Error issue above and possibly
> have a very difficult situation to get a cluster back into a place where
> nodes aren't crashing while initilaizing or soon after. This issue is minor
> if you know about it in advance and set the value IN BYTES.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16071) max_compaction_flush_memory_in_mb is interpreted as bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-16071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16071:
---
Since Version: 3.4
Source Control Link:
https://github.com/apache/cassandra/commit/116e9c1678a1e96748236962e71319f337e07f8d
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[116e9c1678a1e96748236962e71319f337e07f8d|https://github.com/apache/cassandra/commit/116e9c1678a1e96748236962e71319f337e07f8d].
> max_compaction_flush_memory_in_mb is interpreted as bytes
> -
>
> Key: CASSANDRA-16071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16071
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.11.x, 4.0-beta
>
>
> In CASSANDRA-12662, [~scottcarey]
> [reported|https://issues.apache.org/jira/browse/CASSANDRA-12662?focusedCommentId=17070055&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17070055]
> that the {{max_compaction_flush_memory_in_mb}} setting gets incorrectly
> interpreted in bytes rather than megabytes as its name implies.
> {quote}
> 1. the setting 'max_compaction_flush_memory_in_mb' is a misnomer, it is
> actually memory in BYTES. If you take it at face value, and set it to say,
> '512' thinking that means 512MB, you will produce a million temp files
> rather quickly in a large compaction, which will exhaust even large values of
> max_map_count rapidly, and get the OOM: Map Error issue above and possibly
> have a very difficult situation to get a cluster back into a place where
> nodes aren't crashing while initilaizing or soon after. This issue is minor
> if you know about it in advance and set the value IN BYTES.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 43e33247351aeefd508965c951a3258fae1736e4
Merge: a497d43 116e9c1
Author: Mick Semb Wever
AuthorDate: Tue Aug 25 20:08:54 2020 +0200
Merge branch 'cassandra-3.11' into trunk
CHANGES.txt| 1 +
.../cassandra/index/sasi/conf/IndexMode.java | 12 +-
.../index/sasi/disk/PerSSTableIndexWriter.java | 2 +-
.../cassandra/index/sasi/conf/IndexModeTest.java | 222 +
4 files changed, 230 insertions(+), 7 deletions(-)
diff --cc CHANGES.txt
index a36c910,1ba44f5..1e2c64a
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,24 -1,6 +1,25 @@@
-3.11.8
+4.0-beta2
+ * Remove deprecated HintedHandOffManager (CASSANDRA-15939)
+ * Prevent repair from overrunning compaction (CASSANDRA-15817)
+ * fix cqlsh COPY functions in Python 3.8 on Mac (CASSANDRA-16053)
+ * Strip comment blocks from cqlsh input before processing statements
(CASSANDRA-15802)
+ * Fix unicode chars error input (CASSANDRA-15990)
+ * Improved testability for CacheMetrics and ChunkCacheMetrics
(CASSANDRA-15788)
+ * Handle errors in StreamSession#prepare (CASSANDRA-15852)
+ * FQL replay should have options to ignore DDL statements (CASSANDRA-16039)
+ * Remove COMPACT STORAGE internals (CASSANDRA-13994)
+ * Make TimestampSerializer accept fractional seconds of varying precision
(CASSANDRA-15976)
+ * Improve cassandra-stress logging when using a profile file that doesn't
exist (CASSANDRA-14425)
+ * Improve logging for socket connection/disconnection (CASSANDRA-15980)
+ * Throw FSWriteError upon write failures in order to apply DiskFailurePolicy
(CASSANDRA-15928)
+ * Forbid altering UDTs used in partition keys (CASSANDRA-15933)
+ * Fix version parsing logic when upgrading from 3.0 (CASSANDRA-15973)
+ * Optimize NoSpamLogger use in hot paths (CASSANDRA-15766)
+ * Verify sstable components on startup (CASSANDRA-15945)
+Merged from 3.11:
+ * Correctly interpret SASI's `max_compaction_flush_memory_in_mb` setting in
megabytes not bytes (CASSANDRA-16071)
* Fix short read protection for GROUP BY queries (CASSANDRA-15459)
+ * stop_paranoid disk failure policy is ignored on CorruptSSTableException
after node is up (CASSANDRA-15191)
* Frozen RawTuple is not annotated with frozen in the toString method
(CASSANDRA-15857)
Merged from 3.0:
* Fix gossip shutdown order (CASSANDRA-15816)
diff --cc test/unit/org/apache/cassandra/index/sasi/conf/IndexModeTest.java
index 000,9f93f27..1cea469
mode 00,100644..100644
--- a/test/unit/org/apache/cassandra/index/sasi/conf/IndexModeTest.java
+++ b/test/unit/org/apache/cassandra/index/sasi/conf/IndexModeTest.java
@@@ -1,0 -1,222 +1,222 @@@
+ /*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+ package org.apache.cassandra.index.sasi.conf;
+
+ import java.util.Collections;
+ import java.util.Map;
+
+ import com.google.common.collect.ImmutableMap;
+ import org.junit.Assert;
+ import org.junit.BeforeClass;
+ import org.junit.Test;
+
-import org.apache.cassandra.config.CFMetaData;
-import org.apache.cassandra.config.ColumnDefinition;
+ import org.apache.cassandra.config.DatabaseDescriptor;
+ import org.apache.cassandra.db.marshal.AsciiType;
+ import org.apache.cassandra.db.marshal.BytesType;
+ import org.apache.cassandra.db.marshal.UTF8Type;
+ import org.apache.cassandra.exceptions.ConfigurationException;
+ import org.apache.cassandra.index.sasi.disk.OnDiskIndexBuilder.Mode;
++import org.apache.cassandra.schema.ColumnMetadata;
++import org.apache.cassandra.schema.TableMetadata;
+ import org.apache.cassandra.utils.ByteBufferUtil;
+
+
+ public class IndexModeTest
+ {
+
-private final CFMetaData cfm = CFMetaData.Builder.create("ks", "cf")
-.addPartitionKey("pkey", AsciiType.instance)
++private final TableMetadata cfm = TableMetadata.builder("ks", "cf")
++.addPartitionKeyColumn("pkey", AsciiType.instance)
+ .build();
+
+ @BeforeClass
+ public static void setupDD()
+ {
+ Databa
[cassandra] branch cassandra-3.11 updated: Correctly interpret SASI's `max_compaction_flush_memory_in_mb` setting in megabytes not bytes
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.11 by this push:
new 116e9c1 Correctly interpret SASI's
`max_compaction_flush_memory_in_mb` setting in megabytes not bytes
116e9c1 is described below
commit 116e9c1678a1e96748236962e71319f337e07f8d
Author: Mick Semb Wever
AuthorDate: Sat Aug 22 15:15:19 2020 +0200
Correctly interpret SASI's `max_compaction_flush_memory_in_mb` setting in
megabytes not bytes
patch by Mick Semb Wever; reviewed by Zhao Yang for CASSANDRA-16071
---
CHANGES.txt| 1 +
.../cassandra/index/sasi/conf/IndexMode.java | 12 +-
.../index/sasi/disk/PerSSTableIndexWriter.java | 2 +-
.../cassandra/index/sasi/conf/IndexModeTest.java | 222 +
4 files changed, 230 insertions(+), 7 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 714b104..1ba44f5 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.11.8
+ * Correctly interpret SASI's `max_compaction_flush_memory_in_mb` setting in
megabytes not bytes (CASSANDRA-16071)
* Fix short read protection for GROUP BY queries (CASSANDRA-15459)
* Frozen RawTuple is not annotated with frozen in the toString method
(CASSANDRA-15857)
Merged from 3.0:
diff --git a/src/java/org/apache/cassandra/index/sasi/conf/IndexMode.java
b/src/java/org/apache/cassandra/index/sasi/conf/IndexMode.java
index 5709a0f..8d76bb0 100644
--- a/src/java/org/apache/cassandra/index/sasi/conf/IndexMode.java
+++ b/src/java/org/apache/cassandra/index/sasi/conf/IndexMode.java
@@ -60,15 +60,15 @@ public class IndexMode
public final Mode mode;
public final boolean isAnalyzed, isLiteral;
public final Class analyzerClass;
-public final long maxCompactionFlushMemoryInMb;
+public final long maxCompactionFlushMemoryInBytes;
-private IndexMode(Mode mode, boolean isLiteral, boolean isAnalyzed, Class
analyzerClass, long maxFlushMemMb)
+private IndexMode(Mode mode, boolean isLiteral, boolean isAnalyzed, Class
analyzerClass, long maxMemBytes)
{
this.mode = mode;
this.isLiteral = isLiteral;
this.isAnalyzed = isAnalyzed;
this.analyzerClass = analyzerClass;
-this.maxCompactionFlushMemoryInMb = maxFlushMemMb;
+this.maxCompactionFlushMemoryInBytes = maxMemBytes;
}
public AbstractAnalyzer getAnalyzer(AbstractType validator)
@@ -186,11 +186,11 @@ public class IndexMode
logger.error("failed to parse {} option, defaulting to 'false'.",
INDEX_IS_LITERAL_OPTION);
}
-Long maxMemMb = indexOptions.get(INDEX_MAX_FLUSH_MEMORY_OPTION) == null
+long maxMemBytes = indexOptions.get(INDEX_MAX_FLUSH_MEMORY_OPTION) ==
null
? (long) (1073741824 * INDEX_MAX_FLUSH_DEFAULT_MULTIPLIER) //
1G default for memtable
-:
Long.parseLong(indexOptions.get(INDEX_MAX_FLUSH_MEMORY_OPTION));
+: 1048576L *
Long.parseLong(indexOptions.get(INDEX_MAX_FLUSH_MEMORY_OPTION));
-return new IndexMode(mode, isLiteral, isAnalyzed, analyzerClass,
maxMemMb);
+return new IndexMode(mode, isLiteral, isAnalyzed, analyzerClass,
maxMemBytes);
}
public boolean supports(Op operator)
diff --git
a/src/java/org/apache/cassandra/index/sasi/disk/PerSSTableIndexWriter.java
b/src/java/org/apache/cassandra/index/sasi/disk/PerSSTableIndexWriter.java
index d5ecaf7..527deab 100644
--- a/src/java/org/apache/cassandra/index/sasi/disk/PerSSTableIndexWriter.java
+++ b/src/java/org/apache/cassandra/index/sasi/disk/PerSSTableIndexWriter.java
@@ -360,7 +360,7 @@ public class PerSSTableIndexWriter implements
SSTableFlushObserver
protected long maxMemorySize(ColumnIndex columnIndex)
{
// 1G for memtable and configuration for compaction
-return source == OperationType.FLUSH ? 1073741824L :
columnIndex.getMode().maxCompactionFlushMemoryInMb;
+return source == OperationType.FLUSH ? 1073741824L :
columnIndex.getMode().maxCompactionFlushMemoryInBytes;
}
public int hashCode()
diff --git a/test/unit/org/apache/cassandra/index/sasi/conf/IndexModeTest.java
b/test/unit/org/apache/cassandra/index/sasi/conf/IndexModeTest.java
new file mode 100644
index 000..9f93f27
--- /dev/null
+++ b/test/unit/org/apache/cassandra/index/sasi/conf/IndexModeTest.java
@@ -0,0 +1,222 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+
[cassandra] branch trunk updated (a497d43 -> 43e3324)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from a497d43 Remove deprecated HintedHandOffManager new 116e9c1 Correctly interpret SASI's `max_compaction_flush_memory_in_mb` setting in megabytes not bytes new 43e3324 Merge branch 'cassandra-3.11' into trunk The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../cassandra/index/sasi/conf/IndexMode.java | 12 +- .../index/sasi/disk/PerSSTableIndexWriter.java | 2 +- .../cassandra/index/sasi/conf/IndexModeTest.java | 222 + 4 files changed, 230 insertions(+), 7 deletions(-) create mode 100644 test/unit/org/apache/cassandra/index/sasi/conf/IndexModeTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16071) max_compaction_flush_memory_in_mb is interpreted as bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-16071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16071:
---
Reviewers: ZhaoYang, Michael Semb Wever (was: Michael Semb Wever, ZhaoYang)
ZhaoYang, Michael Semb Wever (was: ZhaoYang)
Status: Review In Progress (was: Patch Available)
> max_compaction_flush_memory_in_mb is interpreted as bytes
> -
>
> Key: CASSANDRA-16071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16071
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.11.x, 4.0-beta
>
>
> In CASSANDRA-12662, [~scottcarey]
> [reported|https://issues.apache.org/jira/browse/CASSANDRA-12662?focusedCommentId=17070055&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17070055]
> that the {{max_compaction_flush_memory_in_mb}} setting gets incorrectly
> interpreted in bytes rather than megabytes as its name implies.
> {quote}
> 1. the setting 'max_compaction_flush_memory_in_mb' is a misnomer, it is
> actually memory in BYTES. If you take it at face value, and set it to say,
> '512' thinking that means 512MB, you will produce a million temp files
> rather quickly in a large compaction, which will exhaust even large values of
> max_map_count rapidly, and get the OOM: Map Error issue above and possibly
> have a very difficult situation to get a cluster back into a place where
> nodes aren't crashing while initilaizing or soon after. This issue is minor
> if you know about it in advance and set the value IN BYTES.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16071) max_compaction_flush_memory_in_mb is interpreted as bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-16071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16071:
---
Status: Ready to Commit (was: Review In Progress)
> max_compaction_flush_memory_in_mb is interpreted as bytes
> -
>
> Key: CASSANDRA-16071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16071
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.11.x, 4.0-beta
>
>
> In CASSANDRA-12662, [~scottcarey]
> [reported|https://issues.apache.org/jira/browse/CASSANDRA-12662?focusedCommentId=17070055&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17070055]
> that the {{max_compaction_flush_memory_in_mb}} setting gets incorrectly
> interpreted in bytes rather than megabytes as its name implies.
> {quote}
> 1. the setting 'max_compaction_flush_memory_in_mb' is a misnomer, it is
> actually memory in BYTES. If you take it at face value, and set it to say,
> '512' thinking that means 512MB, you will produce a million temp files
> rather quickly in a large compaction, which will exhaust even large values of
> max_map_count rapidly, and get the OOM: Map Error issue above and possibly
> have a very difficult situation to get a cluster back into a place where
> nodes aren't crashing while initilaizing or soon after. This issue is minor
> if you know about it in advance and set the value IN BYTES.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16072) Reduce thread contention in CommitLogSegment and HintsBuffer by rewriting CAS loops to atomic adds
[
https://issues.apache.org/jira/browse/CASSANDRA-16072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184629#comment-17184629
]
Michael Semb Wever commented on CASSANDRA-16072:
Benedict is busy atm. [~blerer], all yours.
The question came up whether these should be protected from overflow.
The regions (CASSANDRA-15922) are limited to 1MB.
The CommitLogSegment is limited by {{commitlog_segment_size_in_mb < 2048}}.
And the HintsBuffer by being {{commitlog_segment_size_in_mb / 2}}.
The use of {{.getAndAdd(..)}} could still let multiple calls happen close to
{{Integer.MAX_VALUE}}. Unless these can add up to wrap-around close to zero the
{{allocate(..)}} methods will still return a negative value which is handled as
"not enough space".
For CommitLogSegment, the only one possible to be close to wrapping around,
this
[block|https://github.com/thelastpickle/cassandra/blob/e8513923de7edba9265ca50f0dbd1000539bf394/src/java/org/apache/cassandra/db/commitlog/CommitLogSegment.java#L276-L279]
is protected by the OpOrder and cas loop, and {{close()}} is synchronized (wrt
to the nullable buffer).
> Reduce thread contention in CommitLogSegment and HintsBuffer by rewriting CAS
> loops to atomic adds
> --
>
> Key: CASSANDRA-16072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16072
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Hints, Local/Commit Log
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.11.x, 4.0-beta
>
>
> Follow up to CASSANDRA-15922
> Both CommitLogSegment and HintsBuffer use AtomicIntegers for the current
> offset when allocating. Like in CASSANDRA\-15922 the loops on
> {{.compareAndSet(..)}} can be replaced with atomic adds using the {{.
> getAndAdd(..)}} method.
> In highly contended environments the CAS failures can be high, starving
> writes in a running Cassandra node. On the same cluster CASSANDRA\-15922 was
> found, after CASSANDRA\-15922's fix was deployed, there was still problems
> around commit log flushing and hints. No flamegraph was collected that
> demonstrated the thread contention as clearly as was found in
> CASSANDRA\-15922, but the performance fix proposed here hopefully is obvious
> enough.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15937) JMX output inconsistencies from CASSANDRA-7544 storage-port-configurable-per-node
[
https://issues.apache.org/jira/browse/CASSANDRA-15937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184611#comment-17184611
]
David Capwell commented on CASSANDRA-15937:
---
Thanks, working on a script to make this easier for me; launched the build here
https://app.circleci.com/pipelines/github/dcapwell/cassandra/431/workflows/2fd8cab6-5af3-4260-8acd-5239fbc56b6d
> JMX output inconsistencies from CASSANDRA-7544
> storage-port-configurable-per-node
> -
>
> Key: CASSANDRA-15937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15937
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/JMX
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> CASSANDRA-7544 introduced changes to allow the storage port number to be
> configured per-node. As part of that work it introduces new MBeans for
> MessagingService, FailureDetector providing new 'WithPort' versions that
> include the new port information, however there are some mistakes and
> inconsistencies.
> {code:java}
> 3.11.6 trunk trunk
> w/Port Notes
>
> AllEndpointStates /127.0.0.1\n... /127.0.0.3\n...
> 127.0.0.3:7000\n (trunk /w port different)
> SimpleStates /127.0.0.2=UP /127.0.0.2=UP
> 127.0.0.3:7000=UP (trunk /w port different)
> LargeMessagePendingTasks /127.0.0.1=0 /127.0.0.1=0
> 127.0.0.3:7000=0 (trunk /w port different)
> TimeoutsPerHost 127.0.0.1=0 /127.0.0.1=0
> 127.0.0.3:7000=0 3.0/3.11.6 & trunk differ.
> BackPressurePerHost 127.0.0.1=Infinity /127.0.0.2=Infinity
> /127.0.0.2=Infinity 3.11 & trunk differ, missing port number for
> BackPressurePerHostWithPort
> SchemaVersions {...=[127.0.0.1,...]} {...=[127.0.0.1,...]}
> {...=[127.0.0.1:7000,...]
>
> TokenToEndpointMap {-92...8=127.0.0.1, -92...8=127.0.0.1
> -92..8=127.0.0.1:7000
> HostIdMap 127.0.0.1=1ee..6f0af 127.0.0.1=e06...7e MISSING
> Deprecated for EndpointToHostId
> EndpointToHostId 127.0.0.1=1ee..6f0a 127.0.0.1=e06...7e
> 127.0.0.1:7000=e0..7e
> HostIdToEndpoint 1ee..6f0a=127.0.0.1 e06..7e=127.0.0.1
> e06..7e=127.0.0.1:7000
> LoadMap 127.0.0.1=185.01 KiB 127.0.0.1:7000=106.08 KiB
> 127.0.0.1=106.08 Ki LoadMap and LoadMapWithPort are flipped.
> LiveNodes 127.0.0.1 127.0.0.1
> 127.0.0.1:7000
> Ownership /127.0.0.1=0.33 /127.0.0.1=0.33
> 127.0.0.1:7000=0.33
> Scores /127.0.0.1=0.0 /127.0.0.1=0.0
> 127.0.0.1:7000=0.0
> {code}
>
> Proposed changes
>
> 1) AllEndpointStats, SimpleStates, Connection message tracking,
> TimeoutsPerHost - include the host/ip:port in the WithPort version
> 2) Add port number to BackPressurePerHostWithPort
> 3) Correct LoadMap to omit port / LoadMapWithPort to include port
> 4) Ownership - update with port to host/ip:port version
> 5) Scores - update with port to host/ip:port version
>
>
> Additionally while dumping out all of the JMX info with `sjk mxdump`
>
> 6) DynamicEndpointSnitch.getScoresWithPort now returns an InetAddressAndPort
> which should just be a String
> 7) ClientMetrics.clientsByProtocolVersion returns a Guava Immutable map
> 8) StorageService.getIdealConsistencyLevel fails if none set (as we try and
> call ConsistencyLevel.toString on a null pointer).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15939) Remove previously deprecated HintedHandoffManager
[
https://issues.apache.org/jira/browse/CASSANDRA-15939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15939:
-
Fix Version/s: (was: 4.0-beta)
4.0-beta2
Source Control Link:
https://github.com/apache/cassandra/commit/a497d43e6ba7568defe0621e90c3451ec9204e1d
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Jenkins looks good too:
https://ci-cassandra.apache.org/job/Cassandra-devbranch/270/
Thanks, committed.
> Remove previously deprecated HintedHandoffManager
> -
>
> Key: CASSANDRA-15939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15939
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Hints
>Reporter: Stephen Mallette
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta2
>
>
> {{HintedHandOffManager}} was deprecated about 6 years ago:
> https://github.com/apache/cassandra/commit/96d41f0e0e44d9b3114a5d80dedf12053d36a76b
> with the TODO to remove it for 4.0. While looking at CASSANDRA-15582 and
> examining the published JMX elements it seemed sensible to remove this MBean
> to help clean up a bit as it appears to just be a proxy to the
> {{HintService}} at this point.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Remove deprecated HintedHandOffManager
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new a497d43 Remove deprecated HintedHandOffManager
a497d43 is described below
commit a497d43e6ba7568defe0621e90c3451ec9204e1d
Author: Bereng
AuthorDate: Tue Aug 25 11:45:51 2020 +0200
Remove deprecated HintedHandOffManager
Patch by Bereguer Blasi, reviewed by brandonwilliams for CASSANDRA-15939
---
CHANGES.txt| 1 +
doc/source/operating/metrics.rst | 26 +---
.../apache/cassandra/db/HintedHandOffManager.java | 76 --
.../cassandra/db/HintedHandOffManagerMBean.java| 50 --
.../org/apache/cassandra/hints/HintsService.java | 2 +-
.../cassandra/metrics/HintedHandoffMetrics.java| 2 +-
.../org/apache/cassandra/service/StorageProxy.java | 2 -
src/java/org/apache/cassandra/tools/NodeProbe.java | 25 +++
.../mock/nodetool/InternalNodeProbe.java | 5 +-
9 files changed, 16 insertions(+), 173 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 415f699..a36c910 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0-beta2
+ * Remove deprecated HintedHandOffManager (CASSANDRA-15939)
* Prevent repair from overrunning compaction (CASSANDRA-15817)
* fix cqlsh COPY functions in Python 3.8 on Mac (CASSANDRA-16053)
* Strip comment blocks from cqlsh input before processing statements
(CASSANDRA-15802)
diff --git a/doc/source/operating/metrics.rst b/doc/source/operating/metrics.rst
index 0053cbc..3c9cc7d 100644
--- a/doc/source/operating/metrics.rst
+++ b/doc/source/operating/metrics.rst
@@ -538,34 +538,10 @@ TotalHints CounterNumber of hint
messages written to thi
TotalHintsInProgress CounterNumber of hints attemping to be sent
currently.
== == ===
-.. _handoff-metrics:
-
-HintedHandoff Metrics
-^
-
-Metrics specific to Hinted Handoff. There are also some metrics related to
hints tracked in ``Storage Metrics``
-
-These metrics include the peer endpoint **in the metric name**
-
-Reported name format:
-
-**Metric Name**
-``org.apache.cassandra.metrics.HintedHandOffManager.``
-
-**JMX MBean**
-``org.apache.cassandra.metrics:type=HintedHandOffManager
name=``
-
-=== == ===
-NameType Description
-=== == ===
-Hints_created- CounterNumber of hints on disk for this
peer.
-Hints_not_stored-CounterNumber of hints not stored for
this peer, due to being down past the configured hint window.
-=== == ===
-
.. _hintsservice-metrics:
HintsService Metrics
-^
+
Metrics specific to the Hints delivery service. There are also some metrics
related to hints tracked in ``Storage Metrics``
diff --git a/src/java/org/apache/cassandra/db/HintedHandOffManager.java
b/src/java/org/apache/cassandra/db/HintedHandOffManager.java
deleted file mode 100644
index e26f658..000
--- a/src/java/org/apache/cassandra/db/HintedHandOffManager.java
+++ /dev/null
@@ -1,76 +0,0 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package org.apache.cassandra.db;
-
-import java.util.List;
-
-import org.apache.cassandra.hints.HintsService;
-import org.apache.cassandra.utils.MBeanWrapper;
-
-/**
- * A proxy class that implement the deprecated legacy
HintedHandoffManagerMBean interface.
- *
- * TODO: remove in 4.0.
- */
-@SuppressWarnings("deprecation")
-@Deprecated
-public final class HintedHandOffManager implements HintedHandOffManagerMBean
-{
-public static final HintedHandOffManager instance = new
HintedHandOffManager();
-
-public static final String MBEAN_NAME =
"org.apache.cassandra.db:type=HintedHandoffManager";
-
-private HintedHandOffManager()
-{
-}
-
-public void registerMBean()
-{
-MBeanWrappe
[jira] [Updated] (CASSANDRA-15939) Remove previously deprecated HintedHandoffManager
[
https://issues.apache.org/jira/browse/CASSANDRA-15939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15939:
-
Status: Ready to Commit (was: Review In Progress)
> Remove previously deprecated HintedHandoffManager
> -
>
> Key: CASSANDRA-15939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15939
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Hints
>Reporter: Stephen Mallette
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
>
> {{HintedHandOffManager}} was deprecated about 6 years ago:
> https://github.com/apache/cassandra/commit/96d41f0e0e44d9b3114a5d80dedf12053d36a76b
> with the TODO to remove it for 4.0. While looking at CASSANDRA-15582 and
> examining the published JMX elements it seemed sensible to remove this MBean
> to help clean up a bit as it appears to just be a proxy to the
> {{HintService}} at this point.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15406) Show the progress of data streaming and index build
[ https://issues.apache.org/jira/browse/CASSANDRA-15406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184186#comment-17184186 ] Stefan Miklosovic commented on CASSANDRA-15406: --- [~blerer] would you mind to go over that? > Show the progress of data streaming and index build > > > Key: CASSANDRA-15406 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15406 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Streaming, Legacy/Streaming and Messaging, > Tool/nodetool >Reporter: maxwellguo >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0, 4.x > > Time Spent: 3h 10m > Remaining Estimate: 0h > > I found that we should supply a command to show the progress of streaming > when we do the operation of bootstrap/move/decommission/removenode. For when > do data streaming , noboday knows which steps there program are in , so I > think a command to show the joing/leaving node's is needed . > > PR [https://github.com/apache/cassandra/pull/558] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15986) Repair tests flakiness
[ https://issues.apache.org/jira/browse/CASSANDRA-15986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15986: Authors: Berenguer Blasi (was: Ekaterina Dimitrova) > Repair tests flakiness > -- > > Key: CASSANDRA-15986 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15986 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-beta2 > > > Repair tests come up in test failure reports every now and then. I have tried > to repro the > [latest|https://ci-cassandra.apache.org/job/Cassandra-trunk/241/testReport/junit/dtest-novnode.repair_tests.repair_test/TestRepair/test_simple_sequential_repair/] > locally 100 times with no luck. > _dtest-novnode.repair_tests.repair_test/TestRepair/test_simple_sequential_repair_ > Still from experience from fixing other flaky tests I have some intuition > where the problems may lie. The proposed fix should add no harm if merged. We > can reopen the ticket if repair tests keep failing. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15821) Metrics Documentation Enhancements
[
https://issues.apache.org/jira/browse/CASSANDRA-15821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184129#comment-17184129
]
Caleb Rackliffe commented on CASSANDRA-15821:
-
[~aholmber] Just FYI, I'm going to try to wrap up CASSANDRA-15909 here this
week.
> Metrics Documentation Enhancements
> --
>
> Key: CASSANDRA-15821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15821
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Stephen Mallette
>Priority: Normal
> Fix For: 4.0-beta
>
>
> CASSANDRA-15582 involves quality around metrics and it was mentioned that
> reviewing and [improving
> documentation|https://github.com/apache/cassandra/blob/trunk/doc/source/operating/metrics.rst]
> around metrics would fall into that scope. Please consider some of this
> analysis in determining what improvements to make here:
> Please see [this
> spreadsheet|https://docs.google.com/spreadsheets/d/1iPWfCMIG75CI6LbYuDtCTjEOvZw-5dyH-e08bc63QnI/edit?usp=sharing]
> that itemizes almost all of cassandra's metrics and whether they are
> documented or not (and other notes). That spreadsheet is "almost all"
> because there are some metrics that don't seem to initialize as part of
> Cassandra startup (i was able to trigger some to initialize, but all were not
> immediately obvious). The missing metrics seem to be related to the following:
> * ThreadPool metrics - only some initialize at startup the list of which
> follow below
> * Streaming Metrics
> * HintedHandoff Metrics
> * HintsService Metrics
> Here are the ThreadPool scopes that get listed:
> {code}
> AntiEntropyStage
> CacheCleanupExecutor
> CompactionExecutor
> GossipStage
> HintsDispatcher
> MemtableFlushWriter
> MemtablePostFlush
> MemtableReclaimMemory
> MigrationStage
> MutationStage
> Native-Transport-Requests
> PendingRangeCalculator
> PerDiskMemtableFlushWriter_0
> ReadStage
> Repair-Task
> RequestResponseStage
> Sampler
> SecondaryIndexManagement
> ValidationExecutor
> ViewBuildExecutor
> {code}
> I noticed that Keyspace Metrics have this note: "Most of these metrics are
> the same as the Table Metrics above, only they are aggregated at the Keyspace
> level." I think I've isolated those metrics on table that are not on keyspace
> to specifically be:
> {code}
> BloomFilterFalsePositives
> BloomFilterFalseRatio
> BytesAnticompacted
> BytesFlushed
> BytesMutatedAnticompaction
> BytesPendingRepair
> BytesRepaired
> BytesUnrepaired
> CompactionBytesWritten
> CompressionRatio
> CoordinatorReadLatency
> CoordinatorScanLatency
> CoordinatorWriteLatency
> EstimatedColumnCountHistogram
> EstimatedPartitionCount
> EstimatedPartitionSizeHistogram
> KeyCacheHitRate
> LiveSSTableCount
> MaxPartitionSize
> MeanPartitionSize
> MinPartitionSize
> MutatedAnticompactionGauge
> PercentRepaired
> RowCacheHitOutOfRange
> RowCacheHit
> RowCacheMiss
> SpeculativeSampleLatencyNanos
> SyncTime
> WaitingOnFreeMemtableSpace
> DroppedMutations
> {code}
> Someone with greater knowledge of this area might consider it worth the
> effort to see if any of these metrics should be aggregated to the keyspace
> level in case they were inadvertently missed. In any case, perhaps the
> documentation could easily now reflect which metric names could be expected
> on Keyspace.
> The DroppedMessage metrics have a much larger body of scopes than just what
> were documented:
> {code}
> ASYMMETRIC_SYNC_REQ
> BATCH_REMOVE_REQ
> BATCH_REMOVE_RSP
> BATCH_STORE_REQ
> BATCH_STORE_RSP
> CLEANUP_MSG
> COUNTER_MUTATION_REQ
> COUNTER_MUTATION_RSP
> ECHO_REQ
> ECHO_RSP
> FAILED_SESSION_MSG
> FAILURE_RSP
> FINALIZE_COMMIT_MSG
> FINALIZE_PROMISE_MSG
> FINALIZE_PROPOSE_MSG
> GOSSIP_DIGEST_ACK
> GOSSIP_DIGEST_ACK2
> GOSSIP_DIGEST_SYN
> GOSSIP_SHUTDOWN
> HINT_REQ
> HINT_RSP
> INTERNAL_RSP
> MUTATION_REQ
> MUTATION_RSP
> PAXOS_COMMIT_REQ
> PAXOS_COMMIT_RSP
> PAXOS_PREPARE_REQ
> PAXOS_PREPARE_RSP
> PAXOS_PROPOSE_REQ
> PAXOS_PROPOSE_RSP
> PING_REQ
> PING_RSP
> PREPARE_CONSISTENT_REQ
> PREPARE_CONSISTENT_RSP
> PREPARE_MSG
> RANGE_REQ
> RANGE_RSP
> READ_REPAIR_REQ
> READ_REPAIR_RSP
> READ_REQ
> READ_RSP
> REPAIR_RSP
> REPLICATION_DONE_REQ
> REPLICATION_DONE_RSP
> REQUEST_RSP
> SCHEMA_PULL_REQ
> SCHEMA_PULL_RSP
> SCHEMA_PUSH_REQ
> SCHEMA_PUSH_RSP
> SCHEMA_VERSION_REQ
> SCHEMA_VERSION_RSP
> SNAPSHOT_MSG
> SNAPSHOT_REQ
> SNAPSHOT_RSP
> STATUS_REQ
> STATUS_RSP
> SYNC_REQ
> SYNC_RSP
> TRUNCATE_REQ
> TRUNCATE_RSP
> VALIDATION_REQ
> VALIDATION_RSP
> _SAMPLE
> _TEST_1
> _TEST_2
> _TRACE
> {code}
> I suppose I may yet be missing some metrics as my knowledge of what's
> available is limited to what I can get from JMX after cassandra
> initialization (and some initial starting commands) and what's int he
> documentation. If something is present
[jira] [Updated] (CASSANDRA-15821) Metrics Documentation Enhancements
[
https://issues.apache.org/jira/browse/CASSANDRA-15821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-15821:
Authors: Stephen Mallette
> Metrics Documentation Enhancements
> --
>
> Key: CASSANDRA-15821
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15821
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Stephen Mallette
>Priority: Normal
> Fix For: 4.0-beta
>
>
> CASSANDRA-15582 involves quality around metrics and it was mentioned that
> reviewing and [improving
> documentation|https://github.com/apache/cassandra/blob/trunk/doc/source/operating/metrics.rst]
> around metrics would fall into that scope. Please consider some of this
> analysis in determining what improvements to make here:
> Please see [this
> spreadsheet|https://docs.google.com/spreadsheets/d/1iPWfCMIG75CI6LbYuDtCTjEOvZw-5dyH-e08bc63QnI/edit?usp=sharing]
> that itemizes almost all of cassandra's metrics and whether they are
> documented or not (and other notes). That spreadsheet is "almost all"
> because there are some metrics that don't seem to initialize as part of
> Cassandra startup (i was able to trigger some to initialize, but all were not
> immediately obvious). The missing metrics seem to be related to the following:
> * ThreadPool metrics - only some initialize at startup the list of which
> follow below
> * Streaming Metrics
> * HintedHandoff Metrics
> * HintsService Metrics
> Here are the ThreadPool scopes that get listed:
> {code}
> AntiEntropyStage
> CacheCleanupExecutor
> CompactionExecutor
> GossipStage
> HintsDispatcher
> MemtableFlushWriter
> MemtablePostFlush
> MemtableReclaimMemory
> MigrationStage
> MutationStage
> Native-Transport-Requests
> PendingRangeCalculator
> PerDiskMemtableFlushWriter_0
> ReadStage
> Repair-Task
> RequestResponseStage
> Sampler
> SecondaryIndexManagement
> ValidationExecutor
> ViewBuildExecutor
> {code}
> I noticed that Keyspace Metrics have this note: "Most of these metrics are
> the same as the Table Metrics above, only they are aggregated at the Keyspace
> level." I think I've isolated those metrics on table that are not on keyspace
> to specifically be:
> {code}
> BloomFilterFalsePositives
> BloomFilterFalseRatio
> BytesAnticompacted
> BytesFlushed
> BytesMutatedAnticompaction
> BytesPendingRepair
> BytesRepaired
> BytesUnrepaired
> CompactionBytesWritten
> CompressionRatio
> CoordinatorReadLatency
> CoordinatorScanLatency
> CoordinatorWriteLatency
> EstimatedColumnCountHistogram
> EstimatedPartitionCount
> EstimatedPartitionSizeHistogram
> KeyCacheHitRate
> LiveSSTableCount
> MaxPartitionSize
> MeanPartitionSize
> MinPartitionSize
> MutatedAnticompactionGauge
> PercentRepaired
> RowCacheHitOutOfRange
> RowCacheHit
> RowCacheMiss
> SpeculativeSampleLatencyNanos
> SyncTime
> WaitingOnFreeMemtableSpace
> DroppedMutations
> {code}
> Someone with greater knowledge of this area might consider it worth the
> effort to see if any of these metrics should be aggregated to the keyspace
> level in case they were inadvertently missed. In any case, perhaps the
> documentation could easily now reflect which metric names could be expected
> on Keyspace.
> The DroppedMessage metrics have a much larger body of scopes than just what
> were documented:
> {code}
> ASYMMETRIC_SYNC_REQ
> BATCH_REMOVE_REQ
> BATCH_REMOVE_RSP
> BATCH_STORE_REQ
> BATCH_STORE_RSP
> CLEANUP_MSG
> COUNTER_MUTATION_REQ
> COUNTER_MUTATION_RSP
> ECHO_REQ
> ECHO_RSP
> FAILED_SESSION_MSG
> FAILURE_RSP
> FINALIZE_COMMIT_MSG
> FINALIZE_PROMISE_MSG
> FINALIZE_PROPOSE_MSG
> GOSSIP_DIGEST_ACK
> GOSSIP_DIGEST_ACK2
> GOSSIP_DIGEST_SYN
> GOSSIP_SHUTDOWN
> HINT_REQ
> HINT_RSP
> INTERNAL_RSP
> MUTATION_REQ
> MUTATION_RSP
> PAXOS_COMMIT_REQ
> PAXOS_COMMIT_RSP
> PAXOS_PREPARE_REQ
> PAXOS_PREPARE_RSP
> PAXOS_PROPOSE_REQ
> PAXOS_PROPOSE_RSP
> PING_REQ
> PING_RSP
> PREPARE_CONSISTENT_REQ
> PREPARE_CONSISTENT_RSP
> PREPARE_MSG
> RANGE_REQ
> RANGE_RSP
> READ_REPAIR_REQ
> READ_REPAIR_RSP
> READ_REQ
> READ_RSP
> REPAIR_RSP
> REPLICATION_DONE_REQ
> REPLICATION_DONE_RSP
> REQUEST_RSP
> SCHEMA_PULL_REQ
> SCHEMA_PULL_RSP
> SCHEMA_PUSH_REQ
> SCHEMA_PUSH_RSP
> SCHEMA_VERSION_REQ
> SCHEMA_VERSION_RSP
> SNAPSHOT_MSG
> SNAPSHOT_REQ
> SNAPSHOT_RSP
> STATUS_REQ
> STATUS_RSP
> SYNC_REQ
> SYNC_RSP
> TRUNCATE_REQ
> TRUNCATE_RSP
> VALIDATION_REQ
> VALIDATION_RSP
> _SAMPLE
> _TEST_1
> _TEST_2
> _TRACE
> {code}
> I suppose I may yet be missing some metrics as my knowledge of what's
> available is limited to what I can get from JMX after cassandra
> initialization (and some initial starting commands) and what's int he
> documentation. If something is present that is missing from both then I won't
> know it's there. Anyway, perhaps this issue can help build some disc
[jira] [Commented] (CASSANDRA-16071) max_compaction_flush_memory_in_mb is interpreted as bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-16071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184111#comment-17184111
]
ZhaoYang commented on CASSANDRA-16071:
--
Thanks for the patch. LGTM.
> max_compaction_flush_memory_in_mb is interpreted as bytes
> -
>
> Key: CASSANDRA-16071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16071
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.11.x, 4.0-beta
>
>
> In CASSANDRA-12662, [~scottcarey]
> [reported|https://issues.apache.org/jira/browse/CASSANDRA-12662?focusedCommentId=17070055&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17070055]
> that the {{max_compaction_flush_memory_in_mb}} setting gets incorrectly
> interpreted in bytes rather than megabytes as its name implies.
> {quote}
> 1. the setting 'max_compaction_flush_memory_in_mb' is a misnomer, it is
> actually memory in BYTES. If you take it at face value, and set it to say,
> '512' thinking that means 512MB, you will produce a million temp files
> rather quickly in a large compaction, which will exhaust even large values of
> max_map_count rapidly, and get the OOM: Map Error issue above and possibly
> have a very difficult situation to get a cluster back into a place where
> nodes aren't crashing while initilaizing or soon after. This issue is minor
> if you know about it in advance and set the value IN BYTES.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15958) org.apache.cassandra.net.ConnectionTest testMessagePurging
[
https://issues.apache.org/jira/browse/CASSANDRA-15958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184097#comment-17184097
]
Adam Holmberg edited comment on CASSANDRA-15958 at 8/25/20, 2:46 PM:
-
Thanks, Yifan, for taking a look. I'll revisit that before submitting for
review.
In the mean time, I looked some at the other flakiness.
{noformat}
java.lang.RuntimeException: java.util.concurrent.TimeoutException
at
org.apache.cassandra.net.ConnectionTest.lambda$testMessagePurging$36(ConnectionTest.java:700)
at
org.apache.cassandra.net.ConnectionTest.lambda$testMessagePurging$40(ConnectionTest.java:730)
at
org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:263)
at
org.apache.cassandra.net.ConnectionTest.testManual(ConnectionTest.java:236)
at
org.apache.cassandra.net.ConnectionTest.testMessagePurging(ConnectionTest.java:679)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Caused by: java.util.concurrent.TimeoutException
at
java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
at
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
at
org.apache.cassandra.net.ConnectionTest.lambda$testMessagePurging$36(ConnectionTest.java:693)
{noformat}
Timeout waiting for message to be purged. It will never purge.
Identified another race condition where the next expiration can be set to
Long.MAX_VALUE, and pruning will never happen.
[Periodic
pruning|https://github.com/aholmberg/cassandra/blob/eb1c9bf59c7faba3e65be7fc45359611c7242672/src/java/org/apache/cassandra/net/OutboundMessageQueue.java#L203-L209]
runs in the background. It might run against an empty queue, producing a
[pruner|https://github.com/aholmberg/cassandra/blob/eb1c9bf59c7faba3e65be7fc45359611c7242672/src/java/org/apache/cassandra/net/OutboundMessageQueue.java#L288]
with {{earliestExpiresAt = Long.MAX_VALUE}}. In the mean time a message is
added and the current deadline matches that message. If our nowNanos was
established more than the clock resolution after the message expire time was
set, the earliestExpiresAt time is
[set|https://github.com/aholmberg/cassandra/blob/eb1c9bf59c7faba3e65be7fc45359611c7242672/src/java/org/apache/cassandra/net/OutboundMessageQueue.java#L228-L229]
to {{Long.MAX_VALUE}}.
I have another tweak for this issue. Still looking at some other related unit
tests.
was (Author: aholmber):
Thanks, Yifan, for taking a look. I'll revisit that before submitting for
review.
In the mean time, I looked some at the other flakiness.
{noformat}
java.lang.RuntimeException: java.util.concurrent.TimeoutException
at
org.apache.cassandra.net.ConnectionTest.lambda$testMessagePurging$36(ConnectionTest.java:700)
at
org.apache.cassandra.net.ConnectionTest.lambda$testMessagePurging$40(ConnectionTest.java:730)
at
org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:263)
at
org.apache.cassandra.net.ConnectionTest.testManual(ConnectionTest.java:236)
at
org.apache.cassandra.net.ConnectionTest.testMessagePurging(ConnectionTest.java:679)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Caused by: java.util.concurrent.TimeoutException
at
java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
at
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
at
org.apache.cassandra.net.ConnectionTest.lambda$testMessagePurging$36(ConnectionTest.java:693)
{noformat}
Timeout waiting for message to be purged. It will never purge.
Identified another race condition where the next expiration can be set to
Long.MAX_VALUE, and pruning will never happen.
[Periodic
pruning|https://github.com/aholmberg/cassandra/blob/eb1c9bf59c7faba3e65be7fc45359611c7242672/src/java/org/apache/cassandra/net/OutboundMessageQueue.java#L203-L209]
runs in the background. It might run against an empty queue, producing a
[pruner|https://github.com/aholmberg/cassandra/blob/eb1c9bf59c7faba3e65be7fc45359611c7242672/src/java/org/apache/cassandra/net/OutboundMessageQueue.java#L288]
with {{earliestExpiresAt = Long.MAX_VALUE}}. In the mean time a message is
added and the current deadline matches that message. If our nowNanos is was
establi
[jira] [Commented] (CASSANDRA-15958) org.apache.cassandra.net.ConnectionTest testMessagePurging
[
https://issues.apache.org/jira/browse/CASSANDRA-15958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184097#comment-17184097
]
Adam Holmberg commented on CASSANDRA-15958:
---
Thanks, Yifan, for taking a look. I'll revisit that before submitting for
review.
In the mean time, I looked some at the other flakiness.
{noformat}
java.lang.RuntimeException: java.util.concurrent.TimeoutException
at
org.apache.cassandra.net.ConnectionTest.lambda$testMessagePurging$36(ConnectionTest.java:700)
at
org.apache.cassandra.net.ConnectionTest.lambda$testMessagePurging$40(ConnectionTest.java:730)
at
org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:263)
at
org.apache.cassandra.net.ConnectionTest.testManual(ConnectionTest.java:236)
at
org.apache.cassandra.net.ConnectionTest.testMessagePurging(ConnectionTest.java:679)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Caused by: java.util.concurrent.TimeoutException
at
java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
at
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
at
org.apache.cassandra.net.ConnectionTest.lambda$testMessagePurging$36(ConnectionTest.java:693)
{noformat}
Timeout waiting for message to be purged. It will never purge.
Identified another race condition where the next expiration can be set to
Long.MAX_VALUE, and pruning will never happen.
[Periodic
pruning|https://github.com/aholmberg/cassandra/blob/eb1c9bf59c7faba3e65be7fc45359611c7242672/src/java/org/apache/cassandra/net/OutboundMessageQueue.java#L203-L209]
runs in the background. It might run against an empty queue, producing a
[pruner|https://github.com/aholmberg/cassandra/blob/eb1c9bf59c7faba3e65be7fc45359611c7242672/src/java/org/apache/cassandra/net/OutboundMessageQueue.java#L288]
with {{earliestExpiresAt = Long.MAX_VALUE}}. In the mean time a message is
added and the current deadline matches that message. If our nowNanos is was
established more than the clock resolution after the message expire time was
set, the earliestExpiresAt time is
[set|https://github.com/aholmberg/cassandra/blob/eb1c9bf59c7faba3e65be7fc45359611c7242672/src/java/org/apache/cassandra/net/OutboundMessageQueue.java#L228-L229]
to {{Long.MAX_VALUE}}.
I have another tweak for this issue. Still looking at some other related unit
tests.
> org.apache.cassandra.net.ConnectionTest testMessagePurging
> --
>
> Key: CASSANDRA-15958
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15958
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Build:
> https://ci-cassandra.apache.org/job/Cassandra-trunk-test/196/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessagePurging/
> Build:
> https://ci-cassandra.apache.org/job/Cassandra-trunk-test/194/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessagePurging/
> java.util.concurrent.TimeoutException
> at org.apache.cassandra.net.AsyncPromise.get(AsyncPromise.java:258)
> at org.apache.cassandra.net.FutureDelegate.get(FutureDelegate.java:143)
> at
> org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:268)
> at
> org.apache.cassandra.net.ConnectionTest.testManual(ConnectionTest.java:236)
> at
> org.apache.cassandra.net.ConnectionTest.testMessagePurging(ConnectionTest.java:679)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15988) Add nodetool getfullquerylog
[ https://issues.apache.org/jira/browse/CASSANDRA-15988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183955#comment-17183955 ] Stefan Miklosovic edited comment on CASSANDRA-15988 at 8/25/20, 2:27 PM: - PR: [https://github.com/apache/cassandra/pull/721] build: [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/271] it is all fully tested, added docs, the actual output is shown in docs. was (Author: stefan.miklosovic): PR: [https://github.com/apache/cassandra/pull/721] build: [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/268/] it is all fully tested, added docs, the actual output is shown in docs I have made path parameter required so that will be handled by Airlift tooling in nodetool directly. > Add nodetool getfullquerylog > - > > Key: CASSANDRA-15988 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15988 > Project: Cassandra > Issue Type: Improvement > Components: Tool/fql >Reporter: Ekaterina Dimitrova >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-rc > > > This ticket is raised based on CASSANDRA-15791 and valuable feedback provided > by [~jshook]. > There are two outstanding questions: > * forming the exact shape of such a command and how it can benefit the > users; to be discussed in detail in this ticket > * Is this a thing we as a project can add to 4.0 beta or it should be > considered in 4.1 for example > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16060) Cassandra crashes with OutOfMemory Exception
[
https://issues.apache.org/jira/browse/CASSANDRA-16060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184081#comment-17184081
]
Brandon Williams commented on CASSANDRA-16060:
--
That sounds like a plausible cause, though 150k isn't that bad. Can you query
less rows at a time or something else to mitigate this?
> Cassandra crashes with OutOfMemory Exception
>
>
> Key: CASSANDRA-16060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16060
> Project: Cassandra
> Issue Type: Bug
>Reporter: Thomas De Keulenaer
>Priority: Normal
> Attachments: cassandra.yaml
>
>
> Out Cassandra instance has run perfectly for almost 5 years, but aout a month
> ago, the performance has dropped significantly. Reads are incredibly slow or
> time out, making the cluster almost useless. The load on the nodes has
> skyrocketed to almost 100% CPU usage. On top of that, the nodes crash with
> OutOfMemoryError.
> I also have [heap
> dumps|https://arcelormittal-my.sharepoint.com/:f:/g/personal/sidtdke_sidmar_be/Es7PaQq15jdKgIvDfMFfBRoBR6sr60t156AxbA0dFZvzJg?e=rohgHn].
>
> Cassandra version: 3.11.1
> Java version: OpenJDK 1.8.0_201
> We have upgraded our nodes to version 3.11.7 and applied the recommended
> OS/system setting, but this has not improved performance.
> {code:java}
> ERROR [ReadStage-9] 2020-08-10 14:56:01,399 JVMStabilityInspector.java:142 -
> JVM state determined to be unstable. Exiting forcefully due to:
> java.lang.OutOfMemoryError: Java heap space
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> ~[na:1.8.0_201]
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335) ~[na:1.8.0_201]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:159)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:413)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.Cell$Serializer.serialize(Cell.java:210)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.lambda$serializeRowBody$0(UnfilteredSerializer.java:248)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer$$Lambda$120/205506350.accept(Unknown
> Source) ~[na:na]
> at
> org.apache.cassandra.utils.btree.BTree.applyForwards(BTree.java:1242)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.utils.btree.BTree.apply(BTree.java:1197)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.db.rows.BTreeRow.apply(BTreeRow.java:172)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializeRowBody(UnfilteredSerializer.java:236)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:205)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:137)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:125)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:137)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:92)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:79)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:308)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:167)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:160)
> ~[ap
[jira] [Commented] (CASSANDRA-16060) Cassandra crashes with OutOfMemory Exception
[
https://issues.apache.org/jira/browse/CASSANDRA-16060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184075#comment-17184075
]
Thomas De Keulenaer commented on CASSANDRA-16060:
-
I think each query reads a lot of rows here 1 column is/can be a large string
(~150kB). And together they amount to 113MB.
We no longer write these large string, that was fixed a month ago. But reading
them may cause the OOM.
> Cassandra crashes with OutOfMemory Exception
>
>
> Key: CASSANDRA-16060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16060
> Project: Cassandra
> Issue Type: Bug
>Reporter: Thomas De Keulenaer
>Priority: Normal
> Attachments: cassandra.yaml
>
>
> Out Cassandra instance has run perfectly for almost 5 years, but aout a month
> ago, the performance has dropped significantly. Reads are incredibly slow or
> time out, making the cluster almost useless. The load on the nodes has
> skyrocketed to almost 100% CPU usage. On top of that, the nodes crash with
> OutOfMemoryError.
> I also have [heap
> dumps|https://arcelormittal-my.sharepoint.com/:f:/g/personal/sidtdke_sidmar_be/Es7PaQq15jdKgIvDfMFfBRoBR6sr60t156AxbA0dFZvzJg?e=rohgHn].
>
> Cassandra version: 3.11.1
> Java version: OpenJDK 1.8.0_201
> We have upgraded our nodes to version 3.11.7 and applied the recommended
> OS/system setting, but this has not improved performance.
> {code:java}
> ERROR [ReadStage-9] 2020-08-10 14:56:01,399 JVMStabilityInspector.java:142 -
> JVM state determined to be unstable. Exiting forcefully due to:
> java.lang.OutOfMemoryError: Java heap space
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> ~[na:1.8.0_201]
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335) ~[na:1.8.0_201]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:159)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:413)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.Cell$Serializer.serialize(Cell.java:210)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.lambda$serializeRowBody$0(UnfilteredSerializer.java:248)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer$$Lambda$120/205506350.accept(Unknown
> Source) ~[na:na]
> at
> org.apache.cassandra.utils.btree.BTree.applyForwards(BTree.java:1242)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.utils.btree.BTree.apply(BTree.java:1197)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.db.rows.BTreeRow.apply(BTreeRow.java:172)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializeRowBody(UnfilteredSerializer.java:236)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:205)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:137)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:125)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:137)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:92)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:79)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:308)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:167)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
>
[jira] [Commented] (CASSANDRA-16060) Cassandra crashes with OutOfMemory Exception
[
https://issues.apache.org/jira/browse/CASSANDRA-16060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184070#comment-17184070
]
Thomas De Keulenaer commented on CASSANDRA-16060:
-
I don't think there are errors in the logs. Just a lot of "X operations were
slow in the last Y seconds" and "X operations timed out.
> Cassandra crashes with OutOfMemory Exception
>
>
> Key: CASSANDRA-16060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16060
> Project: Cassandra
> Issue Type: Bug
>Reporter: Thomas De Keulenaer
>Priority: Normal
> Attachments: cassandra.yaml
>
>
> Out Cassandra instance has run perfectly for almost 5 years, but aout a month
> ago, the performance has dropped significantly. Reads are incredibly slow or
> time out, making the cluster almost useless. The load on the nodes has
> skyrocketed to almost 100% CPU usage. On top of that, the nodes crash with
> OutOfMemoryError.
> I also have [heap
> dumps|https://arcelormittal-my.sharepoint.com/:f:/g/personal/sidtdke_sidmar_be/Es7PaQq15jdKgIvDfMFfBRoBR6sr60t156AxbA0dFZvzJg?e=rohgHn].
>
> Cassandra version: 3.11.1
> Java version: OpenJDK 1.8.0_201
> We have upgraded our nodes to version 3.11.7 and applied the recommended
> OS/system setting, but this has not improved performance.
> {code:java}
> ERROR [ReadStage-9] 2020-08-10 14:56:01,399 JVMStabilityInspector.java:142 -
> JVM state determined to be unstable. Exiting forcefully due to:
> java.lang.OutOfMemoryError: Java heap space
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> ~[na:1.8.0_201]
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335) ~[na:1.8.0_201]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:159)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:413)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.Cell$Serializer.serialize(Cell.java:210)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.lambda$serializeRowBody$0(UnfilteredSerializer.java:248)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer$$Lambda$120/205506350.accept(Unknown
> Source) ~[na:na]
> at
> org.apache.cassandra.utils.btree.BTree.applyForwards(BTree.java:1242)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.utils.btree.BTree.apply(BTree.java:1197)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.db.rows.BTreeRow.apply(BTreeRow.java:172)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializeRowBody(UnfilteredSerializer.java:236)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:205)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:137)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:125)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:137)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:92)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:79)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:308)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:167)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:160)
>
[jira] [Updated] (CASSANDRA-15939) Remove previously deprecated HintedHandoffManager
[
https://issues.apache.org/jira/browse/CASSANDRA-15939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15939:
-
Reviewers: Brandon Williams, Brandon Williams (was: Brandon Williams)
Brandon Williams, Brandon Williams
Status: Review In Progress (was: Patch Available)
> Remove previously deprecated HintedHandoffManager
> -
>
> Key: CASSANDRA-15939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15939
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Hints
>Reporter: Stephen Mallette
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
>
> {{HintedHandOffManager}} was deprecated about 6 years ago:
> https://github.com/apache/cassandra/commit/96d41f0e0e44d9b3114a5d80dedf12053d36a76b
> with the TODO to remove it for 4.0. While looking at CASSANDRA-15582 and
> examining the published JMX elements it seemed sensible to remove this MBean
> to help clean up a bit as it appears to just be a proxy to the
> {{HintService}} at this point.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16060) Cassandra crashes with OutOfMemory Exception
[
https://issues.apache.org/jira/browse/CASSANDRA-16060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184058#comment-17184058
]
Brandon Williams commented on CASSANDRA-16060:
--
You don't have message coalescing enabled, so it should correspond to one
query. But, that's still quite large. Your commitlog segment size is the
default at 32MB, so you can't write a mutation larger than 16MB. Are you
seeing any errors in the logs before the OOM? Generally I wouldn't think a
schema problem causes this.
> Cassandra crashes with OutOfMemory Exception
>
>
> Key: CASSANDRA-16060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16060
> Project: Cassandra
> Issue Type: Bug
>Reporter: Thomas De Keulenaer
>Priority: Normal
> Attachments: cassandra.yaml
>
>
> Out Cassandra instance has run perfectly for almost 5 years, but aout a month
> ago, the performance has dropped significantly. Reads are incredibly slow or
> time out, making the cluster almost useless. The load on the nodes has
> skyrocketed to almost 100% CPU usage. On top of that, the nodes crash with
> OutOfMemoryError.
> I also have [heap
> dumps|https://arcelormittal-my.sharepoint.com/:f:/g/personal/sidtdke_sidmar_be/Es7PaQq15jdKgIvDfMFfBRoBR6sr60t156AxbA0dFZvzJg?e=rohgHn].
>
> Cassandra version: 3.11.1
> Java version: OpenJDK 1.8.0_201
> We have upgraded our nodes to version 3.11.7 and applied the recommended
> OS/system setting, but this has not improved performance.
> {code:java}
> ERROR [ReadStage-9] 2020-08-10 14:56:01,399 JVMStabilityInspector.java:142 -
> JVM state determined to be unstable. Exiting forcefully due to:
> java.lang.OutOfMemoryError: Java heap space
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> ~[na:1.8.0_201]
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335) ~[na:1.8.0_201]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:159)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:413)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.Cell$Serializer.serialize(Cell.java:210)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.lambda$serializeRowBody$0(UnfilteredSerializer.java:248)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer$$Lambda$120/205506350.accept(Unknown
> Source) ~[na:na]
> at
> org.apache.cassandra.utils.btree.BTree.applyForwards(BTree.java:1242)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.utils.btree.BTree.apply(BTree.java:1197)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.db.rows.BTreeRow.apply(BTreeRow.java:172)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializeRowBody(UnfilteredSerializer.java:236)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:205)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:137)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:125)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:137)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:92)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:79)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:308)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.ReadRe
[jira] [Commented] (CASSANDRA-15939) Remove previously deprecated HintedHandoffManager
[
https://issues.apache.org/jira/browse/CASSANDRA-15939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184057#comment-17184057
]
Berenguer Blasi commented on CASSANDRA-15939:
-
What on earth is that? Well my rst editor adds those for me upon 'save file' so
I can't help it !!??. I had to use vi to remove them... Thanks for spotting it.
> Remove previously deprecated HintedHandoffManager
> -
>
> Key: CASSANDRA-15939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15939
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Hints
>Reporter: Stephen Mallette
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
>
> {{HintedHandOffManager}} was deprecated about 6 years ago:
> https://github.com/apache/cassandra/commit/96d41f0e0e44d9b3114a5d80dedf12053d36a76b
> with the TODO to remove it for 4.0. While looking at CASSANDRA-15582 and
> examining the published JMX elements it seemed sensible to remove this MBean
> to help clean up a bit as it appears to just be a proxy to the
> {{HintService}} at this point.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15939) Remove previously deprecated HintedHandoffManager
[
https://issues.apache.org/jira/browse/CASSANDRA-15939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184040#comment-17184040
]
Brandon Williams commented on CASSANDRA-15939:
--
Looks good, but did you mean to change that line of dots in the license portion
of metrics.rst?
> Remove previously deprecated HintedHandoffManager
> -
>
> Key: CASSANDRA-15939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15939
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Hints
>Reporter: Stephen Mallette
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
>
> {{HintedHandOffManager}} was deprecated about 6 years ago:
> https://github.com/apache/cassandra/commit/96d41f0e0e44d9b3114a5d80dedf12053d36a76b
> with the TODO to remove it for 4.0. While looking at CASSANDRA-15582 and
> examining the published JMX elements it seemed sensible to remove this MBean
> to help clean up a bit as it appears to just be a proxy to the
> {{HintService}} at this point.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16071) max_compaction_flush_memory_in_mb is interpreted as bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-16071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16071:
---
Test and Documentation Plan: CI running. Unit test added. (was: CI running)
Status: Patch Available (was: In Progress)
> max_compaction_flush_memory_in_mb is interpreted as bytes
> -
>
> Key: CASSANDRA-16071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16071
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.11.x, 4.0-beta
>
>
> In CASSANDRA-12662, [~scottcarey]
> [reported|https://issues.apache.org/jira/browse/CASSANDRA-12662?focusedCommentId=17070055&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17070055]
> that the {{max_compaction_flush_memory_in_mb}} setting gets incorrectly
> interpreted in bytes rather than megabytes as its name implies.
> {quote}
> 1. the setting 'max_compaction_flush_memory_in_mb' is a misnomer, it is
> actually memory in BYTES. If you take it at face value, and set it to say,
> '512' thinking that means 512MB, you will produce a million temp files
> rather quickly in a large compaction, which will exhaust even large values of
> max_map_count rapidly, and get the OOM: Map Error issue above and possibly
> have a very difficult situation to get a cluster back into a place where
> nodes aren't crashing while initilaizing or soon after. This issue is minor
> if you know about it in advance and set the value IN BYTES.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16071) max_compaction_flush_memory_in_mb is interpreted as bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-16071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184038#comment-17184038
]
Michael Semb Wever commented on CASSANDRA-16071:
Unit test added.
> max_compaction_flush_memory_in_mb is interpreted as bytes
> -
>
> Key: CASSANDRA-16071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16071
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.11.x, 4.0-beta
>
>
> In CASSANDRA-12662, [~scottcarey]
> [reported|https://issues.apache.org/jira/browse/CASSANDRA-12662?focusedCommentId=17070055&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17070055]
> that the {{max_compaction_flush_memory_in_mb}} setting gets incorrectly
> interpreted in bytes rather than megabytes as its name implies.
> {quote}
> 1. the setting 'max_compaction_flush_memory_in_mb' is a misnomer, it is
> actually memory in BYTES. If you take it at face value, and set it to say,
> '512' thinking that means 512MB, you will produce a million temp files
> rather quickly in a large compaction, which will exhaust even large values of
> max_map_count rapidly, and get the OOM: Map Error issue above and possibly
> have a very difficult situation to get a cluster back into a place where
> nodes aren't crashing while initilaizing or soon after. This issue is minor
> if you know about it in advance and set the value IN BYTES.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16071) max_compaction_flush_memory_in_mb is interpreted as bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-16071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16071:
---
Test and Documentation Plan: CI run. Unit test added. (was: CI running.
Unit test added.)
> max_compaction_flush_memory_in_mb is interpreted as bytes
> -
>
> Key: CASSANDRA-16071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16071
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.11.x, 4.0-beta
>
>
> In CASSANDRA-12662, [~scottcarey]
> [reported|https://issues.apache.org/jira/browse/CASSANDRA-12662?focusedCommentId=17070055&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17070055]
> that the {{max_compaction_flush_memory_in_mb}} setting gets incorrectly
> interpreted in bytes rather than megabytes as its name implies.
> {quote}
> 1. the setting 'max_compaction_flush_memory_in_mb' is a misnomer, it is
> actually memory in BYTES. If you take it at face value, and set it to say,
> '512' thinking that means 512MB, you will produce a million temp files
> rather quickly in a large compaction, which will exhaust even large values of
> max_map_count rapidly, and get the OOM: Map Error issue above and possibly
> have a very difficult situation to get a cluster back into a place where
> nodes aren't crashing while initilaizing or soon after. This issue is minor
> if you know about it in advance and set the value IN BYTES.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16074) Add metric for client concurrent byte throttle
[ https://issues.apache.org/jira/browse/CASSANDRA-16074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184021#comment-17184021 ] Chris Lohfink commented on CASSANDRA-16074: --- The justification is that the throttle is really hard to use without a metric to tell what it’s at. Especially since it will be heavily based on the data model. It isn’t required for the throttle to work though as well so it can wait. > Add metric for client concurrent byte throttle > -- > > Key: CASSANDRA-16074 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16074 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client, Observability/Metrics >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > > Add a metric to expose the current bytes and bytes per ip used that is used > in the existing throttle so its possible to determine what to set it to. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15939) Remove previously deprecated HintedHandoffManager
[
https://issues.apache.org/jira/browse/CASSANDRA-15939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184015#comment-17184015
]
Berenguer Blasi commented on CASSANDRA-15939:
-
Thx for confirming [~stefan.miklosovic]
> Remove previously deprecated HintedHandoffManager
> -
>
> Key: CASSANDRA-15939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15939
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Hints
>Reporter: Stephen Mallette
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
>
> {{HintedHandOffManager}} was deprecated about 6 years ago:
> https://github.com/apache/cassandra/commit/96d41f0e0e44d9b3114a5d80dedf12053d36a76b
> with the TODO to remove it for 4.0. While looking at CASSANDRA-15582 and
> examining the published JMX elements it seemed sensible to remove this MBean
> to help clean up a bit as it appears to just be a proxy to the
> {{HintService}} at this point.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15939) Remove previously deprecated HintedHandoffManager
[
https://issues.apache.org/jira/browse/CASSANDRA-15939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183999#comment-17183999
]
Stefan Miklosovic commented on CASSANDRA-15939:
---
Based on private discussion with [~aleksey], this is fine to delete in 4.0.
> Remove previously deprecated HintedHandoffManager
> -
>
> Key: CASSANDRA-15939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15939
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Hints
>Reporter: Stephen Mallette
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
>
> {{HintedHandOffManager}} was deprecated about 6 years ago:
> https://github.com/apache/cassandra/commit/96d41f0e0e44d9b3114a5d80dedf12053d36a76b
> with the TODO to remove it for 4.0. While looking at CASSANDRA-15582 and
> examining the published JMX elements it seemed sensible to remove this MBean
> to help clean up a bit as it appears to just be a proxy to the
> {{HintService}} at this point.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15939) Remove previously deprecated HintedHandoffManager
[
https://issues.apache.org/jira/browse/CASSANDRA-15939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-15939:
Test and Documentation Plan: See PR
Status: Patch Available (was: In Progress)
> Remove previously deprecated HintedHandoffManager
> -
>
> Key: CASSANDRA-15939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15939
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Hints
>Reporter: Stephen Mallette
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
>
> {{HintedHandOffManager}} was deprecated about 6 years ago:
> https://github.com/apache/cassandra/commit/96d41f0e0e44d9b3114a5d80dedf12053d36a76b
> with the TODO to remove it for 4.0. While looking at CASSANDRA-15582 and
> examining the published JMX elements it seemed sensible to remove this MBean
> to help clean up a bit as it appears to just be a proxy to the
> {{HintService}} at this point.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16073) cql_tracing_test.py failing repeatedly on jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-16073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183983#comment-17183983 ] Berenguer Blasi commented on CASSANDRA-16073: - [~blerer]CI results are in the PR. You can see them [here|https://ci-cassandra.apache.org/job/Cassandra-devbranch/266/] > cql_tracing_test.py failing repeatedly on jenkins > - > > Key: CASSANDRA-16073 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16073 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 20m > Remaining Estimate: 0h > > Jenkins has been failing tracing tests repeatedly -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16073) cql_tracing_test.py failing repeatedly on jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-16073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183957#comment-17183957 ] Benjamin Lerer commented on CASSANDRA-16073: The fix looks fine to me. Waiting for the CI-results. > cql_tracing_test.py failing repeatedly on jenkins > - > > Key: CASSANDRA-16073 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16073 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 20m > Remaining Estimate: 0h > > Jenkins has been failing tracing tests repeatedly -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16073) cql_tracing_test.py failing repeatedly on jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-16073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16073: --- Reviewers: Benjamin Lerer > cql_tracing_test.py failing repeatedly on jenkins > - > > Key: CASSANDRA-16073 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16073 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 20m > Remaining Estimate: 0h > > Jenkins has been failing tracing tests repeatedly -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15988) Add nodetool getfullquerylog
[ https://issues.apache.org/jira/browse/CASSANDRA-15988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183955#comment-17183955 ] Stefan Miklosovic commented on CASSANDRA-15988: --- PR: [https://github.com/apache/cassandra/pull/721] build: [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/268/] it is all fully tested, added docs, the actual output is shown in docs I have made path parameter required so that will be handled by Airlift tooling in nodetool directly. > Add nodetool getfullquerylog > - > > Key: CASSANDRA-15988 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15988 > Project: Cassandra > Issue Type: Improvement > Components: Tool/fql >Reporter: Ekaterina Dimitrova >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-rc > > > This ticket is raised based on CASSANDRA-15791 and valuable feedback provided > by [~jshook]. > There are two outstanding questions: > * forming the exact shape of such a command and how it can benefit the > users; to be discussed in detail in this ticket > * Is this a thing we as a project can add to 4.0 beta or it should be > considered in 4.1 for example > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16060) Cassandra crashes with OutOfMemory Exception
[
https://issues.apache.org/jira/browse/CASSANDRA-16060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183949#comment-17183949
]
Thomas De Keulenaer commented on CASSANDRA-16060:
-
[^cassandra.yaml]
I also inspected the contents of the QueuedMessage. I notice we a writing a lot
of application data in each message.
Does each Message corresond to one query or are queries split over messages or
grouped in messages? If they correspond to 1 query, perhaps we must change our
schema.
> Cassandra crashes with OutOfMemory Exception
>
>
> Key: CASSANDRA-16060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16060
> Project: Cassandra
> Issue Type: Bug
>Reporter: Thomas De Keulenaer
>Priority: Normal
> Attachments: cassandra.yaml
>
>
> Out Cassandra instance has run perfectly for almost 5 years, but aout a month
> ago, the performance has dropped significantly. Reads are incredibly slow or
> time out, making the cluster almost useless. The load on the nodes has
> skyrocketed to almost 100% CPU usage. On top of that, the nodes crash with
> OutOfMemoryError.
> I also have [heap
> dumps|https://arcelormittal-my.sharepoint.com/:f:/g/personal/sidtdke_sidmar_be/Es7PaQq15jdKgIvDfMFfBRoBR6sr60t156AxbA0dFZvzJg?e=rohgHn].
>
> Cassandra version: 3.11.1
> Java version: OpenJDK 1.8.0_201
> We have upgraded our nodes to version 3.11.7 and applied the recommended
> OS/system setting, but this has not improved performance.
> {code:java}
> ERROR [ReadStage-9] 2020-08-10 14:56:01,399 JVMStabilityInspector.java:142 -
> JVM state determined to be unstable. Exiting forcefully due to:
> java.lang.OutOfMemoryError: Java heap space
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> ~[na:1.8.0_201]
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335) ~[na:1.8.0_201]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:159)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:413)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.Cell$Serializer.serialize(Cell.java:210)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.lambda$serializeRowBody$0(UnfilteredSerializer.java:248)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer$$Lambda$120/205506350.accept(Unknown
> Source) ~[na:na]
> at
> org.apache.cassandra.utils.btree.BTree.applyForwards(BTree.java:1242)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.utils.btree.BTree.apply(BTree.java:1197)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.db.rows.BTreeRow.apply(BTreeRow.java:172)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializeRowBody(UnfilteredSerializer.java:236)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:205)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:137)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:125)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:137)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:92)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:79)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:308)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataRe
[jira] [Updated] (CASSANDRA-16060) Cassandra crashes with OutOfMemory Exception
[
https://issues.apache.org/jira/browse/CASSANDRA-16060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas De Keulenaer updated CASSANDRA-16060:
Attachment: cassandra.yaml
> Cassandra crashes with OutOfMemory Exception
>
>
> Key: CASSANDRA-16060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16060
> Project: Cassandra
> Issue Type: Bug
>Reporter: Thomas De Keulenaer
>Priority: Normal
> Attachments: cassandra.yaml
>
>
> Out Cassandra instance has run perfectly for almost 5 years, but aout a month
> ago, the performance has dropped significantly. Reads are incredibly slow or
> time out, making the cluster almost useless. The load on the nodes has
> skyrocketed to almost 100% CPU usage. On top of that, the nodes crash with
> OutOfMemoryError.
> I also have [heap
> dumps|https://arcelormittal-my.sharepoint.com/:f:/g/personal/sidtdke_sidmar_be/Es7PaQq15jdKgIvDfMFfBRoBR6sr60t156AxbA0dFZvzJg?e=rohgHn].
>
> Cassandra version: 3.11.1
> Java version: OpenJDK 1.8.0_201
> We have upgraded our nodes to version 3.11.7 and applied the recommended
> OS/system setting, but this has not improved performance.
> {code:java}
> ERROR [ReadStage-9] 2020-08-10 14:56:01,399 JVMStabilityInspector.java:142 -
> JVM state determined to be unstable. Exiting forcefully due to:
> java.lang.OutOfMemoryError: Java heap space
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> ~[na:1.8.0_201]
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335) ~[na:1.8.0_201]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.reallocate(DataOutputBuffer.java:159)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.DataOutputBuffer.doFlush(DataOutputBuffer.java:119)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:132)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus.write(BufferedDataOutputStreamPlus.java:151)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.utils.ByteBufferUtil.writeWithVIntLength(ByteBufferUtil.java:296)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.marshal.AbstractType.writeValue(AbstractType.java:413)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.Cell$Serializer.serialize(Cell.java:210)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.lambda$serializeRowBody$0(UnfilteredSerializer.java:248)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer$$Lambda$120/205506350.accept(Unknown
> Source) ~[na:na]
> at
> org.apache.cassandra.utils.btree.BTree.applyForwards(BTree.java:1242)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.utils.btree.BTree.apply(BTree.java:1197)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at org.apache.cassandra.db.rows.BTreeRow.apply(BTreeRow.java:172)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serializeRowBody(UnfilteredSerializer.java:236)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:205)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:137)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:125)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:137)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:92)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:79)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:308)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:167)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:160)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:156)
> ~[apache-cassandra-3.11.1.j
[jira] [Updated] (CASSANDRA-16074) Add metric for client concurrent byte throttle
[ https://issues.apache.org/jira/browse/CASSANDRA-16074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16074: --- Status: Patch Available (was: Review In Progress) > Add metric for client concurrent byte throttle > -- > > Key: CASSANDRA-16074 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16074 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client, Observability/Metrics >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > > Add a metric to expose the current bytes and bytes per ip used that is used > in the existing throttle so its possible to determine what to set it to. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16074) Add metric for client concurrent byte throttle
[ https://issues.apache.org/jira/browse/CASSANDRA-16074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183932#comment-17183932 ] Michael Semb Wever commented on CASSANDRA-16074: [~clohfink], is there justification for this (new api) to go into 4.0-beta, or can it wait for 4.1? > Add metric for client concurrent byte throttle > -- > > Key: CASSANDRA-16074 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16074 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client, Observability/Metrics >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > > Add a metric to expose the current bytes and bytes per ip used that is used > in the existing throttle so its possible to determine what to set it to. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15939) Remove previously deprecated HintedHandoffManager
[
https://issues.apache.org/jira/browse/CASSANDRA-15939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-15939:
Change Category: Code Clarity
Complexity: Normal
Status: Open (was: Triage Needed)
> Remove previously deprecated HintedHandoffManager
> -
>
> Key: CASSANDRA-15939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15939
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Hints
>Reporter: Stephen Mallette
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
>
> {{HintedHandOffManager}} was deprecated about 6 years ago:
> https://github.com/apache/cassandra/commit/96d41f0e0e44d9b3114a5d80dedf12053d36a76b
> with the TODO to remove it for 4.0. While looking at CASSANDRA-15582 and
> examining the published JMX elements it seemed sensible to remove this MBean
> to help clean up a bit as it appears to just be a proxy to the
> {{HintService}} at this point.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15939) Remove previously deprecated HintedHandoffManager
[
https://issues.apache.org/jira/browse/CASSANDRA-15939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi reassigned CASSANDRA-15939:
---
Assignee: Berenguer Blasi
> Remove previously deprecated HintedHandoffManager
> -
>
> Key: CASSANDRA-15939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15939
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Hints
>Reporter: Stephen Mallette
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
>
> {{HintedHandOffManager}} was deprecated about 6 years ago:
> https://github.com/apache/cassandra/commit/96d41f0e0e44d9b3114a5d80dedf12053d36a76b
> with the TODO to remove it for 4.0. While looking at CASSANDRA-15582 and
> examining the published JMX elements it seemed sensible to remove this MBean
> to help clean up a bit as it appears to just be a proxy to the
> {{HintService}} at this point.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16072) Reduce thread contention in CommitLogSegment and HintsBuffer by rewriting CAS loops to atomic adds
[
https://issues.apache.org/jira/browse/CASSANDRA-16072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16072:
---
Reviewers: Benjamin Lerer
> Reduce thread contention in CommitLogSegment and HintsBuffer by rewriting CAS
> loops to atomic adds
> --
>
> Key: CASSANDRA-16072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16072
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Hints, Local/Commit Log
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 3.11.x, 4.0-beta
>
>
> Follow up to CASSANDRA-15922
> Both CommitLogSegment and HintsBuffer use AtomicIntegers for the current
> offset when allocating. Like in CASSANDRA\-15922 the loops on
> {{.compareAndSet(..)}} can be replaced with atomic adds using the {{.
> getAndAdd(..)}} method.
> In highly contended environments the CAS failures can be high, starving
> writes in a running Cassandra node. On the same cluster CASSANDRA\-15922 was
> found, after CASSANDRA\-15922's fix was deployed, there was still problems
> around commit log flushing and hints. No flamegraph was collected that
> demonstrated the thread contention as clearly as was found in
> CASSANDRA\-15922, but the performance fix proposed here hopefully is obvious
> enough.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16074) Add metric for client concurrent byte throttle
[ https://issues.apache.org/jira/browse/CASSANDRA-16074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16074: --- Reviewers: Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever) Michael Semb Wever, Michael Semb Wever Status: Review In Progress (was: Patch Available) > Add metric for client concurrent byte throttle > -- > > Key: CASSANDRA-16074 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16074 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client, Observability/Metrics >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Normal > > Add a metric to expose the current bytes and bytes per ip used that is used > in the existing throttle so its possible to determine what to set it to. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
