[jira] [Commented] (CASSANDRA-15214) OOMs caught and not rethrown
[ https://issues.apache.org/jira/browse/CASSANDRA-15214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17059535#comment-17059535 ] Dinesh Joshi commented on CASSANDRA-15214: -- Followed up with [~jolynch] regarding his original comment about including C JVMTI agents in C*. If we build the agent for the officially supported JVMs, we should be good. We need to detect the platform, JVM combo and load it up. If the agent is unavailable for the specific VM/Platform combination, it can be disabled with a warning in the logs much like what we do with `NativeLibrary` except this will need to happen as part of the startup script. > OOMs caught and not rethrown > > > Key: CASSANDRA-15214 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15214 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Messaging/Internode >Reporter: Benedict Elliott Smith >Priority: Normal > Fix For: 4.0, 4.0-rc > > Attachments: oom-experiments.zip > > > Netty (at least, and perhaps elsewhere in Executors) catches all exceptions, > so presently there is no way to ensure that an OOM reaches the JVM handler to > trigger a crash/heapdump. > It may be that the simplest most consistent way to do this would be to have a > single thread spawned at startup that waits for any exceptions we must > propagate to the Runtime. > We could probably submit a patch upstream to Netty, but for a guaranteed > future proof approach, it may be worth paying the cost of a single thread. -- 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-15379) Make it possible to flush with a different compression strategy than we compact with
[
https://issues.apache.org/jira/browse/CASSANDRA-15379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17059531#comment-17059531
]
Joey Lynch edited comment on CASSANDRA-15379 at 3/15/20, 2:03 AM:
--
Cool, took your changes and [rebased on trunk with a few
fixups|https://github.com/apache/cassandra/compare/trunk...jolynch:CASSANDRA-15379].
Tests are running now.
I am having some trouble with our performance integration suite for trunk right
now, but should hopefully be able to run those performance tests on Monday.
Just to confirm you would like performance numbers for a write heavy test for
baseline (trunk without my patch):
* No compressor
* LZ4 Compressor
* Zstd Compressor
And the following candidates:
* No compressor
* Noop compressor
* LZ4 compressor
* Zstd compressor
was (Author: jolynch):
Cool, took your changes and [rebased on trunk with a few
fixups|https://github.com/apache/cassandra/compare/trunk...jolynch:CASSANDRA-15379].
Tests are running now.
I am having some trouble with our performance integration suite for trunk right
now, but should hopefully be able to run those performance tests on Monday.
> Make it possible to flush with a different compression strategy than we
> compact with
>
>
> Key: CASSANDRA-15379
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15379
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction, Local/Config, Local/Memtable
>Reporter: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> [~josnyder] and I have been testing out CASSANDRA-14482 (Zstd compression) on
> some of our most dense clusters and have been observing close to 50%
> reduction in footprint with Zstd on some of our workloads! Unfortunately
> though we have been running into an issue where the flush might take so long
> (Zstd is slower to compress than LZ4) that we can actually block the next
> flush and cause instability.
> Internally we are working around this with a very simple patch which flushes
> SSTables as the default compression strategy (LZ4) regardless of the table
> params. This is a simple solution but I think the ideal solution though might
> be for the flush compression strategy to be configurable separately from the
> table compression strategy (while defaulting to the same thing). Instead of
> adding yet another compression option to the yaml (like hints and commitlog)
> I was thinking of just adding it to the table parameters and then adding a
> {{default_table_parameters}} yaml option like:
> {noformat}
> # Default table properties to apply on freshly created tables. The currently
> supported defaults are:
> # * compression : How are SSTables compressed in general (flush,
> compaction, etc ...)
> # * flush_compression : How are SSTables compressed as they flush
> # supported
> default_table_parameters:
> compression:
> class_name: 'LZ4Compressor'
> parameters:
> chunk_length_in_kb: 16
> flush_compression:
> class_name: 'LZ4Compressor'
> parameters:
> chunk_length_in_kb: 4
> {noformat}
> This would have the nice effect as well of giving our configuration a path
> forward to providing user specified defaults for table creation (so e.g. if a
> particular user wanted to use a different default chunk_length_in_kb they can
> do that).
> So the proposed (~mandatory) scope is:
> * Flush with a faster compression strategy
> I'd like to implement the following at the same time:
> * Per table flush compression configuration
> * Ability to default the table flush and compaction compression in the yaml.
--
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-15379) Make it possible to flush with a different compression strategy than we compact with
[
https://issues.apache.org/jira/browse/CASSANDRA-15379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17059531#comment-17059531
]
Joey Lynch commented on CASSANDRA-15379:
Cool, took your changes and [rebased on trunk with a few
fixups|https://github.com/apache/cassandra/compare/trunk...jolynch:CASSANDRA-15379].
Tests are running now.
I am having some trouble with our performance integration suite for trunk right
now, but should hopefully be able to run those performance tests on Monday.
> Make it possible to flush with a different compression strategy than we
> compact with
>
>
> Key: CASSANDRA-15379
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15379
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction, Local/Config, Local/Memtable
>Reporter: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> [~josnyder] and I have been testing out CASSANDRA-14482 (Zstd compression) on
> some of our most dense clusters and have been observing close to 50%
> reduction in footprint with Zstd on some of our workloads! Unfortunately
> though we have been running into an issue where the flush might take so long
> (Zstd is slower to compress than LZ4) that we can actually block the next
> flush and cause instability.
> Internally we are working around this with a very simple patch which flushes
> SSTables as the default compression strategy (LZ4) regardless of the table
> params. This is a simple solution but I think the ideal solution though might
> be for the flush compression strategy to be configurable separately from the
> table compression strategy (while defaulting to the same thing). Instead of
> adding yet another compression option to the yaml (like hints and commitlog)
> I was thinking of just adding it to the table parameters and then adding a
> {{default_table_parameters}} yaml option like:
> {noformat}
> # Default table properties to apply on freshly created tables. The currently
> supported defaults are:
> # * compression : How are SSTables compressed in general (flush,
> compaction, etc ...)
> # * flush_compression : How are SSTables compressed as they flush
> # supported
> default_table_parameters:
> compression:
> class_name: 'LZ4Compressor'
> parameters:
> chunk_length_in_kb: 16
> flush_compression:
> class_name: 'LZ4Compressor'
> parameters:
> chunk_length_in_kb: 4
> {noformat}
> This would have the nice effect as well of giving our configuration a path
> forward to providing user specified defaults for table creation (so e.g. if a
> particular user wanted to use a different default chunk_length_in_kb they can
> do that).
> So the proposed (~mandatory) scope is:
> * Flush with a faster compression strategy
> I'd like to implement the following at the same time:
> * Per table flush compression configuration
> * Ability to default the table flush and compaction compression in the yaml.
--
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-15643) Follow up on CASSANDRA-15616
[
https://issues.apache.org/jira/browse/CASSANDRA-15643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15643:
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Component/s: Feature/Virtual Tables
Discovered By: User Report
Severity: Normal
Assignee: Ekaterina Dimitrova
Status: Open (was: Triage Needed)
> Follow up on CASSANDRA-15616
> -
>
> Key: CASSANDRA-15643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15643
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> Add {{java.rmi.server.randomID}} to the systems_table
> System.getProperty("java.home")
> to be switched to
> System.getenv("JAVA_HOME")
>
> Oracle JVM might use the JRE which do not contain jmap.
--
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] [Created] (CASSANDRA-15643) Follow up on CASSANDRA-15616
Ekaterina Dimitrova created CASSANDRA-15643:
---
Summary: Follow up on CASSANDRA-15616
Key: CASSANDRA-15643
URL: https://issues.apache.org/jira/browse/CASSANDRA-15643
Project: Cassandra
Issue Type: Bug
Reporter: Ekaterina Dimitrova
Add {{java.rmi.server.randomID}} to the systems_table
System.getProperty("java.home")
to be switched to
System.getenv("JAVA_HOME")
Oracle JVM might use the JRE which do not contain jmap.
--
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-15605) Broken dtest replication_test.py::TestSnitchConfigurationUpdate
[
https://issues.apache.org/jira/browse/CASSANDRA-15605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15605:
---
Since Version: 0.3
Source Control Link:
https://github.com/apache/cassandra-dtest/commit/981ac73a6174208adb3ec8de467e8558db9f0184
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as 981ac73a6174208adb3ec8de467e8558db9f0184
> Broken dtest replication_test.py::TestSnitchConfigurationUpdate
> ---
>
> Key: CASSANDRA-15605
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15605
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Sam Tunnicliffe
>Assignee: Ryan Svihla
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Noticed this failing on a couple of CI runs and repros when running trunk
> locally and on CircleCI
> 2 or 3 tests are consistently failing:
> * {{test_rf_expand_gossiping_property_file_snitch}}
> * {{test_rf_expand_property_file_snitch}}
> * {{test_move_forwards_between_and_cleanup}}
> [https://circleci.com/workflow-run/f23f13a9-bbdc-4764-8336-109517e137f1]
--
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-dtest] branch master updated: fixed flakey tests in replication_tests.py (CASSANDRA-15605)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git
The following commit(s) were added to refs/heads/master by this push:
new 981ac73 fixed flakey tests in replication_tests.py (CASSANDRA-15605)
981ac73 is described below
commit 981ac73a6174208adb3ec8de467e8558db9f0184
Author: Ryan Svihla <43972+rssvi...@users.noreply.github.com>
AuthorDate: Wed Mar 11 17:11:55 2020 +
fixed flakey tests in replication_tests.py (CASSANDRA-15605)
---
replication_test.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/replication_test.py b/replication_test.py
index 69287d6..8943961 100644
--- a/replication_test.py
+++ b/replication_test.py
@@ -348,7 +348,7 @@ class TestSnitchConfigurationUpdate(Tester):
m = regex.match(line)
if m:
racks.append(m.group(1))
-
+racks.sort() #order is not deterministic
if racks == expected_racks:
# great, the topology change is propagated
logger.debug("Topology change detected on node
{}".format(i))
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15605) Broken dtest replication_test.py::TestSnitchConfigurationUpdate
[
https://issues.apache.org/jira/browse/CASSANDRA-15605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15605:
---
Status: Ready to Commit (was: Review In Progress)
> Broken dtest replication_test.py::TestSnitchConfigurationUpdate
> ---
>
> Key: CASSANDRA-15605
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15605
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Sam Tunnicliffe
>Assignee: Ryan Svihla
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Noticed this failing on a couple of CI runs and repros when running trunk
> locally and on CircleCI
> 2 or 3 tests are consistently failing:
> * {{test_rf_expand_gossiping_property_file_snitch}}
> * {{test_rf_expand_property_file_snitch}}
> * {{test_move_forwards_between_and_cleanup}}
> [https://circleci.com/workflow-run/f23f13a9-bbdc-4764-8336-109517e137f1]
--
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
