[jira] [Updated] (CASSANDRA-15766) NoSpamLogger arguments building objects on hot paths
[ https://issues.apache.org/jira/browse/CASSANDRA-15766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-15766: Test and Documentation Plan: Just passing utests and dtests, assuming reviewed performance improvements are non-controversial. Shouldn't be any impact on documentation. Status: Patch Available (was: In Progress) Finished a first draft that stays pretty close to the original scope/description. I've left inline comments in the PR to clarify the reasoning behind some decisions. [patch|https://github.com/apache/cassandra/pull/685], [Java 8 CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/63/workflows/aea6888d-a6fd-42d0-9efe-81b15420d96a], [Java 11 CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/63/workflows/c820bade-6073-4f36-b2fb-6abac7dd2532] > NoSpamLogger arguments building objects on hot paths > > > Key: CASSANDRA-15766 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15766 > Project: Cassandra > Issue Type: Bug > Components: Observability/Logging >Reporter: Jon Meredith >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > NoSpamLogger is used in hot logging paths to prevent logs being overrun. For > that to be most effective the arguments to the logger need to be cheap to > construct. During the internode messaging refactor CASSANDRA-15066, > performance changes to BufferPool for CASSANDRA-14416 > were accidentally reverted in the merge up from 3.11. > Reviewing other uses since, it looks like there are a few places where the > arguments require some form of String building. > org.apache.cassandra.net.InboundSink#accept > org.apache.cassandra.net.InboundMessageHandler#processCorruptFrame > org.apache.cassandra.net.InboundMessageHandler.LargeMessage#deserialize > org.apache.cassandra.net.OutboundConnection#onOverloaded > org.apache.cassandra.utils.memory.BufferPool.GlobalPool#allocateMoreChunks > Formatting arguments should either be precomputed, or if expensive they > should be computed after the decision on whether to noSpamLog has been made. -- 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] [Issue Comment Deleted] (CASSANDRA-15766) NoSpamLogger arguments building objects on hot paths
[ https://issues.apache.org/jira/browse/CASSANDRA-15766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-15766: Comment: was deleted (was: Did some preliminary work on this [here|https://github.com/maedhroz/cassandra/commit/659882f9f75eac5d019e1d935e7c18fa230f5e5a].) > NoSpamLogger arguments building objects on hot paths > > > Key: CASSANDRA-15766 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15766 > Project: Cassandra > Issue Type: Bug > Components: Observability/Logging >Reporter: Jon Meredith >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0-beta > > > NoSpamLogger is used in hot logging paths to prevent logs being overrun. For > that to be most effective the arguments to the logger need to be cheap to > construct. During the internode messaging refactor CASSANDRA-15066, > performance changes to BufferPool for CASSANDRA-14416 > were accidentally reverted in the merge up from 3.11. > Reviewing other uses since, it looks like there are a few places where the > arguments require some form of String building. > org.apache.cassandra.net.InboundSink#accept > org.apache.cassandra.net.InboundMessageHandler#processCorruptFrame > org.apache.cassandra.net.InboundMessageHandler.LargeMessage#deserialize > org.apache.cassandra.net.OutboundConnection#onOverloaded > org.apache.cassandra.utils.memory.BufferPool.GlobalPool#allocateMoreChunks > Formatting arguments should either be precomputed, or if expensive they > should be computed after the decision on whether to noSpamLog has been made. -- 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-15191) stop_paranoid disk failure policy is ignored on CorruptSSTableException after node is up
[ https://issues.apache.org/jira/browse/CASSANDRA-15191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160294#comment-17160294 ] David Capwell commented on CASSANDRA-15191: --- Took a stab at review and left a few comments in the PR. > stop_paranoid disk failure policy is ignored on CorruptSSTableException after > node is up > > > Key: CASSANDRA-15191 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15191 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Vincent White >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.7, 4.0-beta1 > > Attachments: log.txt > > Time Spent: 0.5h > Remaining Estimate: 0h > > There is a bug when disk_failure_policy is set to stop_paranoid and > CorruptSSTableException is thrown after server is up. The problem is that > this setting is ignored. Normally, it should stop gossip and transport but it > just continues to serve requests and an exception is just logged. > > This patch unifies the exception handling in JVMStabilityInspector and code > is reworked in such way that this inspector acts as a central place where > such exceptions are inspected. > > The core reason for ignoring that exception is that thrown exception in > AbstractLocalAwareExecturorService is not CorruptSSTableException but it is > RuntimeException and that exception is as its cause. Hence it is better if we > handle this in JVMStabilityInspector which can recursively examine it, hence > act accordingly. > Behaviour before: > stop_paranoid of disk_failure_policy is ignored when CorruptSSTableException > is thrown, e.g. on a regular select statement > Behaviour after: > Gossip and transport (cql) is turned off, JVM is still up for further > investigation e.g. by jmx. -- 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-15191) stop_paranoid disk failure policy is ignored on CorruptSSTableException after node is up
[ https://issues.apache.org/jira/browse/CASSANDRA-15191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15191: -- Test and Documentation Plan: jvm dtest Status: Patch Available (was: Open) > stop_paranoid disk failure policy is ignored on CorruptSSTableException after > node is up > > > Key: CASSANDRA-15191 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15191 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Vincent White >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.7, 4.0-beta1 > > Attachments: log.txt > > Time Spent: 20m > Remaining Estimate: 0h > > There is a bug when disk_failure_policy is set to stop_paranoid and > CorruptSSTableException is thrown after server is up. The problem is that > this setting is ignored. Normally, it should stop gossip and transport but it > just continues to serve requests and an exception is just logged. > > This patch unifies the exception handling in JVMStabilityInspector and code > is reworked in such way that this inspector acts as a central place where > such exceptions are inspected. > > The core reason for ignoring that exception is that thrown exception in > AbstractLocalAwareExecturorService is not CorruptSSTableException but it is > RuntimeException and that exception is as its cause. Hence it is better if we > handle this in JVMStabilityInspector which can recursively examine it, hence > act accordingly. > Behaviour before: > stop_paranoid of disk_failure_policy is ignored when CorruptSSTableException > is thrown, e.g. on a regular select statement > Behaviour after: > Gossip and transport (cql) is turned off, JVM is still up for further > investigation e.g. by jmx. -- 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-15945) Verify expected SSTable components are present at startup
[ https://issues.apache.org/jira/browse/CASSANDRA-15945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15945: -- Reviewers: David Capwell, David Capwell (was: David Capwell) David Capwell, David Capwell Status: Review In Progress (was: Patch Available) Did a first pass and mostly LGTM, left a comment in the PR about the tests. > Verify expected SSTable components are present at startup > - > > Key: CASSANDRA-15945 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15945 > Project: Cassandra > Issue Type: Bug > Components: Local/SSTable >Reporter: Yifan Cai >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.0 > > Time Spent: 40m > Remaining Estimate: 0h > > When Cassandra batch opens all sstables at startup, it should check that all > components listed in the TOC.txt are available. Compression is optional, so > there may not be a Compression.db component for all sstables, but if there > should be and it's missing we continue to load the sstable. The sstable is > unreadable without the compression metadata though, but we won't know this > until it's touched by a query or compaction. > To reliably use TOC.txt for verification, it needs CASSANDRA-10709 -- 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-15959) org.apache.cassandra.cql3.validation.operations.TTLTest testCapWarnExpirationOverflowPolicy
[ https://issues.apache.org/jira/browse/CASSANDRA-15959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15959: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Discovered By: Unit Test Fix Version/s: 4.0-beta Severity: Normal Status: Open (was: Triage Needed) > org.apache.cassandra.cql3.validation.operations.TTLTest > testCapWarnExpirationOverflowPolicy > --- > > Key: CASSANDRA-15959 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15959 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: David Capwell >Priority: Normal > Fix For: 4.0-beta > > > Build: > https://ci-cassandra.apache.org/job/Cassandra-trunk-test/194/testReport/junit/org.apache.cassandra.cql3.validation.operations/TTLTest/testCapWarnExpirationOverflowPolicy/ > junit.framework.AssertionFailedError > at > org.apache.cassandra.cql3.validation.operations.TTLTest.checkTTLIsCapped(TTLTest.java:321) > at > org.apache.cassandra.cql3.validation.operations.TTLTest.verifyData(TTLTest.java:303) > at > org.apache.cassandra.cql3.validation.operations.TTLTest.testCapExpirationDateOverflowPolicy(TTLTest.java:248) > at > org.apache.cassandra.cql3.validation.operations.TTLTest.testCapExpirationDateOverflowPolicy(TTLTest.java:199) > at > org.apache.cassandra.cql3.validation.operations.TTLTest.testCapWarnExpirationOverflowPolicy(TTLTest.java:140) -- 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-15959) org.apache.cassandra.cql3.validation.operations.TTLTest testCapWarnExpirationOverflowPolicy
David Capwell created CASSANDRA-15959: - Summary: org.apache.cassandra.cql3.validation.operations.TTLTest testCapWarnExpirationOverflowPolicy Key: CASSANDRA-15959 URL: https://issues.apache.org/jira/browse/CASSANDRA-15959 Project: Cassandra Issue Type: Bug Components: Test/unit Reporter: David Capwell Build: https://ci-cassandra.apache.org/job/Cassandra-trunk-test/194/testReport/junit/org.apache.cassandra.cql3.validation.operations/TTLTest/testCapWarnExpirationOverflowPolicy/ junit.framework.AssertionFailedError at org.apache.cassandra.cql3.validation.operations.TTLTest.checkTTLIsCapped(TTLTest.java:321) at org.apache.cassandra.cql3.validation.operations.TTLTest.verifyData(TTLTest.java:303) at org.apache.cassandra.cql3.validation.operations.TTLTest.testCapExpirationDateOverflowPolicy(TTLTest.java:248) at org.apache.cassandra.cql3.validation.operations.TTLTest.testCapExpirationDateOverflowPolicy(TTLTest.java:199) at org.apache.cassandra.cql3.validation.operations.TTLTest.testCapWarnExpirationOverflowPolicy(TTLTest.java:140) -- 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-15958) org.apache.cassandra.net.ConnectionTest testMessagePurging
David Capwell created CASSANDRA-15958: - Summary: 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 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] [Updated] (CASSANDRA-15958) org.apache.cassandra.net.ConnectionTest testMessagePurging
[ https://issues.apache.org/jira/browse/CASSANDRA-15958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15958: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Discovered By: Unit Test Fix Version/s: 4.0-beta Severity: Normal Status: Open (was: Triage Needed) > 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 >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] [Created] (CASSANDRA-15957) org.apache.cassandra.repair.RepairJobTest testOptimizedCreateStandardSyncTasks
David Capwell created CASSANDRA-15957: - Summary: org.apache.cassandra.repair.RepairJobTest testOptimizedCreateStandardSyncTasks Key: CASSANDRA-15957 URL: https://issues.apache.org/jira/browse/CASSANDRA-15957 Project: Cassandra Issue Type: Bug Reporter: David Capwell Build: https://ci-cassandra.apache.org/job/Cassandra-trunk-test/lastCompletedBuild/testReport/junit/org.apache.cassandra.repair/RepairJobTest/testOptimizedCreateStandardSyncTasks/ Expecting: <[#, #]> to contain only: <[(,0001]]> but the following elements were unexpected: <[#]> This failed 3 times in a row on Jenkins -- 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-15957) org.apache.cassandra.repair.RepairJobTest testOptimizedCreateStandardSyncTasks
[ https://issues.apache.org/jira/browse/CASSANDRA-15957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15957: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Component/s: Test/unit Discovered By: Unit Test Fix Version/s: 4.0-beta Severity: Normal Status: Open (was: Triage Needed) > org.apache.cassandra.repair.RepairJobTest testOptimizedCreateStandardSyncTasks > -- > > Key: CASSANDRA-15957 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15957 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: David Capwell >Priority: Normal > Fix For: 4.0-beta > > > Build: > https://ci-cassandra.apache.org/job/Cassandra-trunk-test/lastCompletedBuild/testReport/junit/org.apache.cassandra.repair/RepairJobTest/testOptimizedCreateStandardSyncTasks/ > Expecting: > <[#, >#]> > to contain only: > <[(,0001]]> > but the following elements were unexpected: > <[#]> > This failed 3 times in a row on Jenkins -- 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 (3ce6253 -> 972da6f)
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 3ce6253 ninja-fix: CHANGES.txt for CASSANDRA-15375 add 972da6f Prepare debian changelog for 4.0-beta1 No new revisions were added by this update. Summary of changes: debian/changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r40546 - in /dev/cassandra/4.0-beta1/redhat: ./ repodata/
Author: mck Date: Fri Jul 17 23:15:11 2020 New Revision: 40546 Log: staging cassandra rpm packages for 4.0-beta1 Added: dev/cassandra/4.0-beta1/redhat/ dev/cassandra/4.0-beta1/redhat/cassandra-4.0~beta1-1.noarch.rpm (with props) dev/cassandra/4.0-beta1/redhat/cassandra-4.0~beta1-1.src.rpm (with props) dev/cassandra/4.0-beta1/redhat/cassandra-tools-4.0~beta1-1.noarch.rpm (with props) dev/cassandra/4.0-beta1/redhat/repodata/ dev/cassandra/4.0-beta1/redhat/repodata/2fb585774d2ce580709f47cd391c0142a4f366d47939d80c67dc3992d9f7bb12-filelists.sqlite.bz2 (with props) dev/cassandra/4.0-beta1/redhat/repodata/2fb585774d2ce580709f47cd391c0142a4f366d47939d80c67dc3992d9f7bb12-filelists.sqlite.bz2.asc dev/cassandra/4.0-beta1/redhat/repodata/3a378e93e8b900341cc905b4c417f0a14f33ebc256f6f6e664deb9139b53ced5-other.xml.gz (with props) dev/cassandra/4.0-beta1/redhat/repodata/3a378e93e8b900341cc905b4c417f0a14f33ebc256f6f6e664deb9139b53ced5-other.xml.gz.asc dev/cassandra/4.0-beta1/redhat/repodata/3c7af2ddff6918bba05dff89b246bdaaecb536d0ce8c5121eb0e13512f8a7965-primary.sqlite.bz2 (with props) dev/cassandra/4.0-beta1/redhat/repodata/3c7af2ddff6918bba05dff89b246bdaaecb536d0ce8c5121eb0e13512f8a7965-primary.sqlite.bz2.asc dev/cassandra/4.0-beta1/redhat/repodata/5f71ab536006126df62e53d3361725d1d232725c796a857277f3064c84024aeb-filelists.xml.gz (with props) dev/cassandra/4.0-beta1/redhat/repodata/5f71ab536006126df62e53d3361725d1d232725c796a857277f3064c84024aeb-filelists.xml.gz.asc dev/cassandra/4.0-beta1/redhat/repodata/656929e8a169e28b3151759369684200b93797334b475eaf7b76f25dfbe743be-other.sqlite.bz2 (with props) dev/cassandra/4.0-beta1/redhat/repodata/656929e8a169e28b3151759369684200b93797334b475eaf7b76f25dfbe743be-other.sqlite.bz2.asc dev/cassandra/4.0-beta1/redhat/repodata/8c1de63179f47e1aee070ed63c2c1655bcfaa4433a20d15422bbc07aa9749662-primary.xml.gz (with props) dev/cassandra/4.0-beta1/redhat/repodata/8c1de63179f47e1aee070ed63c2c1655bcfaa4433a20d15422bbc07aa9749662-primary.xml.gz.asc dev/cassandra/4.0-beta1/redhat/repodata/repomd.xml dev/cassandra/4.0-beta1/redhat/repodata/repomd.xml.asc Added: dev/cassandra/4.0-beta1/redhat/cassandra-4.0~beta1-1.noarch.rpm == Binary file - no diff available. Propchange: dev/cassandra/4.0-beta1/redhat/cassandra-4.0~beta1-1.noarch.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-beta1/redhat/cassandra-4.0~beta1-1.src.rpm == Binary file - no diff available. Propchange: dev/cassandra/4.0-beta1/redhat/cassandra-4.0~beta1-1.src.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-beta1/redhat/cassandra-tools-4.0~beta1-1.noarch.rpm == Binary file - no diff available. Propchange: dev/cassandra/4.0-beta1/redhat/cassandra-tools-4.0~beta1-1.noarch.rpm -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-beta1/redhat/repodata/2fb585774d2ce580709f47cd391c0142a4f366d47939d80c67dc3992d9f7bb12-filelists.sqlite.bz2 == Binary file - no diff available. Propchange: dev/cassandra/4.0-beta1/redhat/repodata/2fb585774d2ce580709f47cd391c0142a4f366d47939d80c67dc3992d9f7bb12-filelists.sqlite.bz2 -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-beta1/redhat/repodata/2fb585774d2ce580709f47cd391c0142a4f366d47939d80c67dc3992d9f7bb12-filelists.sqlite.bz2.asc == --- dev/cassandra/4.0-beta1/redhat/repodata/2fb585774d2ce580709f47cd391c0142a4f366d47939d80c67dc3992d9f7bb12-filelists.sqlite.bz2.asc (added) +++ dev/cassandra/4.0-beta1/redhat/repodata/2fb585774d2ce580709f47cd391c0142a4f366d47939d80c67dc3992d9f7bb12-filelists.sqlite.bz2.asc Fri Jul 17 23:15:11 2020 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAl8SMFkACgkQ6RM1134+ +h8sh7BAAjJH6o+zEmlVr5TSypTpRcWsUv8UJZQp7To3m5DwcdDvEd6cLDbp5Zc14 +SmIg4fMQXD8N0YvE+S0r5RjBfoQgvsq59BjFa4lQGSjgyCvf/cJC5eNfeJr0q2lt +T3TmTJT1POGoL28+q9Gn+0+3/Trk6JKpG5kau18dxkQgBs9pSTqhxiYGdZsqHfuy +Z+jjusAQ6C08ZPdKJQN379dauWCxVraewckv84bPakJuDXWPpR+fgGoUBUgkkO/5 +3zdDnVLTMinc0/NIDOejC2776xDq2U2YCrgWBT4v7aKd+A6016N/WYqOpPhbyTy4 +UGxrubcTXDqtc3EreIOy4SKPw3QX1n4JyXH+srxCW6hd8miOWc5isIo/lp2BS/3Z +0maQYw68fkH5cFuTbbWvtTKwK0//6RZ40B9uCI9KOiqxHU8jgyrxEYWszMTOY3jE
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160264#comment-17160264
]
David Capwell commented on CASSANDRA-15234:
---
Thanks [~maedhroz] and [~benedict] for the YAML examples; it would be great to
start this dialog on user@ to get peoples feedback.
bq. I personally would like to propose we also introduce a dual system for
updating properties, wherein we can accept the nested namespace versions, as
well as e.g. dot-delimited versions. e.g. disk.throttle.compaction: 10MiB/s.
This should mitigate any risk to simplistic tools, as well as maybe providing
us a simple route to permitting common options being given at the start of the
file, without confusing the overall approach.
So the following would be supported?
{code}
compaction_throughput_mb_per_sec: 42
disk:
throttle:
compaction: 42MiB/s
disk.throttle.compaction: 42MiB/s
{code}
I assume the semantics would require mixed to work (part of the disk.throttle
is nested, other parts are not) and wouldn't allow duplication definitions with
other versions (can only use 1 of the 3 forms, not all), so doesn't seem that
bad as that logic already exists. We walk the class to discover the previous
names, so can do the same or collect the shape while we walk.
My main concern is if this makes it more confusing for users; they may find
some docs which say the old name, some using the nested name, and others using
the flat name.
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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
svn commit: r40545 - in /dev/cassandra/4.0-beta1/debian: ./ dists/ dists/40x/ dists/40x/main/ dists/40x/main/binary-amd64/ dists/40x/main/binary-i386/ dists/40x/main/source/ pool/ pool/main/ pool/main
Author: mck Date: Fri Jul 17 23:04:56 2020 New Revision: 40545 Log: staging cassandra debian packages for 4.0-beta1 Added: dev/cassandra/4.0-beta1/debian/ dev/cassandra/4.0-beta1/debian/cassandra-tools_4.0~beta1_all.deb (with props) dev/cassandra/4.0-beta1/debian/cassandra_4.0~beta1.dsc dev/cassandra/4.0-beta1/debian/cassandra_4.0~beta1.tar.gz (with props) dev/cassandra/4.0-beta1/debian/cassandra_4.0~beta1_all.deb (with props) dev/cassandra/4.0-beta1/debian/cassandra_4.0~beta1_amd64.buildinfo dev/cassandra/4.0-beta1/debian/cassandra_4.0~beta1_amd64.changes dev/cassandra/4.0-beta1/debian/dists/ dev/cassandra/4.0-beta1/debian/dists/40x/ dev/cassandra/4.0-beta1/debian/dists/40x/InRelease dev/cassandra/4.0-beta1/debian/dists/40x/Release dev/cassandra/4.0-beta1/debian/dists/40x/Release.gpg dev/cassandra/4.0-beta1/debian/dists/40x/main/ dev/cassandra/4.0-beta1/debian/dists/40x/main/binary-amd64/ dev/cassandra/4.0-beta1/debian/dists/40x/main/binary-amd64/Packages dev/cassandra/4.0-beta1/debian/dists/40x/main/binary-amd64/Packages.gz (with props) dev/cassandra/4.0-beta1/debian/dists/40x/main/binary-amd64/Release dev/cassandra/4.0-beta1/debian/dists/40x/main/binary-i386/ dev/cassandra/4.0-beta1/debian/dists/40x/main/binary-i386/Packages dev/cassandra/4.0-beta1/debian/dists/40x/main/binary-i386/Packages.gz (with props) dev/cassandra/4.0-beta1/debian/dists/40x/main/binary-i386/Release dev/cassandra/4.0-beta1/debian/dists/40x/main/source/ dev/cassandra/4.0-beta1/debian/dists/40x/main/source/Release dev/cassandra/4.0-beta1/debian/dists/40x/main/source/Sources.gz (with props) dev/cassandra/4.0-beta1/debian/pool/ dev/cassandra/4.0-beta1/debian/pool/main/ dev/cassandra/4.0-beta1/debian/pool/main/c/ dev/cassandra/4.0-beta1/debian/pool/main/c/cassandra/ dev/cassandra/4.0-beta1/debian/pool/main/c/cassandra/cassandra-tools_4.0~beta1_all.deb (with props) dev/cassandra/4.0-beta1/debian/pool/main/c/cassandra/cassandra_4.0~beta1.dsc dev/cassandra/4.0-beta1/debian/pool/main/c/cassandra/cassandra_4.0~beta1.tar.gz (with props) dev/cassandra/4.0-beta1/debian/pool/main/c/cassandra/cassandra_4.0~beta1_all.deb (with props) Added: dev/cassandra/4.0-beta1/debian/cassandra-tools_4.0~beta1_all.deb == Binary file - no diff available. Propchange: dev/cassandra/4.0-beta1/debian/cassandra-tools_4.0~beta1_all.deb -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-beta1/debian/cassandra_4.0~beta1.dsc == --- dev/cassandra/4.0-beta1/debian/cassandra_4.0~beta1.dsc (added) +++ dev/cassandra/4.0-beta1/debian/cassandra_4.0~beta1.dsc Fri Jul 17 23:04:56 2020 @@ -0,0 +1,41 @@ +-BEGIN PGP SIGNED MESSAGE- +Hash: SHA512 + +Format: 1.0 +Source: cassandra +Binary: cassandra, cassandra-tools +Architecture: all +Version: 4.0~beta1 +Maintainer: Eric Evans +Uploaders: Sylvain Lebresne +Homepage: http://cassandra.apache.org +Standards-Version: 3.8.3 +Vcs-Browser: https://gitbox.apache.org/repos/asf?p=cassandra.git +Vcs-Git: https://gitbox.apache.org/repos/asf/cassandra.git +Build-Depends: debhelper (>= 5), openjdk-8-jdk | java8-jdk, ant (>= 1.9), ant-optional (>= 1.9), dh-python, python-dev (>= 2.7), quilt, bash-completion +Package-List: + cassandra deb misc extra arch=all + cassandra-tools deb misc extra arch=all +Checksums-Sha1: + 8b5f6328a5023536f6366609e3be5c51f22c2b53 258487599 cassandra_4.0~beta1.tar.gz +Checksums-Sha256: + 2640bd18084aeea328497d595662f55e76a8475293ff4340fc3dba796b3e4d2b 258487599 cassandra_4.0~beta1.tar.gz +Files: + 56c2e12a1b57a3eeedd4ffed83aa82f3 258487599 cassandra_4.0~beta1.tar.gz + +-BEGIN PGP SIGNATURE- + +iQIzBAEBCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAl8SIs4ACgkQ6RM1134+ +h8uzEw//eJ48jPQ58W4y1e6UlVb3kHHObWTh9Hd7wO0a9qhydDUkG41eWytNS1Kz +zy6pW7hY8A0HgSUDQ88dGg6VETyFDz4kBXtXOmhGxmGSs8bB0s0YuHCTJ1dNTduT +ll5DIcdaTmlraoO6Bt0L/3UBJDt3G5KTB0v/ygGgK59gXH3NqzQmozMAOAltuM0P +9Io+dqqX6CUSRQyEl8d1IgeaQ0xsUTrCV9XUTetcnd1pXw0XVZQUFwKeyhDt3rQZ +me1ltPM/VLVEcXZYICiO/31EvIVf/v/Wbgm6PhA5eZBeU4v2AuWNI/V6xof0kdyV +tnVuoTdp9aUPCJ3FeFte0bCWbLKabLvb/OcQP88lL1UUm4htpURJOHsp6RBc9j25 +kdubtyFpXrKhPOuYvkGJakdrh1mHuV33/CipwFVDKpAU/p3INfbQx8dGAduUNnVP +ps1apu6j2COYrR/z3WHiA+CxzI1KwpDioEbtqfnXtXeTmHVfscHxNrh7PoeUmVnW +jWG9xRnDI/vvRZ/91BeRktCfIsxFp/9nrVaVI5IXI2TkdsOlyZG3IjTMJQ3HR0fh +0QumS+Ui0dnt4VRWf+lPLjR35QElREtcn5lvGN20jhhPwOpyOkr+YCjMeubgeBzm +0cuWUkAaO7V0Ss3nLzMnLfUqqZb/oJV/hZV2nfaKtumcSOfOcCE= +=LIeR +-END PGP SIGNATURE- Added: dev/cassandra/4.0-beta1/debian/cassandra_4.0~beta1.tar.gz == Binary file - no diff available. Propchange:
[jira] [Commented] (CASSANDRA-15876) Accessors for SystemProperties
[ https://issues.apache.org/jira/browse/CASSANDRA-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160248#comment-17160248 ] David Capwell commented on CASSANDRA-15876: --- * https://github.com/ekaterinadimitrova2/cassandra/commit/e05a927fb6787dbf887dd827b07dd02dc5d09e04#diff-28d0b1faa6709eb626f8a04f5e50e18fR28 extra space added, maybe remove? * https://github.com/ekaterinadimitrova2/cassandra/commit/e05a927fb6787dbf887dd827b07dd02dc5d09e04#diff-28d0b1faa6709eb626f8a04f5e50e18fR31 Should use immutable sets rather than mutable sets if you expose as being public. * Should rename https://github.com/ekaterinadimitrova2/cassandra/commit/e05a927fb6787dbf887dd827b07dd02dc5d09e04#diff-28d0b1faa6709eb626f8a04f5e50e18fR76 so its clear its from env and not system property. Env may be different than system property, and the system property matches the actual JVM. Since the code using it used JAVA_HOME I am fine with this method, but would be best to rename so its clear. * Javadocs normally have the description before the annotations, can you double check that the generated java docs worked correctly for SysPropertiesConfig? * https://github.com/ekaterinadimitrova2/cassandra/commit/e05a927fb6787dbf887dd827b07dd02dc5d09e04#diff-28d0b1faa6709eb626f8a04f5e50e18fR215 JMX properties should be prefixed with JMX I think, so its clear what access file its for * https://github.com/ekaterinadimitrova2/cassandra/commit/e05a927fb6787dbf887dd827b07dd02dc5d09e04#diff-28d0b1faa6709eb626f8a04f5e50e18fR248 Can you rename the mx4j properties to say mx4j in the method name? saddress isn't clear * https://github.com/ekaterinadimitrova2/cassandra/commit/e05a927fb6787dbf887dd827b07dd02dc5d09e04#r40555216 Agree that it would be better to rewrite so we don't duplicate. If we used a enum then we remove the listing and duplication issue. Overall I am +1 for this patch; all my comments are small. > 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-15876) Accessors for SystemProperties
[ https://issues.apache.org/jira/browse/CASSANDRA-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15876: -- Reviewers: David Capwell, Michael Semb Wever (was: Michael Semb Wever) > 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
svn commit: r40544 - /dev/cassandra/4.0-beta1/
Author: mck Date: Fri Jul 17 22:10:15 2020 New Revision: 40544 Log: staging cassandra 4.0-beta1 Added: dev/cassandra/4.0-beta1/ dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-bin.tar.gz (with props) dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-bin.tar.gz.asc dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-bin.tar.gz.sha256 dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-bin.tar.gz.sha512 dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-src.tar.gz (with props) dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-src.tar.gz.asc dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-src.tar.gz.sha256 dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-src.tar.gz.sha512 Added: dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-bin.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-bin.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-bin.tar.gz.asc == --- dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-bin.tar.gz.asc (added) +++ dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-bin.tar.gz.asc Fri Jul 17 22:10:15 2020 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIyBAABCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAl8SGGYACgkQ6RM1134+ +h8tbDw/41rSEet+VaWtbuQTDHCA7krHhL/PbJskuq8Rw7c468YtZjRtfhnYMPNKG +Hn7eiRTY3nWw7TuNWcuCUWceuCE1as0BtFvO+hvEo/9NE2Viur2UOuahOA08h/mb +EafFmzUpH+uwNFs46xhygBLs0Xw/r9Rd2lt1hfcRZ12VL16wb35quR3T7/u4niW5 +DsBqrtMW9QHaUk87Q7BZdoAwxr1WxutjTLMWZdGRuegfjlbNErwb63sXOVAzurZG +9FyxbfCdH508gCivLcYIbhKTLawC1AzJcD0XWAvAncpoTwvAWnjXPtFKkva4yXLf +jEZ3nb3G8Sn5WV7YpATKkhSspl4CCKgjbjQM02qrUzMfcqFHjqg4MDLIeKfN10i3 +g3bhqgALV2gXYrA5R55SjEGCIfHF3AE/eNKPu3ETWj5cwa3H6iI2Uszrn02nRKiZ +Ff5Z267fS9enKMGGhBlhAvpzkYuvf8Fjbv4UyxTiG0F8lwcR7KA6XQ7Y7H/mcWm1 +vH5B9Ga8ieSr5C9APts3EqcLgmoI9JTKHkfj2oTorWtT1vbYmEAT9uIhM8/+sAOC ++nl0PLQM0AJFI9u1qm82vYEnKDTTs2ka5j47MLhkeVZNSSve37Z4Q8An4t5olPCR +03hVC8LQNk5E2y6VpDzgnx3FhBrMpC7MKdzCpvsOISWWZjjHqg== +=Uvpt +-END PGP SIGNATURE- Added: dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-bin.tar.gz.sha256 == --- dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-bin.tar.gz.sha256 (added) +++ dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-bin.tar.gz.sha256 Fri Jul 17 22:10:15 2020 @@ -0,0 +1 @@ +a4183f91e0e2dca2a72420d8d927477310b44fe9ea25bc0e1bbf1cfa9447b8d2 Added: dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-bin.tar.gz.sha512 == --- dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-bin.tar.gz.sha512 (added) +++ dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-bin.tar.gz.sha512 Fri Jul 17 22:10:15 2020 @@ -0,0 +1 @@ +240ae95f78de172333eee865f01b838433845fbd0dceea0eb91ea3a419873f74c5e266cfb62553fa0260849afa7ec5cc65335d037d1455e36b96ddc0f18effc7 Added: dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-src.tar.gz == Binary file - no diff available. Propchange: dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-src.tar.gz -- svn:mime-type = application/octet-stream Added: dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-src.tar.gz.asc == --- dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-src.tar.gz.asc (added) +++ dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-src.tar.gz.asc Fri Jul 17 22:10:15 2020 @@ -0,0 +1,16 @@ +-BEGIN PGP SIGNATURE- + +iQIzBAABCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAl8SGGgACgkQ6RM1134+ +h8vkmw//Val4IGeGq+edlGUCwh8wfpHLsbHW9NAswYG3X5ay3g8V554VJtRFm/Lu +Yg+jVLuxmh/n87cVI6JShMfLMoL5LraFfqgLSIDqk0RbCof4DHD6phmCc1VcS9kv +64smAtSKwSUpKAeNjwZawpFc32DEBT9eCIYSSqP4bvWu5Fh8M9V4S9TNd2FBKLgK +oLuM6i0tEm0YymyGpLTpk3QF001kSB4WwAzBuP6yF0ymvazXA2nAgpvEpDhgLG5S +yzEIGlUW8joqHjtLg3mSCg5B+3IeJqkYzzoxVDU4xzKwZvli1riXncXnnJusmfh2 +DQNexAKvlnK/xbGN7fJp3GEhidYUBtE1+l5xavXMkQZWTlHYFZ5Naw3+Ck03Qwbz +8CpfEKADqhUwxxYIvA7hKuYc9hhRjx0VarZdAU3CehjXOrtRn+zsV07BIjxMVJ+B +aNr3A0SU9sAg3Aun9fqrKqL55o2fdANQUvHd3KDDH+iRypzcdWG3iLt1KAv60VIu +oO9SuQt2XI6ppqit4PNZCG/dkxxxRIJ36XGGO0PR/M572iY82Gvr7/ZBpyA94a9D +tDK2sl++gHmQVPMKFOEVmYHwkd336NEDrcWILqEzk4MnL2xmoXRP0n9/VKHSNKJU +zbihbPYBZKxR/TYXrm93Kfy4Rsi2GmqKZmMMKEwQF/73JuRqq8Y= +=RRrL +-END PGP SIGNATURE- Added: dev/cassandra/4.0-beta1/apache-cassandra-4.0-beta1-src.tar.gz.sha256 == ---
[jira] [Commented] (CASSANDRA-15766) NoSpamLogger arguments building objects on hot paths
[ https://issues.apache.org/jira/browse/CASSANDRA-15766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160224#comment-17160224 ] Caleb Rackliffe commented on CASSANDRA-15766: - Did some preliminary work on this [here|https://github.com/maedhroz/cassandra/commit/659882f9f75eac5d019e1d935e7c18fa230f5e5a]. > NoSpamLogger arguments building objects on hot paths > > > Key: CASSANDRA-15766 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15766 > Project: Cassandra > Issue Type: Bug > Components: Observability/Logging >Reporter: Jon Meredith >Assignee: Caleb Rackliffe >Priority: Normal > Fix For: 4.0-beta > > > NoSpamLogger is used in hot logging paths to prevent logs being overrun. For > that to be most effective the arguments to the logger need to be cheap to > construct. During the internode messaging refactor CASSANDRA-15066, > performance changes to BufferPool for CASSANDRA-14416 > were accidentally reverted in the merge up from 3.11. > Reviewing other uses since, it looks like there are a few places where the > arguments require some form of String building. > org.apache.cassandra.net.InboundSink#accept > org.apache.cassandra.net.InboundMessageHandler#processCorruptFrame > org.apache.cassandra.net.InboundMessageHandler.LargeMessage#deserialize > org.apache.cassandra.net.OutboundConnection#onOverloaded > org.apache.cassandra.utils.memory.BufferPool.GlobalPool#allocateMoreChunks > Formatting arguments should either be precomputed, or if expensive they > should be computed after the decision on whether to noSpamLog has been made. -- 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] tag 4.0-beta1-tentative created (now 972da6f)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to tag 4.0-beta1-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git. at 972da6f (commit) This tag includes the following new commits: new 972da6f Prepare debian changelog for 4.0-beta1 The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Prepare debian changelog for 4.0-beta1
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to tag 4.0-beta1-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 972da6fcffa87b3a1684362a2bab97db853372d8 Author: Mick Semb Wever AuthorDate: Fri Jul 17 23:22:38 2020 +0200 Prepare debian changelog for 4.0-beta1 --- debian/changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 8ceafa7..6e6b571 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,7 +2,7 @@ cassandra (4.0~beta1) unstable; urgency=medium * New release - -- Mick Semb Wever Tue, 14 Jul 2020 23:40:46 +0200 + -- Mick Fri, 17 Jul 2020 23:22:24 +0200 cassandra (4.0~alpha4) unstable; urgency=medium - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: ninja-fix: CHANGES.txt for CASSANDRA-15375
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 3ce6253 ninja-fix: CHANGES.txt for CASSANDRA-15375 3ce6253 is described below commit 3ce62532c48f4b56ff77d1cbb252f7ceef2370e1 Author: Mick Semb Wever AuthorDate: Fri Jul 17 23:18:36 2020 +0200 ninja-fix: CHANGES.txt for CASSANDRA-15375 --- CHANGES.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/CHANGES.txt b/CHANGES.txt index 9f7f529..10079b3 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.0-beta1 + * Remove BackPressureStrategy (CASSANDRA-15375) * Improve messaging on indexing frozen collections (CASSANDRA-15908) * USING_G1 is incorrectly set in cassandra-env.sh if G1 is explicitly disabled with -UseG1GC (CASSANDRA-15931) * Update compaction_throughput_mb_per_sec throttle default to 64 (CASSANDRA-14902) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-15375:
---
Fix Version/s: (was: 4.0-beta)
4.0-beta1
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Benedict Elliott Smith
>Priority: Low
> Fix For: 4.0, 4.0-beta1
>
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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
svn commit: r40543 - /dev/cassandra/4.0-beta1/
Author: mck Date: Fri Jul 17 21:13:44 2020 New Revision: 40543 Log: dropping first proposed cassandra 4.0-beta1 release Removed: dev/cassandra/4.0-beta1/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] tag 4.0-beta1-tentative deleted (was 5e76771)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to tag 4.0-beta1-tentative in repository https://gitbox.apache.org/repos/asf/cassandra.git. *** WARNING: tag 4.0-beta1-tentative was deleted! *** was 5e76771 Prepare debian changelog for 4.0-beta1 The revisions that were on this tag are still contained in other references; therefore, this change does not discard any commits from the repository. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15538) 4.0 quality testing: Local Read/Write Path: Other Areas
[ https://issues.apache.org/jira/browse/CASSANDRA-15538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15538: Change Category: Quality Assurance Complexity: Normal Status: Open (was: Triage Needed) > 4.0 quality testing: Local Read/Write Path: Other Areas > --- > > Key: CASSANDRA-15538 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15538 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Josh McKenzie >Assignee: Sylvain Lebresne >Priority: Normal > Fix For: 4.0-beta > > > Reference [doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] > for context. > *Shepherd: Aleksey Yeschenko* > Testing in this area refers to the local read/write path (StorageProxy, > ColumnFamilyStore, Memtable, SSTable reading/writing, etc). We are still > finding numerous bugs and issues with the 3.0 storage engine rewrite > (CASSANDRA-8099). For 4.0 we want to ensure that we thoroughly cover the > local read/write path with techniques such as property-based testing, fuzzing > ([example|http://cassandra.apache.org/blog/2018/10/17/finding_bugs_with_property_based_testing.html]), > and a source audit. -- 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-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152248#comment-17152248
]
Caleb Rackliffe edited comment on CASSANDRA-15907 at 7/17/20, 8:44 PM:
---
[~jwest] I've hopefully addressed the points from [~adelapena]'s first round of
review, so I think this is officially ready for a second reviewer.
3.0: [patch|https://github.com/apache/cassandra/pull/659],
[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/60/workflows/37dcf29a-effb-425a-95de-2362949942c5]
WIP (avoid review ATM)
3.11: [patch|https://github.com/apache/cassandra/pull/665],
[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/38/workflows/c3a3b51b-d105-49d9-91f8-2a149cf211b6]
trunk: [patch|https://github.com/apache/cassandra/pull/666], [j8
CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/37/workflows/84e48d9e-f3dd-45ff-b70a-b69a86f6eb96]
[j11 Circle
CI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/37/workflows/79b581ab-94a1-4920-a894-7f0f91ef466b]
If we're happy with the implementation, the next step will be to do some basic
stress testing.
Note: Existing issues described by CASSANDRA-14595 (Thrift dtest) and
CASSANDRA-15881 (SASI memtable switching) are visible in the test results so
far.
was (Author: maedhroz):
[~jwest] I've hopefully addressed the points from [~adelapena]'s first round of
review, so I think this is officially ready for a second reviewer.
3.0: [patch|https://github.com/apache/cassandra/pull/659],
[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/57/workflows/b408ce8a-ee68-47bf-b9f1-eb9541e9827e]
WIP (avoid review ATM)
3.11: [patch|https://github.com/apache/cassandra/pull/665],
[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/38/workflows/c3a3b51b-d105-49d9-91f8-2a149cf211b6]
trunk: [patch|https://github.com/apache/cassandra/pull/666], [j8
CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/37/workflows/84e48d9e-f3dd-45ff-b70a-b69a86f6eb96]
[j11 Circle
CI|https://app.circleci.com/pipelines/github/maedhroz/cassandra/37/workflows/79b581ab-94a1-4920-a894-7f0f91ef466b]
If we're happy with the implementation, the next step will be to do some basic
stress testing.
Note: Existing issues described by CASSANDRA-14595 (Thrift dtest) and
CASSANDRA-15881 (SASI memtable switching) are visible in the test results so
far.
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect
[jira] [Updated] (CASSANDRA-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-15907:
Test and Documentation Plan:
The first line of defense against regression here is the set of dtests built
for CASSANDRA-8272 in {{replica_side_filtering}}. In addition to that, we'll
need at minimum a basic battery of in-JVM dtests around the new guardrails.
Once the implementation is reviewed, we'll use the \{{tlp-stress}} filtering
workload to stress things a bit, both to see how things behave with larger sets
of query results when filtering protection isn't activated, and to see how the
thresholds work when we have severely out-of-sync replicas.
In terms of documentation, we have two new {{cassandra.yaml}}
[options|https://github.com/apache/cassandra/pull/659/files?file-filters%5B%5D=.java%5B%5D=.xml%5B%5D=.yaml#diff-bdaab1104a93e723ce0b609a6477c9c4R664],
which have what should be reasonable documentation inline.
There is also a new metric in {{org.apache.cassandra.metrics}}:
{{type=Table}}
{{keyspace=}}
{{scope=}}
{{name=ReplicaFilteringProtectionRowsCachedPerPartition}}
This is a histogram of the number of rows cached per partition during queries
that activate RFP.
was:
The first line of defense against regression here is the set of dtests built
for CASSANDRA-8272 in {{replica_side_filtering}}. In addition to that, we'll
need at minimum a basic battery of in-JVM dtests around the new guardrails.
Once the implementation is reviewed, we'll use the \{{tlp-stress}} filtering
workload to stress things a bit, both to see how things behave with larger sets
of query results when filtering protection isn't activated, and to see how the
thresholds work when we have severely out-of-sync replicas.
In terms of documentation, we have two new {{cassandra.yaml}}
[options|https://github.com/apache/cassandra/pull/659/files?file-filters%5B%5D=.java%5B%5D=.xml%5B%5D=.yaml#diff-bdaab1104a93e723ce0b609a6477c9c4R664],
which have what should be reasonable documentation inline.
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves against incorrect replica
> filtering results). It's a minor fix, but would avoid confusion.
> * The method call chain in {{DataResolver}} might be a bit simpler if we put
> the {{repairedDataTracker}} in {{ResolveContext}}.
> *Testing*
> * I want to bite the bullet and get some basic tests for RFP (including any
> guardrails we might add here) onto the in-JVM dtest framework.
> *Guardrails*
> * As it
[jira] [Updated] (CASSANDRA-15940) Create better third-party page
[ https://issues.apache.org/jira/browse/CASSANDRA-15940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15940: --- Change Category: Semantic Complexity: Normal Fix Version/s: 4.0-beta Status: Open (was: Triage Needed) > Create better third-party page > -- > > Key: CASSANDRA-15940 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15940 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-beta > > > Create a better third-party page based on dev mailing list conversation. > https://lists.apache.org/thread.html/r90076db617bf8615ae03567fa089bfe0ae31f1aa63ef8e2242bd9701%40%3Cdev.cassandra.apache.org%3E -- 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-14128) Prune dead links from cassandra.apache.org
[ https://issues.apache.org/jira/browse/CASSANDRA-14128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-14128: --- Component/s: Documentation/Website > Prune dead links from cassandra.apache.org > -- > > Key: CASSANDRA-14128 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14128 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website, Legacy/Documentation and Website >Reporter: Jeff Jirsa >Assignee: Kurt Greaves >Priority: Low > Labels: lhf > Attachments: 14128-site.patch > > > Lots of dead links on the site, including the homepage. Should do some > pruning cleanup. > Site repo is [here|https://svn.apache.org/repos/asf/cassandra/site/] (in svn) > for anyone who wishes to give this a shot. -- 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-15940) Create better third-party page
[ https://issues.apache.org/jira/browse/CASSANDRA-15940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-15940: --- Labels: pull-request-available (was: ) > Create better third-party page > -- > > Key: CASSANDRA-15940 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15940 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Lorina Poland >Assignee: Lorina Poland >Priority: Normal > Labels: pull-request-available > > Create a better third-party page based on dev mailing list conversation. > https://lists.apache.org/thread.html/r90076db617bf8615ae03567fa089bfe0ae31f1aa63ef8e2242bd9701%40%3Cdev.cassandra.apache.org%3E -- 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-builds] branch master updated: ninja-fix: in cassandra-test.sh correctly detect which test targets are valid in the code
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-builds.git
The following commit(s) were added to refs/heads/master by this push:
new 84268b8 ninja-fix: in cassandra-test.sh correctly detect which test
targets are valid in the code
84268b8 is described below
commit 84268b8180fe5e7331efcc301df9c269c7b1babd
Author: mck
AuthorDate: Fri Jul 17 19:51:23 2020 +0200
ninja-fix: in cassandra-test.sh correctly detect which test targets are
valid in the code
---
build-scripts/cassandra-test.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/build-scripts/cassandra-test.sh b/build-scripts/cassandra-test.sh
index aab819f..852aede 100755
--- a/build-scripts/cassandra-test.sh
+++ b/build-scripts/cassandra-test.sh
@@ -37,8 +37,8 @@ _main() {
ant -projecthelp | grep -q " $target " || { echo "Skipping ${target}. It
does not exist in ${version}"; exit 0; }
;;
"test-cdc")
- regx_version="2.2([0-9]+)$"
- ! [[ $version =~ $version ]] || { echo "Skipping ${target}. It does not
exist in ${version}"; exit 0; }
+ regx_version="(2.2|3.0).([0-9]+)$"
+ ! [[ $version =~ $regx_version ]] || { echo "Skipping ${target}. It does
not exist in ${version}"; exit 0; }
;;
*)
;;
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-15907:
Test and Documentation Plan:
The first line of defense against regression here is the set of dtests built
for CASSANDRA-8272 in {{replica_side_filtering}}. In addition to that, we'll
need at minimum a basic battery of in-JVM dtests around the new guardrails.
Once the implementation is reviewed, we'll use the \{{tlp-stress}} filtering
workload to stress things a bit, both to see how things behave with larger sets
of query results when filtering protection isn't activated, and to see how the
thresholds work when we have severely out-of-sync replicas.
In terms of documentation, we have two new {{cassandra.yaml}}
[options|https://github.com/apache/cassandra/pull/659/files?file-filters%5B%5D=.java%5B%5D=.xml%5B%5D=.yaml#diff-bdaab1104a93e723ce0b609a6477c9c4R664],
which have what should be reasonable documentation inline.
was:
The first line of defense against regression here is the set of dtests built
for CASSANDRA-8272 in {{replica_side_filtering}}. In addition to that, we'll
need at minimum a basic battery of in-JVM dtests around the new guardrails.
Once the implementation is reviewed, we'll use the \{{tlp-stress}} filtering
workload to stress things a bit, both to see how things behave with larger sets
of query results when filtering protection isn't activated, and to see how the
thresholds work when we have severely out-of-sync replicas.
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves against incorrect replica
> filtering results). It's a minor fix, but would avoid confusion.
> * The method call chain in {{DataResolver}} might be a bit simpler if we put
> the {{repairedDataTracker}} in {{ResolveContext}}.
> *Testing*
> * I want to bite the bullet and get some basic tests for RFP (including any
> guardrails we might add here) onto the in-JVM dtest framework.
> *Guardrails*
> * As it stands, we don't have a way to enforce an upper bound on the memory
> usage of {{ReplicaFilteringProtection}} which caches row responses from the
> first round of requests. (Remember, these are later used to merged with the
> second round of results to complete the data for filtering.) Operators will
> likely need a way to protect themselves, i.e. simply fail queries if they hit
> a particular threshold rather than GC nodes into oblivion. (Having control
> over limits and page sizes doesn't quite get us there, because stale
[jira] [Commented] (CASSANDRA-15952) TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap checks non-existent log messages for 3.0 and 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-15952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160063#comment-17160063
]
Ekaterina Dimitrova commented on CASSANDRA-15952:
-
Thank you to both of you!
> TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap checks
> non-existent log messages for 3.0 and 3.11
> ---
>
> Key: CASSANDRA-15952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15952
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 3.0.22, 3.11.8
>
>
> CASSANDRA-14525 added a bit of logging only in trunk that
> {{TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap}} assumes
> is present in all versions. This should be as simple as making sure we only
> assert around that on 4.0+.
> See
> https://app.circleci.com/pipelines/github/maedhroz/cassandra/57/workflows/b408ce8a-ee68-47bf-b9f1-eb9541e9827e/jobs/312
--
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-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160052#comment-17160052
]
Andres de la Peña commented on CASSANDRA-15907:
---
In case we need to explore the per-row approach in the future, I'm leaving
[here|https://github.com/adelapena/cassandra/commit/90900ec717958270bc38b501b4248dfb7d55958c]
the most extensive prototype of it, that uses two properties to control the
min cache size when we don't have conflicts yet and when we have found
conflicts.
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves against incorrect replica
> filtering results). It's a minor fix, but would avoid confusion.
> * The method call chain in {{DataResolver}} might be a bit simpler if we put
> the {{repairedDataTracker}} in {{ResolveContext}}.
> *Testing*
> * I want to bite the bullet and get some basic tests for RFP (including any
> guardrails we might add here) onto the in-JVM dtest framework.
> *Guardrails*
> * As it stands, we don't have a way to enforce an upper bound on the memory
> usage of {{ReplicaFilteringProtection}} which caches row responses from the
> first round of requests. (Remember, these are later used to merged with the
> second round of results to complete the data for filtering.) Operators will
> likely need a way to protect themselves, i.e. simply fail queries if they hit
> a particular threshold rather than GC nodes into oblivion. (Having control
> over limits and page sizes doesn't quite get us there, because stale results
> _expand_ the number of incomplete results we must cache.) The fun question is
> how we do this, with the primary axes being scope (per-query, global, etc.)
> and granularity (per-partition, per-row, per-cell, actual heap usage, etc.).
> My starting disposition on the right trade-off between
> performance/complexity and accuracy is having something along the lines of
> cached rows per query. Prior art suggests this probably makes sense alongside
> things like {{tombstone_failure_threshold}} in {{cassandra.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-15952) TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap checks non-existent log messages for 3.0 and 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-15952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15952:
-
Reviewers: Brandon Williams, Ekaterina Dimitrova (was: Ekaterina Dimitrova)
> TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap checks
> non-existent log messages for 3.0 and 3.11
> ---
>
> Key: CASSANDRA-15952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15952
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> CASSANDRA-14525 added a bit of logging only in trunk that
> {{TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap}} assumes
> is present in all versions. This should be as simple as making sure we only
> assert around that on 4.0+.
> See
> https://app.circleci.com/pipelines/github/maedhroz/cassandra/57/workflows/b408ce8a-ee68-47bf-b9f1-eb9541e9827e/jobs/312
--
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-15952) TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap checks non-existent log messages for 3.0 and 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-15952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15952:
-
Fix Version/s: (was: 3.11.x)
(was: 3.0.x)
3.11.8
3.0.22
> TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap checks
> non-existent log messages for 3.0 and 3.11
> ---
>
> Key: CASSANDRA-15952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15952
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 3.0.22, 3.11.8
>
>
> CASSANDRA-14525 added a bit of logging only in trunk that
> {{TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap}} assumes
> is present in all versions. This should be as simple as making sure we only
> assert around that on 4.0+.
> See
> https://app.circleci.com/pipelines/github/maedhroz/cassandra/57/workflows/b408ce8a-ee68-47bf-b9f1-eb9541e9827e/jobs/312
--
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-15952) TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap checks non-existent log messages for 3.0 and 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-15952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15952:
-
Since Version: 3.0.0
Source Control Link:
https://github.com/apache/cassandra-dtest/commit/94ce5797ae5892e2952fa55efd0594b1aa0e3aa8
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks.
> TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap checks
> non-existent log messages for 3.0 and 3.11
> ---
>
> Key: CASSANDRA-15952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15952
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> CASSANDRA-14525 added a bit of logging only in trunk that
> {{TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap}} assumes
> is present in all versions. This should be as simple as making sure we only
> assert around that on 4.0+.
> See
> https://app.circleci.com/pipelines/github/maedhroz/cassandra/57/workflows/b408ce8a-ee68-47bf-b9f1-eb9541e9827e/jobs/312
--
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: fix test_bootstrap_binary_disabled to avoid checking for log messages that only exist on 4.0+ when testing 3.0 and 3.11
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams 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 94ce579 fix test_bootstrap_binary_disabled to avoid checking for log
messages that only exist on 4.0+ when testing 3.0 and 3.11
94ce579 is described below
commit 94ce5797ae5892e2952fa55efd0594b1aa0e3aa8
Author: Caleb Rackliffe
AuthorDate: Thu Jul 16 14:44:13 2020 -0500
fix test_bootstrap_binary_disabled to avoid checking for log messages that
only exist on 4.0+ when testing 3.0 and 3.11
Patch by Caleb Rackliffe, reviewed by Ekaterina Dimitrova and
brandonwilliams for CASSANDRA-15952
---
bootstrap_test.py | 55 ++-
1 file changed, 50 insertions(+), 5 deletions(-)
diff --git a/bootstrap_test.py b/bootstrap_test.py
index d22599f..927468d 100644
--- a/bootstrap_test.py
+++ b/bootstrap_test.py
@@ -15,6 +15,8 @@ from ccmlib.node import TimeoutError
import pytest
+from distutils.version import LooseVersion
+
from dtest import Tester, create_ks, create_cf, data_size
from tools.assertions import (assert_almost_equal, assert_bootstrap_state,
assert_not_running,
assert_one, assert_stderr_clean)
@@ -336,6 +338,50 @@ class TestBootstrap(Tester):
assert_not_running(node3)
@since('2.2')
+def test_resumable_bootstrap(self):
+"""
+Test resuming bootstrap after data streaming failure
+"""
+cluster = self.cluster
+cluster.populate(2)
+
+node1 = cluster.nodes['node1']
+# set up byteman
+node1.byteman_port = '8100'
+node1.import_config_files()
+
+cluster.start(wait_other_notice=True)
+# kill stream to node3 in the middle of streaming to let it fail
+if cluster.version() < '4.0':
+node1.byteman_submit([self.byteman_submit_path_pre_4_0])
+else:
+node1.byteman_submit([self.byteman_submit_path_4_0])
+node1.stress(['write', 'n=1K', 'no-warmup', 'cl=TWO', '-schema',
'replication(factor=2)', '-rate', 'threads=50'])
+cluster.flush()
+
+# start bootstrapping node3 and wait for streaming
+node3 = new_node(cluster)
+node3.start(wait_other_notice=False)
+
+# let streaming fail as we expect
+node3.watch_log_for('Some data streaming failed')
+
+# bring back node3 and invoke nodetool bootstrap to resume
bootstrapping
+node3.nodetool('bootstrap resume')
+node3.wait_for_binary_interface()
+assert_bootstrap_state(self, node3, 'COMPLETED')
+
+# cleanup to guarantee each node will only have sstables of its ranges
+cluster.cleanup()
+
+logger.debug("Check data is present")
+# Let's check stream bootstrap completely transferred data
+stdout, stderr, _ = node3.stress(['read', 'n=1k', 'no-warmup',
'-schema', 'replication(factor=2)', '-rate', 'threads=8'])
+
+if stdout is not None:
+assert "FAILURE" not in stdout
+
+@since('2.2')
def test_bootstrap_with_reset_bootstrap_state(self):
"""Test bootstrap with resetting bootstrap progress"""
cluster = self.cluster
@@ -708,13 +754,10 @@ class TestBootstrap(Tester):
shutil.rmtree(commitlog_dir)
@since('2.2')
-def test_bootstrap_binary_disabled_resumable_bootstrap(self):
+def test_bootstrap_binary_disabled(self):
"""
Test binary while bootstrapping and streaming fails
@jira_ticket CASSANDRA-14526, CASSANDRA-14525
-Test resumable bootstrap
-In very rare cases this test might fail because the bootstrap
completes before the streaming failure
-@jira_ticket CASSANDRA-15614
"""
config = {'authenticator':
'org.apache.cassandra.auth.PasswordAuthenticator',
'authorizer':
'org.apache.cassandra.auth.CassandraAuthorizer',
@@ -746,7 +789,9 @@ class TestBootstrap(Tester):
node2.import_config_files()
node2.start(jvm_args=["-Dcassandra.ring_delay_ms=5000"],
wait_other_notice=True)
self.assert_log_had_msg(node2, 'Some data streaming failed')
-self.assert_log_had_msg(node2, 'Not starting client transports as
bootstrap has not completed')
+
+if self.cluster.version() >= LooseVersion('4.0'):
+self.assert_log_had_msg(node2, 'Not starting client transports as
bootstrap has not completed')
try:
node2.nodetool('join')
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160018#comment-17160018
]
Caleb Rackliffe commented on CASSANDRA-15907:
-
[~adelapena] and I had a quick Slack discussion, and I think we've landed on
the following:
1.) For now, we'll stop at a partition-based lazy first-phase iterator
consumption approach (what's in the main patch branch right now). It's not
clear that a {{min_cache_size}} (that avoid creating tons of "singleton"
{{CachedRowIterator}} instances) would produce something meaningfully different.
2.) In the interest of visibility, we'll explore adding a histogram that
quantifies just how much row caching these queries are doing. It would put some
data behind our assumptions here and might help with tuning the guardrails as
well. (I'll try to have something up for this shortly...)
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves against incorrect replica
> filtering results). It's a minor fix, but would avoid confusion.
> * The method call chain in {{DataResolver}} might be a bit simpler if we put
> the {{repairedDataTracker}} in {{ResolveContext}}.
> *Testing*
> * I want to bite the bullet and get some basic tests for RFP (including any
> guardrails we might add here) onto the in-JVM dtest framework.
> *Guardrails*
> * As it stands, we don't have a way to enforce an upper bound on the memory
> usage of {{ReplicaFilteringProtection}} which caches row responses from the
> first round of requests. (Remember, these are later used to merged with the
> second round of results to complete the data for filtering.) Operators will
> likely need a way to protect themselves, i.e. simply fail queries if they hit
> a particular threshold rather than GC nodes into oblivion. (Having control
> over limits and page sizes doesn't quite get us there, because stale results
> _expand_ the number of incomplete results we must cache.) The fun question is
> how we do this, with the primary axes being scope (per-query, global, etc.)
> and granularity (per-partition, per-row, per-cell, actual heap usage, etc.).
> My starting disposition on the right trade-off between
> performance/complexity and accuracy is having something along the lines of
> cached rows per query. Prior art suggests this probably makes sense alongside
> things like {{tombstone_failure_threshold}} in {{cassandra.yaml}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CASSANDRA-15952) TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap checks non-existent log messages for 3.0 and 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-15952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160003#comment-17160003
]
Caleb Rackliffe commented on CASSANDRA-15952:
-
[~e.dimitrova] [~brandon.williams] Nice. That looks like two clean {{dtest}}
runs to me :)
> TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap checks
> non-existent log messages for 3.0 and 3.11
> ---
>
> Key: CASSANDRA-15952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15952
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> CASSANDRA-14525 added a bit of logging only in trunk that
> {{TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap}} assumes
> is present in all versions. This should be as simple as making sure we only
> assert around that on 4.0+.
> See
> https://app.circleci.com/pipelines/github/maedhroz/cassandra/57/workflows/b408ce8a-ee68-47bf-b9f1-eb9541e9827e/jobs/312
--
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-15952) TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap checks non-existent log messages for 3.0 and 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-15952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-15952:
Status: Ready to Commit (was: Review In Progress)
> TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap checks
> non-existent log messages for 3.0 and 3.11
> ---
>
> Key: CASSANDRA-15952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15952
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> CASSANDRA-14525 added a bit of logging only in trunk that
> {{TestBootstrap::test_bootstrap_binary_disabled_resumable_bootstrap}} assumes
> is present in all versions. This should be as simple as making sure we only
> assert around that on 4.0+.
> See
> https://app.circleci.com/pipelines/github/maedhroz/cassandra/57/workflows/b408ce8a-ee68-47bf-b9f1-eb9541e9827e/jobs/312
--
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-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159989#comment-17159989
]
Benedict Elliott Smith commented on CASSANDRA-15375:
Thanks, committed with your suggestion
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Benedict Elliott Smith
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15375:
---
Since Version: 4.0-alpha4
Source Control Link:
[d8993934e976d8edb94cbfe2974688dac63c5db5|https://github.com/apache/cassandra/commit/d8993934e976d8edb94cbfe2974688dac63c5db5]
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith reassigned CASSANDRA-15375:
--
Assignee: Benedict Elliott Smith (was: Jon Haddad)
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Benedict Elliott Smith
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15375:
---
Reviewers: Robert Stupp, Sergio Bossa, Benedict Elliott Smith (was:
Benedict Elliott Smith, Robert Stupp, Sergio Bossa)
Robert Stupp, Sergio Bossa, Benedict Elliott Smith (was: Sergio
Bossa)
Status: Review In Progress (was: Patch Available)
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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 BackPressureStrategy
This is an automated email from the ASF dual-hosted git repository. benedict 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 d899393 Remove BackPressureStrategy d899393 is described below commit d8993934e976d8edb94cbfe2974688dac63c5db5 Author: Benedict Elliott Smith AuthorDate: Mon Feb 24 09:59:12 2020 + Remove BackPressureStrategy patch by Benedict; reviewed by Sergio Bossa and Robert Stupp for CASSANDRA-15375 --- conf/cassandra.yaml| 22 -- src/java/org/apache/cassandra/config/Config.java | 2 + .../cassandra/config/DatabaseDescriptor.java | 45 --- .../apache/cassandra/hints/HintsDispatcher.java| 6 - .../apache/cassandra/net/BackPressureState.java| 51 --- .../apache/cassandra/net/BackPressureStrategy.java | 44 --- .../org/apache/cassandra/net/MessagingService.java | 75 +--- .../cassandra/net/MessagingServiceMBean.java | 3 +- .../cassandra/net/MessagingServiceMBeanImpl.java | 21 +- .../apache/cassandra/net/OutboundConnections.java | 17 +- .../cassandra/net/RateBasedBackPressure.java | 297 --- .../cassandra/net/RateBasedBackPressureState.java | 130 --- .../org/apache/cassandra/net/RequestCallback.java | 5 - .../org/apache/cassandra/net/RequestCallbacks.java | 3 - .../apache/cassandra/net/ResponseVerbHandler.java | 5 - .../service/AbstractWriteResponseHandler.java | 12 - .../org/apache/cassandra/service/StorageProxy.java | 4 - .../config/DatabaseDescriptorRefTest.java | 1 - .../locator/ReconnectableSnitchHelperTest.java | 1 - .../apache/cassandra/net/MessagingServiceTest.java | 186 -- .../cassandra/net/OutboundConnectionsTest.java | 10 +- .../cassandra/net/RateBasedBackPressureTest.java | 408 - 22 files changed, 15 insertions(+), 1333 deletions(-) diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml index 4bd72cf..573c936 100644 --- a/conf/cassandra.yaml +++ b/conf/cassandra.yaml @@ -1253,28 +1253,6 @@ compaction_large_partition_warning_threshold_mb: 100 # as corrupted. This should be positive and less than 2048. # max_value_size_in_mb: 256 -# Back-pressure settings # -# If enabled, the coordinator will apply the back-pressure strategy specified below to each mutation -# sent to replicas, with the aim of reducing pressure on overloaded replicas. -back_pressure_enabled: false -# The back-pressure strategy applied. -# The default implementation, RateBasedBackPressure, takes three arguments: -# high ratio, factor, and flow type, and uses the ratio between incoming mutation responses and outgoing mutation requests. -# If below high ratio, outgoing mutations are rate limited according to the incoming rate decreased by the given factor; -# if above high ratio, the rate limiting is increased by the given factor; -# such factor is usually best configured between 1 and 10, use larger values for a faster recovery -# at the expense of potentially more dropped mutations; -# the rate limiting is applied according to the flow type: if FAST, it's rate limited at the speed of the fastest replica, -# if SLOW at the speed of the slowest one. -# New strategies can be added. Implementors need to implement org.apache.cassandra.net.BackpressureStrategy and -# provide a public constructor accepting a Map. -back_pressure_strategy: -- class_name: org.apache.cassandra.net.RateBasedBackPressure - parameters: -- high_ratio: 0.90 - factor: 5 - flow: FAST - # Coalescing Strategies # # Coalescing multiples messages turns out to significantly boost message processing throughput (think doubling or more). # On bare metal, the floor for packet processing throughput is high enough that many applications won't notice, but in diff --git a/src/java/org/apache/cassandra/config/Config.java b/src/java/org/apache/cassandra/config/Config.java index 63cfff4..c8af291 100644 --- a/src/java/org/apache/cassandra/config/Config.java +++ b/src/java/org/apache/cassandra/config/Config.java @@ -412,7 +412,9 @@ public class Config */ public UserFunctionTimeoutPolicy user_function_timeout_policy = UserFunctionTimeoutPolicy.die; +@Deprecated public volatile boolean back_pressure_enabled = false; +@Deprecated public volatile ParameterizedClass back_pressure_strategy; public volatile int concurrent_validations; diff --git a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java index 5f94710..a7559f1 100644 --- a/src/java/org/apache/cassandra/config/DatabaseDescriptor.java +++ b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java @@ -68,8 +68,6 @@ import org.apache.cassandra.locator.IEndpointSnitch; import org.apache.cassandra.locator.InetAddressAndPort; import
[jira] [Updated] (CASSANDRA-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15375:
---
Status: Ready to Commit (was: Review In Progress)
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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-13994) Remove dead compact storage code before 4.0 release
[
https://issues.apache.org/jira/browse/CASSANDRA-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159943#comment-17159943
]
Ekaterina Dimitrova commented on CASSANDRA-13994:
-
As [~slebresne] is not available, [~djoshi], [~ifesdjeen] or anyone else having
the time to make the final review so I don't have to rebase again this patch?
As agreed, I returned the indexes part and now only the dead code removal is
there.
> Remove dead compact storage code before 4.0 release
> ---
>
> Key: CASSANDRA-13994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13994
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths
>Reporter: Alex Petrov
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> 4.0 comes without thrift (after [CASSANDRA-5]) and COMPACT STORAGE (after
> [CASSANDRA-10857]), and since Compact Storage flags are now disabled, all of
> the related functionality is useless.
> There are still some things to consider:
> 1. One of the system tables (built indexes) was compact. For now, we just
> added {{value}} column to it to make sure it's backwards-compatible, but we
> might want to make sure it's just a "normal" table and doesn't have redundant
> columns.
> 2. Compact Tables were building indexes in {{KEYS}} mode. Removing it is
> trivial, but this would mean that all built indexes will be defunct. We could
> log a warning for now and ask users to migrate off those for now and
> completely remove it from future releases. It's just a couple of classes
> though.
--
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-15907) Operational Improvements & Hardening for Replica Filtering Protection
[
https://issues.apache.org/jira/browse/CASSANDRA-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159912#comment-17159912
]
Andres de la Peña commented on CASSANDRA-15907:
---
[~maedhroz] I like the changes to the lazy rows approach. However, I'm afraid
we need the snapshot of the cached rows done in [this local
copy-and-clear|https://github.com/adelapena/cassandra/blob/accf2a47c341875942b0d8b06c016cc0d66d62cb/src/java/org/apache/cassandra/service/ReplicaFilteringProtection.java#L522-L524],
otherwise the advances in the other replica can introduce new data and mess
with it, producing multiple test failures. Or, we can do much better than in my
previous patch and just track the number of contents in the snapshot and save
us the queue copy, as it's done
[here|https://github.com/adelapena/cassandra/blob/35d8e712bbbe03076ba867c11759664e8ff839e4/src/java/org/apache/cassandra/service/ReplicaFilteringProtection.java#L528-L568].
Also I think that making {{currentMergedRows}} / {{unprotectedPartition}} to
the partition iterator is not correct. It's a pointer to the current first
iteration merged partition and it should be shared by all the builders in the
RFP. If we make it local it can reduce the speed at which that pointer is
advanced, producing in the end more RFP queries.
{quote}When there is a large number of non-conflicting rows at the start of the
first-phase iterator, though, it seems like the price of avoiding row caching
is creating a large number of {{CachedRowIterator}} objects. Maybe this is the
right trade-off, but I'm not sure.
{quote}
We can find a balance between max cache size and the number of
{{CachedRowIterator}} instances if we try to grow the cache a bit further when
there are no conflicts:
{code:java}
while (unprotectedPartition != null && unprotectedPartition.hasNext()
&& (toFetch != null || cachedRows.size() < min_cache_size))
{code}
Min cache/buffer size can be a constant, or a config property, or a function of
the warning threshold, or something related the query limit. This would still
limit the size of the cache in the absence of conflicts while quickly reducing
the number of {{CachedRowIterator}} instances.
Also, given that we are concerned about the cache size, we might want to
consider tracking the max size that the cache reaches during the query, and add
it to a new table metric that tracks the average max cache size.
> Operational Improvements & Hardening for Replica Filtering Protection
> -
>
> Key: CASSANDRA-15907
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15907
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Feature/2i Index
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Labels: 2i, memory
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> CASSANDRA-8272 uses additional space on the heap to ensure correctness for 2i
> and filtering queries at consistency levels above ONE/LOCAL_ONE. There are a
> few things we should follow up on, however, to make life a bit easier for
> operators and generally de-risk usage:
> (Note: Line numbers are based on {{trunk}} as of
> {{3cfe3c9f0dcf8ca8b25ad111800a21725bf152cb}}.)
> *Minor Optimizations*
> * {{ReplicaFilteringProtection:114}} - Given we size them up-front, we may be
> able to use simple arrays instead of lists for {{rowsToFetch}} and
> {{originalPartitions}}. Alternatively (or also), we may be able to null out
> references in these two collections more aggressively. (ex. Using
> {{ArrayList#set()}} instead of {{get()}} in {{queryProtectedPartitions()}},
> assuming we pass {{toFetch}} as an argument to {{querySourceOnKey()}}.)
> * {{ReplicaFilteringProtection:323}} - We may be able to use
> {{EncodingStats.merge()}} and remove the custom {{stats()}} method.
> * {{DataResolver:111 & 228}} - Cache an instance of
> {{UnaryOperator#identity()}} instead of creating one on the fly.
> * {{ReplicaFilteringProtection:217}} - We may be able to scatter/gather
> rather than serially querying every row that needs to be completed. This
> isn't a clear win perhaps, given it targets the latency of single queries and
> adds some complexity. (Certainly a decent candidate to kick even out of this
> issue.)
> *Documentation and Intelligibility*
> * There are a few places (CHANGES.txt, tracing output in
> {{ReplicaFilteringProtection}}, etc.) where we mention "replica-side
> filtering protection" (which makes it seem like the coordinator doesn't
> filter) rather than "replica filtering protection" (which sounds more like
> what we actually do, which is protect ourselves against incorrect replica
> filtering results).
[jira] [Commented] (CASSANDRA-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159876#comment-17159876
]
Robert Stupp commented on CASSANDRA-15375:
--
+1
super nit: maybe [change the wording
here|https://github.com/belliottsmith/cassandra/commit/2ba8b4d162c20142c3d4c7a225432337b7bdbc36#diff-4805e34bd9553ede03778be66ddc06c7R262]
to "removed" instead of "deprecated"?
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159846#comment-17159846
]
Benedict Elliott Smith edited comment on CASSANDRA-15234 at 7/17/20, 10:19 AM:
---
Thanks Caleb for the reminder. I've [pushed another
approach|https://github.com/belliottsmith/cassandra/tree/CASSANDRA-15234-grouping-ideas],
that groups options by the reason the operator cares about them, namely:
* {{cluster}}-wide settings (partitioner, token etc)
* {{disk}} options that specify strategy, throttle throughput etc
* {{memory}} options that allocate heap or direct memory resources
* {{concurrency}} that constrain the number of operations or threads committed
to tasks
* {{internode}} and {{client}} networking options
* {{feature}} options; and
* {{log}} options for our warning thresholds etc
It was taking a while, and it might not be well received, so I only went about
90% of the way so that the approach can receive some feedback. Obviously, this
would necessitate a different approach to the headline comments, wherein we
might want to list the parameters users might care about in prose alongside
explanations for why they might care.
I personally would like to propose we also introduce a dual system for updating
properties, wherein we can accept the nested namespace versions, as well as
e.g. dot-delimited versions. e.g. {{disk.throttle.compaction: 10MiB/s}}. This
should mitigate any risk to simplistic tools, as well as maybe providing us a
simple route to permitting common options being given at the start of the file,
without confusing the overall approach.
[~e.dimitrova]: in going through the yaml, I noticed that you have used mbps in
many places, but I thought we had previously agreed that any {{bps}} was
ambiguous, since it can mean bits or bytes? I thought we had settled on MiB/s
so that there could be no ambiguity? (Since MB/s is also ambiguous -
technically meaning 1000s, but often meaning powers of 2)?
was (Author: benedict):
Thanks Caleb for the reminder. I've pushed another approach, that groups
options by the reason the operator cares about them, namely:
* {{cluster}}-wide settings (partitioner, token etc)
* {{disk}} options that specify strategy, throttle throughput etc
* {{memory}} options that allocate heap or direct memory resources
* {{concurrency}} that constrain the number of operations or threads committed
to tasks
* {{internode}} and {{client}} networking options
* {{feature}} options; and
* {{log}} options for our warning thresholds etc
It was taking a while, and it might not be well received, so I only went about
90% of the way so that the approach can receive some feedback. Obviously, this
would necessitate a different approach to the headline comments, wherein we
might want to list the parameters users might care about in prose alongside
explanations for why they might care.
I personally would like to propose we also introduce a dual system for updating
properties, wherein we can accept the nested namespace versions, as well as
e.g. dot-delimited versions. e.g. {{disk.throttle.compaction: 10MiB/s}}. This
should mitigate any risk to simplistic tools, as well as maybe providing us a
simple route to permitting common options being given at the start of the file,
without confusing the overall approach.
[~e.dimitrova]: in going through the yaml, I noticed that you have used mbps in
many places, but I thought we had previously agreed that any {{bps}} was
ambiguous, since it can mean bits or bytes? I thought we had settled on MiB/s
so that there could be no ambiguity? (Since MB/s is also ambiguous -
technically meaning 1000s, but often meaning powers of 2)?
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for
[jira] [Comment Edited] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159846#comment-17159846
]
Benedict Elliott Smith edited comment on CASSANDRA-15234 at 7/17/20, 10:17 AM:
---
Thanks Caleb for the reminder. I've pushed another approach, that groups
options by the reason the operator cares about them, namely:
* {{cluster}}-wide settings (partitioner, token etc)
* {{disk}} options that specify strategy, throttle throughput etc
* {{memory}} options that allocate heap or direct memory resources
* {{concurrency}} that constrain the number of operations or threads committed
to tasks
* {{internode}} and {{client}} networking options
* {{feature}} options; and
* {{log}} options for our warning thresholds etc
It was taking a while, and it might not be well received, so I only went about
90% of the way so that the approach can receive some feedback. Obviously, this
would necessitate a different approach to the headline comments, wherein we
might want to list the parameters users might care about in prose alongside
explanations for why they might care.
I personally would like to propose we also introduce a dual system for updating
properties, wherein we can accept the nested namespace versions, as well as
e.g. dot-delimited versions. e.g. {{disk.throttle.compaction: 10MiB/s}}. This
should mitigate any risk to simplistic tools, as well as maybe providing us a
simple route to permitting common options being given at the start of the file,
without confusing the overall approach.
[~e.dimitrova]: in going through the yaml, I noticed that you have used mbps in
many places, but I thought we had previously agreed that any {{bps}} was
ambiguous, since it can mean bits or bytes? I thought we had settled on MiB/s
so that there could be no ambiguity? (Since MB/s is also ambiguous -
technically meaning 1000s, but often meaning powers of 2)?
was (Author: benedict):
Thanks Caleb for the reminder. I've pushed another approach, that groups
options by the reason the operator cares about them, namely: {{cluster}}-wide
settings (partitioner, token etc), {{disk}} options that specify strategy,
throttle throughput etc, {{memory}} options that allocate heap or direct memory
resources, {{concurrency}} that constrain the number of operations or threads
committed to tasks, {{internode}} and {{client}} networking options,
{{feature}} options and {{log}} options for our warning thresholds etc. It was
taking a while, and it might not be well received, so I only went about 90% of
the way so that the approach can receive some feedback. Obviously, this would
necessitate a different approach to the headline comments, wherein we might
want to list the parameters users might care about in prose alongside
explanations for why they might care.
I personally would like to propose we also introduce a dual system for updating
properties, wherein we can accept the nested namespace versions, as well as
e.g. dot-delimited versions. e.g. {{disk.throttle.compaction: 10MiB/s}}
[~e.dimitrova]: in going through the yaml, I noticed that you have used mbps in
many places, but I thought we had previously agreed that any {{bps}} was
ambiguous, since it can mean bits or bytes? I thought we had settled on MiB/s
so that there could be no ambiguity? (Since MB/s is also ambiguous -
technically meaning 1000s, but often meaning powers of 2)?
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159846#comment-17159846
]
Benedict Elliott Smith commented on CASSANDRA-15234:
Thanks Caleb for the reminder. I've pushed another approach, that groups
options by the reason the operator cares about them, namely: {{cluster}}-wide
settings (partitioner, token etc), {{disk}} options that specify strategy,
throttle throughput etc, {{memory}} options that allocate heap or direct memory
resources, {{concurrency}} that constrain the number of operations or threads
committed to tasks, {{internode}} and {{client}} networking options,
{{feature}} options and {{log}} options for our warning thresholds etc. It was
taking a while, and it might not be well received, so I only went about 90% of
the way so that the approach can receive some feedback. Obviously, this would
necessitate a different approach to the headline comments, wherein we might
want to list the parameters users might care about in prose alongside
explanations for why they might care.
I personally would like to propose we also introduce a dual system for updating
properties, wherein we can accept the nested namespace versions, as well as
e.g. dot-delimited versions. e.g. {{disk.throttle.compaction: 10MiB/s}}
[~e.dimitrova]: in going through the yaml, I noticed that you have used mbps in
many places, but I thought we had previously agreed that any {{bps}} was
ambiguous, since it can mean bits or bytes? I thought we had settled on MiB/s
so that there could be no ambiguity? (Since MB/s is also ambiguous -
technically meaning 1000s, but often meaning powers of 2)?
> Standardise config and JVM parameters
> -
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Benedict Elliott Smith
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-beta
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
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) Add command to 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=17159819#comment-17159819 ] Berenguer Blasi commented on CASSANDRA-15406: - CI run lgtm. Notice the stages have failures despite the overall test report CASSANDRA-15925 > Add command to 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: 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] [Commented] (CASSANDRA-15925) Jenkins pipeline can copy wrong test report artefacts from stage builds
[ https://issues.apache.org/jira/browse/CASSANDRA-15925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159818#comment-17159818 ] Berenguer Blasi commented on CASSANDRA-15925: - https://ci-cassandra.apache.org/job/Cassandra-devbranch/211/ reports no overall failures but stages have failures #collaborating > Jenkins pipeline can copy wrong test report artefacts from stage builds > --- > > Key: CASSANDRA-15925 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15925 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.0-rc > > > Spotted in > https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/196/console > Looks like copyArtifact will need to be specific to a build. -- 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-15814) order by descending on frozen list not working
[
https://issues.apache.org/jira/browse/CASSANDRA-15814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159808#comment-17159808
]
Berenguer Blasi commented on CASSANDRA-15814:
-
[~adelapena] I left a comment on the unit tests. Other than that I checked the
circle links as the rest 404 me. Circle, besides the probably related wall of
failures on 2.2, lgtm. I did run some of the failing ones that either passed
locally or match the failures in ci-cassandra. LGTM pending resolving the
comment in the PR.
> order by descending on frozen list not working
> --
>
> Key: CASSANDRA-15814
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15814
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Felipe Perez
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 1h
> Remaining Estimate: 0h
>
> By creating a table like the following:
> {code:java}
> CREATE TABLE IF NOT EXISTS software (
> name ascii,
> version frozen>,
> data ascii,
> PRIMARY KEY(name,version)
> )
> {code}
> It works and version is ordered in an ascending order. But when trying to
> order in descending order:
> {code:java}
> CREATE TABLE IF NOT EXISTS software (
> name ascii,
> version frozen>,
> data ascii,
> PRIMARY KEY(name,version)
> ) WITH CLUSTERING ORDER BY (version DESC);
> {code}
> The table is created normally, but when trying to insert a row:
> {code:java}
> insert into software(name, version) values ('t1', [2,10,30,40,50]);
> {code}
> Cassandra throws an error:
> {code:java}
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid
> list literal for version of type frozen>"
> {code}
> The goal here is that I would like to get the last version of a software.
>
--
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-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15375:
---
Status: Changes Suggested (was: Review In Progress)
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15375:
---
Status: In Progress (was: Changes Suggested)
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-15375:
---
Status: Patch Available (was: In Progress)
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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-15375) Remove BackPressureStrategy
[
https://issues.apache.org/jira/browse/CASSANDRA-15375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159794#comment-17159794
]
Benedict Elliott Smith commented on CASSANDRA-15375:
Sorry for dropping the ball on this, the ticket doesn't show up in my normal
Jira query (will figure out why later). I've pushed an update to the branch
addressing the review feedback; I think it's ready to commit with a quick +1
(CI is running
[here|https://app.circleci.com/pipelines/github/belliottsmith/cassandra?branch=15375])
> Remove BackPressureStrategy
> ---
>
> Key: CASSANDRA-15375
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15375
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Logging
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Low
> Fix For: 4.0, 4.0-beta
>
>
> This is odd:
> {{INFO [main] 2019-10-25 10:33:07,985 DatabaseDescriptor.java:803 -
> Back-pressure is disabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}
> When I saw that, I wasn't sure if back pressure was actually disabled, or if
> I was really using {{RateBasedBackPressure.}}
> This should change to output either:
> {{Back-pressure is disabled}}
> {{or}}
> {{Back-pressure is enabled with strategy
> org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5,
> flow=FAST}.}}{{}}
>
--
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-15191) stop_paranoid disk failure policy is ignored on CorruptSSTableException after node is up
[ https://issues.apache.org/jira/browse/CASSANDRA-15191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159763#comment-17159763 ] Stefan Miklosovic commented on CASSANDRA-15191: --- PR for trunk aka 4.0 [https://github.com/apache/cassandra/pull/684] > stop_paranoid disk failure policy is ignored on CorruptSSTableException after > node is up > > > Key: CASSANDRA-15191 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15191 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Vincent White >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.11.7, 4.0-beta1 > > Attachments: log.txt > > Time Spent: 20m > Remaining Estimate: 0h > > There is a bug when disk_failure_policy is set to stop_paranoid and > CorruptSSTableException is thrown after server is up. The problem is that > this setting is ignored. Normally, it should stop gossip and transport but it > just continues to serve requests and an exception is just logged. > > This patch unifies the exception handling in JVMStabilityInspector and code > is reworked in such way that this inspector acts as a central place where > such exceptions are inspected. > > The core reason for ignoring that exception is that thrown exception in > AbstractLocalAwareExecturorService is not CorruptSSTableException but it is > RuntimeException and that exception is as its cause. Hence it is better if we > handle this in JVMStabilityInspector which can recursively examine it, hence > act accordingly. > Behaviour before: > stop_paranoid of disk_failure_policy is ignored when CorruptSSTableException > is thrown, e.g. on a regular select statement > Behaviour after: > Gossip and transport (cql) is turned off, JVM is still up for further > investigation e.g. by jmx. -- 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-15583) 4.0 quality testing: Tooling, Bundled and First Party
[ https://issues.apache.org/jira/browse/CASSANDRA-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159761#comment-17159761 ] Berenguer Blasi commented on CASSANDRA-15583: - Starting width first testing in CASSANDRA-15956 > 4.0 quality testing: Tooling, Bundled and First Party > - > > Key: CASSANDRA-15583 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15583 > Project: Cassandra > Issue Type: Task > Components: Test/dtest, Test/unit >Reporter: Josh McKenzie >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Reference [doc from > NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] > for context. > *Shepherd: Sam Tunnicliffe* > Test plans should cover bundled first-party tooling and CLIs such as > nodetool, cqlsh, and new tools supporting full query and audit logging > (CASSANDRA-13983, CASSANDRA-12151). -- 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-15956) 15583 - Toolinng width first test
[ https://issues.apache.org/jira/browse/CASSANDRA-15956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15956: Change Category: Quality Assurance Complexity: Normal Fix Version/s: 4.0-beta Status: Open (was: Triage Needed) > 15583 - Toolinng width first test > - > > Key: CASSANDRA-15956 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15956 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Given CASSANDRA-15942 POC seems ok so far. Now we'll extend that to other > tools and scenarios in a width first approach to make sure enough surface > area is covered. This should suffice to confirm our framework should enable > devs to test any tools when needed. -- 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-15956) 15583 - Toolinng width first test
Berenguer Blasi created CASSANDRA-15956: --- Summary: 15583 - Toolinng width first test Key: CASSANDRA-15956 URL: https://issues.apache.org/jira/browse/CASSANDRA-15956 Project: Cassandra Issue Type: Improvement Components: Test/unit Reporter: Berenguer Blasi Assignee: Berenguer Blasi Given CASSANDRA-15942 POC seems ok so far. Now we'll extend that to other tools and scenarios in a width first approach to make sure enough surface area is covered. This should suffice to confirm our framework should enable devs to test any tools when needed. -- 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-15942) 15583 - Tooling testing foundation
[ https://issues.apache.org/jira/browse/CASSANDRA-15942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15942: Summary: 15583 - Tooling testing foundation (was: Tooling testing foundation) > 15583 - Tooling testing foundation > -- > > Key: CASSANDRA-15942 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15942 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Tooling testing is not as thorough as we'd like it to be. The purpose of this > ticket, under the umbrella of CASSANDRA-15583, is to provide the foundations > to make it easy for devs, migrate the few existing tests as a POC and put > that forward as a proposal to build on top of. -- 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-15942) Tooling testing foundation
[
https://issues.apache.org/jira/browse/CASSANDRA-15942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159752#comment-17159752
]
Berenguer Blasi edited comment on CASSANDRA-15942 at 7/17/20, 7:50 AM:
---
Thanks [~snazy]. CI looks good (links in PR) and I merged it into the main
feature branch in my fork.
Yes, all praise to [~snazy] for the initial implementation of {{ToolRunner}} I
changed. If it works it's his, if it breaks it's my fault lol :-)
was (Author: bereng):
Thanks [~snazy]. CI looks good (links in PR) and I merged it into the main
feature branch in my fork.
Yes, all praise to [~snazy] for the initial implementation of {{ToolRunner}}
:-)
> Tooling testing foundation
> --
>
> Key: CASSANDRA-15942
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15942
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Tooling testing is not as thorough as we'd like it to be. The purpose of this
> ticket, under the umbrella of CASSANDRA-15583, is to provide the foundations
> to make it easy for devs, migrate the few existing tests as a POC and put
> that forward as a proposal to build on top of.
--
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-15942) Tooling testing foundation
[
https://issues.apache.org/jira/browse/CASSANDRA-15942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159752#comment-17159752
]
Berenguer Blasi commented on CASSANDRA-15942:
-
Thanks [~snazy]. CI looks good (links in PR) and I merged it into the main
feature branch in my fork.
Yes, all praise to [~snazy] for the initial implementation of {{ToolRunner}}
:-)
> Tooling testing foundation
> --
>
> Key: CASSANDRA-15942
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15942
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Tooling testing is not as thorough as we'd like it to be. The purpose of this
> ticket, under the umbrella of CASSANDRA-15583, is to provide the foundations
> to make it easy for devs, migrate the few existing tests as a POC and put
> that forward as a proposal to build on top of.
--
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-15942) Tooling testing foundation
[ https://issues.apache.org/jira/browse/CASSANDRA-15942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15942: Source Control Link: See PR Resolution: Fixed Status: Resolved (was: Ready to Commit) > Tooling testing foundation > -- > > Key: CASSANDRA-15942 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15942 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta > > > Tooling testing is not as thorough as we'd like it to be. The purpose of this > ticket, under the umbrella of CASSANDRA-15583, is to provide the foundations > to make it easy for devs, migrate the few existing tests as a POC and put > that forward as a proposal to build on top of. -- 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-15955) java.nio.file.AccessDeniedException
[
https://issues.apache.org/jira/browse/CASSANDRA-15955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-15955:
-
Resolution: Not A Problem
Status: Resolved (was: Triage Needed)
This is obviously related to your file-system permissions. Please check on the
C* user-mailing-list or ASF Slack {{#cassandra}}.
> java.nio.file.AccessDeniedException
> ---
>
> Key: CASSANDRA-15955
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15955
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: rafi saeputra
>Priority: Normal
>
> when i installed cassandra with binnary tarball i got an error log like this
> ERROR [COMMIT-LOG-ALLOCATOR] 2020-07-17 11:47:33,712
> JVMStabilityInspector.java:113 - Exiting due to error while processing commit
> log during initialization.
> org.apache.cassandra.io.FSWriteError: java.nio.file.AccessDeniedException:
> /var/lib/cassandra/commitlog/CommitLog-7-1594961253708.log
> at
> org.apache.cassandra.db.commitlog.CommitLogSegment.(CommitLogSegment.java:180)
> at
> org.apache.cassandra.db.commitlog.MemoryMappedSegment.(MemoryMappedSegment.java:45)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegment.createSegment(CommitLogSegment.java:137)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerStandard.createSegment(CommitLogSegmentManagerStandard.java:66)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$1.runMayThrow(AbstractCommitLogSegmentManager.java:114)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.file.AccessDeniedException:
> /var/lib/cassandra/commitlog/CommitLog-7-1594961253708.log
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at
> sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
> at java.nio.channels.FileChannel.open(FileChannel.java:287)
> at java.nio.channels.FileChannel.open(FileChannel.java:335)
> at
> org.apache.cassandra.db.commitlog.CommitLogSegment.(CommitLogSegment.java:175)
> ... 7 common frames omitted
--
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
