[jira] [Commented] (CASSANDRA-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102282#comment-17102282 ] Michael Semb Wever commented on CASSANDRA-15776: New ci-cassandra.apache.org test run [here|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/119/pipeline]. > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > Time Spent: 1.5h > Remaining Estimate: 0h > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle > CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] > and > [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). -- 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-15262) server_encryption_options is not backwards compatible with 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-15262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102279#comment-17102279
]
Michael Semb Wever commented on CASSANDRA-15262:
ci-cassandra.apache.org run
[here|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/118/pipeline].
(I had to specify the dtest branch rather than commit, so the tox commit is
included.)
> server_encryption_options is not backwards compatible with 3.11
> ---
>
> Key: CASSANDRA-15262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15262
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0, 4.0-alpha
>
>
> The current `server_encryption_options` configuration options are as follows:
> {noformat}
> server_encryption_options:
> # set to true for allowing secure incoming connections
> enabled: false
> # If enabled and optional are both set to true, encrypted and unencrypted
> connections are handled on the storage_port
> optional: false
> # if enabled, will open up an encrypted listening socket on
> ssl_storage_port. Should be used
> # during upgrade to 4.0; otherwise, set to false.
> enable_legacy_ssl_storage_port: false
> # on outbound connections, determine which type of peers to securely
> connect to. 'enabled' must be set to true.
> internode_encryption: none
> keystore: conf/.keystore
> keystore_password: cassandra
> truststore: conf/.truststore
> truststore_password: cassandra
> # More advanced defaults below:
> # protocol: TLS
> # store_type: JKS
> # cipher_suites:
> [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
> # require_client_auth: false
> # require_endpoint_verification: false
> {noformat}
> A couple of issues here:
> 1. optional defaults to false, which will break existing TLS configurations
> for (from what I can tell) no particularly good reason
> 2. The provided protocol and cipher suites are not good ideas (in particular
> encouraging anyone to use CBC ciphers is a bad plan
> I propose that before the 4.0 cut we fixup server_encryption_options and even
> client_encryption_options :
> # Change the default {{optional}} setting to true. As the new Netty code
> intelligently decides to open a TLS connection or not this is the more
> sensible default (saves operators a step while transitioning to TLS as well)
> # Update the defaults to what netty actually defaults to
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15676) flaky test testWriteUnknownResult- org.apache.cassandra.distributed.test.CasWriteTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102237#comment-17102237
]
Gianluca Righetto commented on CASSANDRA-15676:
---
Thanks [~yifanc]! I tested your suggestion and incorporated it in my pull
request. It works great and I was able to get rid of the whole message
serialization/deserialization dance.
[PR|https://github.com/grighetto/cassandra/pull/2]
[Java 11
Tests|https://app.circleci.com/pipelines/github/grighetto/cassandra/18/workflows/d6459a97-0a44-4720-8f85-0d8db11029a2/jobs/96]
[Java 8
Tests|https://app.circleci.com/pipelines/github/grighetto/cassandra/18/workflows/e549dfac-d53c-4ebf-bcbd-efa537c0b740/jobs/98]
> flaky test testWriteUnknownResult-
> org.apache.cassandra.distributed.test.CasWriteTest
> -
>
> Key: CASSANDRA-15676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15676
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest
>Reporter: Kevin Gallardo
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: Screen Shot 2020-05-07 at 7.25.19 PM.png
>
>
> Failure observed in:
> https://app.circleci.com/pipelines/github/newkek/cassandra/33/workflows/54007cf7-4424-4ec1-9655-665f6044e6d1/jobs/187/tests
> {noformat}
> testWriteUnknownResult - org.apache.cassandra.distributed.test.CasWriteTest
> junit.framework.AssertionFailedError: Expecting cause to be
> CasWriteUncertainException
> at
> org.apache.cassandra.distributed.test.CasWriteTest.testWriteUnknownResult(CasWriteTest.java:257)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
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-15676) flaky test testWriteUnknownResult- org.apache.cassandra.distributed.test.CasWriteTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianluca Righetto updated CASSANDRA-15676:
--
Status: Patch Available (was: In Progress)
> flaky test testWriteUnknownResult-
> org.apache.cassandra.distributed.test.CasWriteTest
> -
>
> Key: CASSANDRA-15676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15676
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest
>Reporter: Kevin Gallardo
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: Screen Shot 2020-05-07 at 7.25.19 PM.png
>
>
> Failure observed in:
> https://app.circleci.com/pipelines/github/newkek/cassandra/33/workflows/54007cf7-4424-4ec1-9655-665f6044e6d1/jobs/187/tests
> {noformat}
> testWriteUnknownResult - org.apache.cassandra.distributed.test.CasWriteTest
> junit.framework.AssertionFailedError: Expecting cause to be
> CasWriteUncertainException
> at
> org.apache.cassandra.distributed.test.CasWriteTest.testWriteUnknownResult(CasWriteTest.java:257)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
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-15676) flaky test testWriteUnknownResult- org.apache.cassandra.distributed.test.CasWriteTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianluca Righetto updated CASSANDRA-15676:
--
Status: In Progress (was: Changes Suggested)
> flaky test testWriteUnknownResult-
> org.apache.cassandra.distributed.test.CasWriteTest
> -
>
> Key: CASSANDRA-15676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15676
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest
>Reporter: Kevin Gallardo
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: Screen Shot 2020-05-07 at 7.25.19 PM.png
>
>
> Failure observed in:
> https://app.circleci.com/pipelines/github/newkek/cassandra/33/workflows/54007cf7-4424-4ec1-9655-665f6044e6d1/jobs/187/tests
> {noformat}
> testWriteUnknownResult - org.apache.cassandra.distributed.test.CasWriteTest
> junit.framework.AssertionFailedError: Expecting cause to be
> CasWriteUncertainException
> at
> org.apache.cassandra.distributed.test.CasWriteTest.testWriteUnknownResult(CasWriteTest.java:257)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
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-15790) EmptyType doesn't override writeValue so could attempt to write bytes when expected not to
[
https://issues.apache.org/jira/browse/CASSANDRA-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102208#comment-17102208
]
Yifan Cai commented on CASSANDRA-15790:
---
Overall look good. A few questions.
# Should {{readValue(DataInputPlus in, int maxValueSize)}} raise an exception
in the case that {{maxValueSize}} is not 0? If it ever happens, the system is
in a bad state.
# Is the {{AssertionError}} intended? I can see the intention might be
indicating the severity.
# nit: {{EmptyTypeTest.java}} has no new line at the EOF.
> EmptyType doesn't override writeValue so could attempt to write bytes when
> expected not to
> --
>
> Key: CASSANDRA-15790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15790
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
>
> EmptyType.writeValues is defined here
> https://github.com/apache/cassandra/blob/e394dc0bb32f612a476269010930c617dd1ed3cb/src/java/org/apache/cassandra/db/marshal/AbstractType.java#L407-L414
> {code}
> public void writeValue(ByteBuffer value, DataOutputPlus out) throws
> IOException
> {
> assert value.hasRemaining();
> if (valueLengthIfFixed() >= 0)
> out.write(value);
> else
> ByteBufferUtil.writeWithVIntLength(value, out);
> }
> {code}
> This is fine when the value is empty as the write of empty no-ops (the
> readValue also noops since the length is 0), but if the value is not empty
> (possible during upgrades or random bugs) then this could silently cause
> corruption; ideally this should throw a exception if the ByteBuffer has data.
> This was called from
> org.apache.cassandra.db.rows.BufferCell.Serializer#serialize, here we check
> to see if data is present or not and update the flags. If data is present
> then and only then do we call type.writeValue (which requires bytes is not
> empty). The problem is that EmptyType never expects writes to happen, but it
> still writes them; and does not read them (since it says it is fixed length
> of 0, so does read(buffer, 0)).
--
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-15676) flaky test testWriteUnknownResult- org.apache.cassandra.distributed.test.CasWriteTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102207#comment-17102207
]
Gianluca Righetto commented on CASSANDRA-15676:
---
[~e.dimitrova] I've seen metaspace exceptions around the in-jvm tests a couple
of months ago, I don't think it's anything specific to this test. At the time I
found similar issues reported in this ticket: CASSANDRA-14922. Actually, in
order to run the entire in-jvm suite locally, I have to increase
-XX:MaxMetaspaceSize.
When I run this test in a bash-loop in the command line, it always passes now
and I don't see any metaspace errors. I'm not sure about running within in the
IDE as you're there though.
> flaky test testWriteUnknownResult-
> org.apache.cassandra.distributed.test.CasWriteTest
> -
>
> Key: CASSANDRA-15676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15676
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest
>Reporter: Kevin Gallardo
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: Screen Shot 2020-05-07 at 7.25.19 PM.png
>
>
> Failure observed in:
> https://app.circleci.com/pipelines/github/newkek/cassandra/33/workflows/54007cf7-4424-4ec1-9655-665f6044e6d1/jobs/187/tests
> {noformat}
> testWriteUnknownResult - org.apache.cassandra.distributed.test.CasWriteTest
> junit.framework.AssertionFailedError: Expecting cause to be
> CasWriteUncertainException
> at
> org.apache.cassandra.distributed.test.CasWriteTest.testWriteUnknownResult(CasWriteTest.java:257)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
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-15798) Only calculate 1.0 + dynamicBadnessThreshold once per loop in DynamicEndpointSnitch
[ https://issues.apache.org/jira/browse/CASSANDRA-15798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15798: -- Status: Ready to Commit (was: Review In Progress) LGTM +1 > Only calculate 1.0 + dynamicBadnessThreshold once per loop in > DynamicEndpointSnitch > --- > > Key: CASSANDRA-15798 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15798 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-beta > > > The change to make dynamicBadnessThreshold volatile and mutable in > https://issues.apache.org/jira/browse/CASSANDRA-12179 could have minor > implications for the performance of this code: > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java#L216. > Its better to calculate this once before the loop starts, which has the > added benefit that the value is stable throughout the calculation as well. -- 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-15798) Only calculate 1.0 + dynamicBadnessThreshold once per loop in DynamicEndpointSnitch
[ https://issues.apache.org/jira/browse/CASSANDRA-15798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15798: -- Reviewers: David Capwell, David Capwell (was: David Capwell) David Capwell, David Capwell (was: David Capwell) Status: Review In Progress (was: Patch Available) > Only calculate 1.0 + dynamicBadnessThreshold once per loop in > DynamicEndpointSnitch > --- > > Key: CASSANDRA-15798 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15798 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-beta > > > The change to make dynamicBadnessThreshold volatile and mutable in > https://issues.apache.org/jira/browse/CASSANDRA-12179 could have minor > implications for the performance of this code: > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java#L216. > Its better to calculate this once before the loop starts, which has the > added benefit that the value is stable throughout the calculation as well. -- 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-15256) Clean up redundant nodetool commands added in 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-15256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102121#comment-17102121 ] Jordan West edited comment on CASSANDRA-15256 at 5/8/20, 1:27 AM: -- Rebased on a recent trunk here: https://github.com/jrwest/cassandra/commits/nodetool_cleanup New build started here: https://app.circleci.com/pipelines/github/jrwest/cassandra/11/workflows/705761a6-389b-4c4e-a755-3ee1aecc4bf2 Test failure notes: - the only java8 unit test failure is unrelated / flaky (no use of Nodetool in the test) - dtest failure test_refresh_size_estimates_clears_invalid_entries is known was (Author: jrwest): Rebased on a recent trunk here: https://github.com/jrwest/cassandra/commits/nodetool_cleanup New build started here: https://app.circleci.com/pipelines/github/jrwest/cassandra/11/workflows/705761a6-389b-4c4e-a755-3ee1aecc4bf2 Test failure notes: - the only java8 unit test failure is unrelated / flaky (no use of Nodetool in the test) > Clean up redundant nodetool commands added in 4.0 > - > > Key: CASSANDRA-15256 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15256 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Low > Fix For: 4.0 > > > Both hintedhandoff and getendpoints had a 2nd command added that does the > exact thing but rewritten (and in getReplicas not as well) not just aliased > (like cf->tablestats). Also a minor cleanup is same command added multiple > times to nodetool command list. We should clean this up before 4.0 release > before people become reliant on the newly introduced command name. If we want > them renamed as that we should rename and link with alias like we do with > cf->table others. -- 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-15797) Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102145#comment-17102145
]
Yifan Cai commented on CASSANDRA-15797:
---
I can work on it if you do not plan to, Jon.
> Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
> ---
>
> Key: CASSANDRA-15797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15797
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> An internal CI system is failing BinLogTest somewhat frequently under JDK11.
> Configuration was recently changed to reduce the number of cores the tests
> run with, however it is reproducible on an 8 core laptop.
> {code}
> [junit-timeout] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC
> was deprecated in version 9.0 and will likely be removed in a future release.
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [Junit-timeout] WARNING: An illegal reflective access operation has occurred
> [junit-timeout] WARNING: Illegal reflective access by
> net.openhft.chronicle.core.Jvm (file:/.../lib/chronicle-core-1.16.4.jar) to
> field java.nio.Bits.RESERVED_MEMORY
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.895 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testPutAfterStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected: but
> was:
> [junit-timeout] junit.framework.AssertionFailedError: expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testPutAfterStop(BinLogTest.java:431)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> There's also a different failure under JDK8
> {code}
> junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 15.273 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testBinLogStartStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected:<2> but was:<0>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<2> but was:<0>
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testBinLogStartStop(BinLogTest.java:172)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> Reproducer
> {code}
> PASSED=0; time { while ant testclasslist -Dtest.classlistprefix=unit
> -Dtest.classlistfile=<(echo
> org/apache/cassandra/utils/binlog/BinLogTest.java); do PASSED=$((PASSED+1));
> echo PASSED $PASSED; done }; echo FAILED after $PASSED runs.
> {code}
> In the last four attempts it has taken 31, 38, 27 and 10 rounds respectively
> under JDK11 and took 51 under JDK8 (about 15 minutes).
> I have not tried running in a cpu-limited container or anything like that yet.
> Additionally, this went past in the logs a few times (under JDK11). No idea
> if it's just an artifact of weird test setup, or something more serious.
> {code}
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.839 sec
> [junit-timeout]
> [junit-timeout] java.lang.Throwable: 1e53135d-main creation ref-count=1
> [junit-timeout] at
> net.openhft.chronicle.core.ReferenceCounter.newRefCountHistory(ReferenceCounter.java:45)
> [junit-timeout] at
>
[jira] [Updated] (CASSANDRA-15798) Only calculate 1.0 + dynamicBadnessThreshold once per loop in DynamicEndpointSnitch
[ https://issues.apache.org/jira/browse/CASSANDRA-15798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-15798: Test and Documentation Plan: https://app.circleci.com/pipelines/github/jrwest/cassandra/14/workflows/acf26d1e-7920-4338-b385-f2eb3164e772 Status: Patch Available (was: Open) > Only calculate 1.0 + dynamicBadnessThreshold once per loop in > DynamicEndpointSnitch > --- > > Key: CASSANDRA-15798 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15798 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-beta > > > The change to make dynamicBadnessThreshold volatile and mutable in > https://issues.apache.org/jira/browse/CASSANDRA-12179 could have minor > implications for the performance of this code: > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java#L216. > Its better to calculate this once before the loop starts, which has the > added benefit that the value is stable throughout the calculation as well. -- 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-15676) flaky test testWriteUnknownResult- org.apache.cassandra.distributed.test.CasWriteTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-15676:
--
Status: Changes Suggested (was: Review In Progress)
> flaky test testWriteUnknownResult-
> org.apache.cassandra.distributed.test.CasWriteTest
> -
>
> Key: CASSANDRA-15676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15676
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest
>Reporter: Kevin Gallardo
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: Screen Shot 2020-05-07 at 7.25.19 PM.png
>
>
> Failure observed in:
> https://app.circleci.com/pipelines/github/newkek/cassandra/33/workflows/54007cf7-4424-4ec1-9655-665f6044e6d1/jobs/187/tests
> {noformat}
> testWriteUnknownResult - org.apache.cassandra.distributed.test.CasWriteTest
> junit.framework.AssertionFailedError: Expecting cause to be
> CasWriteUncertainException
> at
> org.apache.cassandra.distributed.test.CasWriteTest.testWriteUnknownResult(CasWriteTest.java:257)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
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-15676) flaky test testWriteUnknownResult- org.apache.cassandra.distributed.test.CasWriteTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-15676:
--
Reviewers: Ekaterina Dimitrova, Yifan Cai (was: Ekaterina Dimitrova)
> flaky test testWriteUnknownResult-
> org.apache.cassandra.distributed.test.CasWriteTest
> -
>
> Key: CASSANDRA-15676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15676
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest
>Reporter: Kevin Gallardo
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: Screen Shot 2020-05-07 at 7.25.19 PM.png
>
>
> Failure observed in:
> https://app.circleci.com/pipelines/github/newkek/cassandra/33/workflows/54007cf7-4424-4ec1-9655-665f6044e6d1/jobs/187/tests
> {noformat}
> testWriteUnknownResult - org.apache.cassandra.distributed.test.CasWriteTest
> junit.framework.AssertionFailedError: Expecting cause to be
> CasWriteUncertainException
> at
> org.apache.cassandra.distributed.test.CasWriteTest.testWriteUnknownResult(CasWriteTest.java:257)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
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-15676) flaky test testWriteUnknownResult- org.apache.cassandra.distributed.test.CasWriteTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102142#comment-17102142
]
Yifan Cai commented on CASSANDRA-15676:
---
[~e.dimitrova] if you can always reproduce the MetaSpace OOM after several
iterations, it is certain that there is a memory leak at MetaSpace.
Probably the {{classLoader}} in {{IsolatedExecutor}} is not closed completely.
> flaky test testWriteUnknownResult-
> org.apache.cassandra.distributed.test.CasWriteTest
> -
>
> Key: CASSANDRA-15676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15676
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest
>Reporter: Kevin Gallardo
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: Screen Shot 2020-05-07 at 7.25.19 PM.png
>
>
> Failure observed in:
> https://app.circleci.com/pipelines/github/newkek/cassandra/33/workflows/54007cf7-4424-4ec1-9655-665f6044e6d1/jobs/187/tests
> {noformat}
> testWriteUnknownResult - org.apache.cassandra.distributed.test.CasWriteTest
> junit.framework.AssertionFailedError: Expecting cause to be
> CasWriteUncertainException
> at
> org.apache.cassandra.distributed.test.CasWriteTest.testWriteUnknownResult(CasWriteTest.java:257)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
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-15798) Only calculate 1.0 + dynamicBadnessThreshold once per loop in DynamicEndpointSnitch
[ https://issues.apache.org/jira/browse/CASSANDRA-15798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15798: -- Reviewers: David Capwell > Only calculate 1.0 + dynamicBadnessThreshold once per loop in > DynamicEndpointSnitch > --- > > Key: CASSANDRA-15798 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15798 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-beta > > > The change to make dynamicBadnessThreshold volatile and mutable in > https://issues.apache.org/jira/browse/CASSANDRA-12179 could have minor > implications for the performance of this code: > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java#L216. > Its better to calculate this once before the loop starts, which has the > added benefit that the value is stable throughout the calculation as well. -- 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-15798) Only calculate 1.0 + dynamicBadnessThreshold once per loop in DynamicEndpointSnitch
[ https://issues.apache.org/jira/browse/CASSANDRA-15798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-15798: Bug Category: Parent values: Degradation(12984)Level 1 values: Performance Bug/Regression(12997) Complexity: Low Hanging Fruit Discovered By: User Report Fix Version/s: 4.0-beta Severity: Low Status: Open (was: Triage Needed) > Only calculate 1.0 + dynamicBadnessThreshold once per loop in > DynamicEndpointSnitch > --- > > Key: CASSANDRA-15798 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15798 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > Fix For: 4.0-beta > > > The change to make dynamicBadnessThreshold volatile and mutable in > https://issues.apache.org/jira/browse/CASSANDRA-12179 could have minor > implications for the performance of this code: > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java#L216. > Its better to calculate this once before the loop starts, which has the > added benefit that the value is stable throughout the calculation as well. -- 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-15798) Only calculate 1.0 + dynamicBadnessThreshold once per loop in DynamicEndpointSnitch
Jordan West created CASSANDRA-15798: --- Summary: Only calculate 1.0 + dynamicBadnessThreshold once per loop in DynamicEndpointSnitch Key: CASSANDRA-15798 URL: https://issues.apache.org/jira/browse/CASSANDRA-15798 Project: Cassandra Issue Type: Bug Components: Messaging/Internode Reporter: Jordan West Assignee: Jordan West The change to make dynamicBadnessThreshold volatile and mutable in https://issues.apache.org/jira/browse/CASSANDRA-12179 could have minor implications for the performance of this code: https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/DynamicEndpointSnitch.java#L216. Its better to calculate this once before the loop starts, which has the added benefit that the value is stable throughout the calculation as well. -- 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-15676) flaky test testWriteUnknownResult- org.apache.cassandra.distributed.test.CasWriteTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102135#comment-17102135
]
Yifan Cai commented on CASSANDRA-15676:
---
Interesting approach. If I am reading the code correctly, the test makes sure
the response from peers are always false. So the first CAS backs off and
returns unknown result.
I think overwriting the response is not necessary. You can precisely construct
such a contention condition with {{CountDownLatch}} and 2 filters.
The test can block the PROPOSE req until the second CAS is completed. So the
first CAS is guaranteed to get unknown result. Something looks like the
following. Therefore, you do not need to open the access to methods in
{{Instance.java}} and {{DistributedTestSnitch.java}} and overwrites messages.
{code:java}
CountDownLatch ready = new CountDownLatch(1);
cluster.filters().verbs(Verb.PAXOS_PROPOSE_REQ.id).from(1).to(2,
3).messagesMatching((from, to, msg) -> {
if (to == 2)
{
// Inject a single CAS request in-between prepare and
propose phases
cluster.coordinator(2).execute(mkCasInsertQuery((a) -> pk,
1, 2),
ConsistencyLevel.QUORUM);
ready.countDown();
} else {
Uninterruptibles.awaitUninterruptibly(ready);
}
return false;
}).drop(); // the message intercepting syntax is sort of
confusing...
{code}
> flaky test testWriteUnknownResult-
> org.apache.cassandra.distributed.test.CasWriteTest
> -
>
> Key: CASSANDRA-15676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15676
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest
>Reporter: Kevin Gallardo
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: Screen Shot 2020-05-07 at 7.25.19 PM.png
>
>
> Failure observed in:
> https://app.circleci.com/pipelines/github/newkek/cassandra/33/workflows/54007cf7-4424-4ec1-9655-665f6044e6d1/jobs/187/tests
> {noformat}
> testWriteUnknownResult - org.apache.cassandra.distributed.test.CasWriteTest
> junit.framework.AssertionFailedError: Expecting cause to be
> CasWriteUncertainException
> at
> org.apache.cassandra.distributed.test.CasWriteTest.testWriteUnknownResult(CasWriteTest.java:257)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
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-15256) Clean up redundant nodetool commands added in 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-15256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102121#comment-17102121 ] Jordan West edited comment on CASSANDRA-15256 at 5/8/20, 12:45 AM: --- Rebased on a recent trunk here: https://github.com/jrwest/cassandra/commits/nodetool_cleanup New build started here: https://app.circleci.com/pipelines/github/jrwest/cassandra/11/workflows/705761a6-389b-4c4e-a755-3ee1aecc4bf2 Test failure notes: - the only java8 unit test failure is unrelated / flaky (no use of Nodetool in the test) was (Author: jrwest): Rebased on a recent trunk here: https://github.com/jrwest/cassandra/commits/nodetool_cleanup New build started here: https://app.circleci.com/pipelines/github/jrwest/cassandra/11/workflows/705761a6-389b-4c4e-a755-3ee1aecc4bf2 > Clean up redundant nodetool commands added in 4.0 > - > > Key: CASSANDRA-15256 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15256 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Low > Fix For: 4.0 > > > Both hintedhandoff and getendpoints had a 2nd command added that does the > exact thing but rewritten (and in getReplicas not as well) not just aliased > (like cf->tablestats). Also a minor cleanup is same command added multiple > times to nodetool command list. We should clean this up before 4.0 release > before people become reliant on the newly introduced command name. If we want > them renamed as that we should rename and link with alias like we do with > cf->table others. -- 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-15256) Clean up redundant nodetool commands added in 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-15256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102121#comment-17102121 ] Jordan West edited comment on CASSANDRA-15256 at 5/8/20, 12:17 AM: --- Rebased on a recent trunk here: https://github.com/jrwest/cassandra/commits/nodetool_cleanup New build started here: https://app.circleci.com/pipelines/github/jrwest/cassandra/11/workflows/705761a6-389b-4c4e-a755-3ee1aecc4bf2 was (Author: jrwest): -Getting ready to commit this. Kicked off a build: https://app.circleci.com/pipelines/github/jrwest/cassandra/10/workflows/3fdc3194-bfea-4fa9-adbe-8ab5843add09- That branch was very out of date. Rebased on a recent trunk here: https://github.com/jrwest/cassandra/commits/nodetool_cleanup New build started here: https://app.circleci.com/pipelines/github/jrwest/cassandra/11/workflows/705761a6-389b-4c4e-a755-3ee1aecc4bf2 > Clean up redundant nodetool commands added in 4.0 > - > > Key: CASSANDRA-15256 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15256 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Low > Fix For: 4.0 > > > Both hintedhandoff and getendpoints had a 2nd command added that does the > exact thing but rewritten (and in getReplicas not as well) not just aliased > (like cf->tablestats). Also a minor cleanup is same command added multiple > times to nodetool command list. We should clean this up before 4.0 release > before people become reliant on the newly introduced command name. If we want > them renamed as that we should rename and link with alias like we do with > cf->table others. -- 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-15256) Clean up redundant nodetool commands added in 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-15256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102121#comment-17102121 ] Jordan West edited comment on CASSANDRA-15256 at 5/8/20, 12:16 AM: --- -Getting ready to commit this. Kicked off a build: https://app.circleci.com/pipelines/github/jrwest/cassandra/10/workflows/3fdc3194-bfea-4fa9-adbe-8ab5843add09- That branch was very out of date. Rebased on a recent trunk here: https://github.com/jrwest/cassandra/commits/nodetool_cleanup New build started here: https://app.circleci.com/pipelines/github/jrwest/cassandra/11/workflows/705761a6-389b-4c4e-a755-3ee1aecc4bf2 was (Author: jrwest): Getting ready to commit this. Kicked off a build: https://app.circleci.com/pipelines/github/jrwest/cassandra/10/workflows/3fdc3194-bfea-4fa9-adbe-8ab5843add09 > Clean up redundant nodetool commands added in 4.0 > - > > Key: CASSANDRA-15256 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15256 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Low > Fix For: 4.0 > > > Both hintedhandoff and getendpoints had a 2nd command added that does the > exact thing but rewritten (and in getReplicas not as well) not just aliased > (like cf->tablestats). Also a minor cleanup is same command added multiple > times to nodetool command list. We should clean this up before 4.0 release > before people become reliant on the newly introduced command name. If we want > them renamed as that we should rename and link with alias like we do with > cf->table others. -- 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-15256) Clean up redundant nodetool commands added in 4.0
[ https://issues.apache.org/jira/browse/CASSANDRA-15256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102121#comment-17102121 ] Jordan West commented on CASSANDRA-15256: - Getting ready to commit this. Kicked off a build: https://app.circleci.com/pipelines/github/jrwest/cassandra/10/workflows/3fdc3194-bfea-4fa9-adbe-8ab5843add09 > Clean up redundant nodetool commands added in 4.0 > - > > Key: CASSANDRA-15256 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15256 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Low > Fix For: 4.0 > > > Both hintedhandoff and getendpoints had a 2nd command added that does the > exact thing but rewritten (and in getReplicas not as well) not just aliased > (like cf->tablestats). Also a minor cleanup is same command added multiple > times to nodetool command list. We should clean this up before 4.0 release > before people become reliant on the newly introduced command name. If we want > them renamed as that we should rename and link with alias like we do with > cf->table others. -- 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-15765) Get-by-index introduced in CASSANDRA-15394 could have negative performance impact on non-RandomAccess List
[
https://issues.apache.org/jira/browse/CASSANDRA-15765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102103#comment-17102103
]
Yifan Cai commented on CASSANDRA-15765:
---
The concern is really just about the type. In practice, code review _should_
guard the introduction of wrong types. However, it would be really nice if
compiler can do the job. _(no human error)_
There is bit verbose solution to declare the type of the acceptable parameter
should be a List with RandomAccess.
Pasting the conceptual code here.
{code:java}
public static class ScannerList
& RandomAccess> implements AutoCloseable
{
public final RandomAccessList scanners;
public ScannerList(RandomAccessList scanners)
{
this.scanners = scanners;
}
...
}{code}
The upside: compiler checks if the type satisfies, and no check performed at
runtime.
The downside: code gets verbose.
What do you think?
> Get-by-index introduced in CASSANDRA-15394 could have negative performance
> impact on non-RandomAccess List
> --
>
> Key: CASSANDRA-15765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15765
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> CASSANDRA-15394 replaced the iterator based iteration with the get-by-index
> one to avoid allocation iterators.
> It works for the lists that support RandomAccess, i.e. the big O of {{get()}}
> is {{O(1)}}.
> However, it fails when the list does not support RandomAccess. The {{get()}}
> method's time complexity can be linear, and it leads to {{O(n^2)}} for the
> overall iteration.
> The implementation should provide different behaviors based on the property.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15765) Get-by-index introduced in CASSANDRA-15394 could have negative performance impact on non-RandomAccess List
[
https://issues.apache.org/jira/browse/CASSANDRA-15765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102103#comment-17102103
]
Yifan Cai edited comment on CASSANDRA-15765 at 5/7/20, 11:32 PM:
-
The concern is really just about the type. In practice, code review _should_
guard the introduction of wrong types. However, it would be really nice if
compiler can do the job. _(no human error)_
There is bit verbose solution to declare the type of the acceptable parameter
should be a List with RandomAccess.
Pasting the conceptual code here.
{code:java}
public static class ScannerList
& RandomAccess> implements AutoCloseable
{
public final RandomAccessList scanners;
public ScannerList(RandomAccessList scanners)
{
this.scanners = scanners;
}
...
}{code}
The upside: compiler checks if the type satisfies, and no check performed at
runtime.
The downside: code gets verbose.
What do you think?
was (Author: yifanc):
The concern is really just about the type. In practice, code review _should_
guard the introduction of wrong types. However, it would be really nice if
compiler can do the job. _(no human error)_
There is bit verbose solution to declare the type of the acceptable parameter
should be a List with RandomAccess.
Pasting the conceptual code here.
{code:java}
public static class ScannerList
& RandomAccess> implements AutoCloseable
{
public final RandomAccessList scanners;
public ScannerList(RandomAccessList scanners)
{
this.scanners = scanners;
}
...
}{code}
The upside: compiler checks if the type satisfies, and no check performed at
runtime.
The downside: code gets verbose.
What do you think?
> Get-by-index introduced in CASSANDRA-15394 could have negative performance
> impact on non-RandomAccess List
> --
>
> Key: CASSANDRA-15765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15765
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> CASSANDRA-15394 replaced the iterator based iteration with the get-by-index
> one to avoid allocation iterators.
> It works for the lists that support RandomAccess, i.e. the big O of {{get()}}
> is {{O(1)}}.
> However, it fails when the list does not support RandomAccess. The {{get()}}
> method's time complexity can be linear, and it leads to {{O(n^2)}} for the
> overall iteration.
> The implementation should provide different behaviors based on the property.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15676) flaky test testWriteUnknownResult- org.apache.cassandra.distributed.test.CasWriteTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15676:
Attachment: Screen Shot 2020-05-07 at 7.25.19 PM.png
> flaky test testWriteUnknownResult-
> org.apache.cassandra.distributed.test.CasWriteTest
> -
>
> Key: CASSANDRA-15676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15676
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest
>Reporter: Kevin Gallardo
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0-alpha
>
> Attachments: Screen Shot 2020-05-07 at 7.25.19 PM.png
>
>
> Failure observed in:
> https://app.circleci.com/pipelines/github/newkek/cassandra/33/workflows/54007cf7-4424-4ec1-9655-665f6044e6d1/jobs/187/tests
> {noformat}
> testWriteUnknownResult - org.apache.cassandra.distributed.test.CasWriteTest
> junit.framework.AssertionFailedError: Expecting cause to be
> CasWriteUncertainException
> at
> org.apache.cassandra.distributed.test.CasWriteTest.testWriteUnknownResult(CasWriteTest.java:257)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
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-15765) Get-by-index introduced in CASSANDRA-15394 could have negative performance impact on non-RandomAccess List
[
https://issues.apache.org/jira/browse/CASSANDRA-15765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102099#comment-17102099
]
Blake Eggleston commented on CASSANDRA-15765:
-
oh cool, I didn't know that
> Get-by-index introduced in CASSANDRA-15394 could have negative performance
> impact on non-RandomAccess List
> --
>
> Key: CASSANDRA-15765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15765
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> CASSANDRA-15394 replaced the iterator based iteration with the get-by-index
> one to avoid allocation iterators.
> It works for the lists that support RandomAccess, i.e. the big O of {{get()}}
> is {{O(1)}}.
> However, it fails when the list does not support RandomAccess. The {{get()}}
> method's time complexity can be linear, and it leads to {{O(n^2)}} for the
> overall iteration.
> The implementation should provide different behaviors based on the property.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15676) flaky test testWriteUnknownResult- org.apache.cassandra.distributed.test.CasWriteTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102100#comment-17102100
]
Ekaterina Dimitrova commented on CASSANDRA-15676:
-
[~gianluca] I was wondering, you managed to run it many times locally without
an error, right?
I wanted to attach a log of 100 successful runs but every fifth run the test
fails as in the attached screenshot.
Any idea why?
Otherwise I am about to give +1.
> flaky test testWriteUnknownResult-
> org.apache.cassandra.distributed.test.CasWriteTest
> -
>
> Key: CASSANDRA-15676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15676
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest
>Reporter: Kevin Gallardo
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Failure observed in:
> https://app.circleci.com/pipelines/github/newkek/cassandra/33/workflows/54007cf7-4424-4ec1-9655-665f6044e6d1/jobs/187/tests
> {noformat}
> testWriteUnknownResult - org.apache.cassandra.distributed.test.CasWriteTest
> junit.framework.AssertionFailedError: Expecting cause to be
> CasWriteUncertainException
> at
> org.apache.cassandra.distributed.test.CasWriteTest.testWriteUnknownResult(CasWriteTest.java:257)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
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-15765) Get-by-index introduced in CASSANDRA-15394 could have negative performance impact on non-RandomAccess List
[
https://issues.apache.org/jira/browse/CASSANDRA-15765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102094#comment-17102094
]
Benedict Elliott Smith commented on CASSANDRA-15765:
There is actually a signifier for this, the {{(java.util.)RandomAccess}}
interface. Not making any specific recommendations, as I don't think this is
an issue in reality: nobody should be using a non-random-access list pretty
much anywhere in the codebase, let alone here, and it isn't free to test for
this interface. But there is a mechanism if we wanted to check.
> Get-by-index introduced in CASSANDRA-15394 could have negative performance
> impact on non-RandomAccess List
> --
>
> Key: CASSANDRA-15765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15765
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> CASSANDRA-15394 replaced the iterator based iteration with the get-by-index
> one to avoid allocation iterators.
> It works for the lists that support RandomAccess, i.e. the big O of {{get()}}
> is {{O(1)}}.
> However, it fails when the list does not support RandomAccess. The {{get()}}
> method's time complexity can be linear, and it leads to {{O(n^2)}} for the
> overall iteration.
> The implementation should provide different behaviors based on the property.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15765) Get-by-index introduced in CASSANDRA-15394 could have negative performance impact on non-RandomAccess List
[
https://issues.apache.org/jira/browse/CASSANDRA-15765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102083#comment-17102083
]
Blake Eggleston commented on CASSANDRA-15765:
-
Thanks for bringing this up Yifan. I'm not sure there's a clean solution to
this. There are several "Array Lists" that we can encounter with these methods,
so we can't enforce an {{ArrayList}} type ({{ArrayList#SubList}} and
{{Arrays#ArrayList}}, for example), and the {{List}} interface doesn't
communicate it's preferred iteration style. Given this does have a measurable
benefit and currently no instances where we're iterating over the wrong type of
list, I'd be inclined to leave as is. The upside is that these are all fairly
hot sections of code, so I'd expect people to be careful when making changes to
data strucures, and hopefully running performance tests before committing.
> Get-by-index introduced in CASSANDRA-15394 could have negative performance
> impact on non-RandomAccess List
> --
>
> Key: CASSANDRA-15765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15765
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Yifan Cai
>Assignee: Yifan Cai
>Priority: Normal
>
> CASSANDRA-15394 replaced the iterator based iteration with the get-by-index
> one to avoid allocation iterators.
> It works for the lists that support RandomAccess, i.e. the big O of {{get()}}
> is {{O(1)}}.
> However, it fails when the list does not support RandomAccess. The {{get()}}
> method's time complexity can be linear, and it leads to {{O(n^2)}} for the
> overall iteration.
> The implementation should provide different behaviors based on the property.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15790) EmptyType doesn't override writeValue so could attempt to write bytes when expected not to
[
https://issues.apache.org/jira/browse/CASSANDRA-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102048#comment-17102048
]
Jordan West commented on CASSANDRA-15790:
-
Sounds and looks good to me [~dcapwell]. Thanks!
> EmptyType doesn't override writeValue so could attempt to write bytes when
> expected not to
> --
>
> Key: CASSANDRA-15790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15790
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
>
> EmptyType.writeValues is defined here
> https://github.com/apache/cassandra/blob/e394dc0bb32f612a476269010930c617dd1ed3cb/src/java/org/apache/cassandra/db/marshal/AbstractType.java#L407-L414
> {code}
> public void writeValue(ByteBuffer value, DataOutputPlus out) throws
> IOException
> {
> assert value.hasRemaining();
> if (valueLengthIfFixed() >= 0)
> out.write(value);
> else
> ByteBufferUtil.writeWithVIntLength(value, out);
> }
> {code}
> This is fine when the value is empty as the write of empty no-ops (the
> readValue also noops since the length is 0), but if the value is not empty
> (possible during upgrades or random bugs) then this could silently cause
> corruption; ideally this should throw a exception if the ByteBuffer has data.
> This was called from
> org.apache.cassandra.db.rows.BufferCell.Serializer#serialize, here we check
> to see if data is present or not and update the flags. If data is present
> then and only then do we call type.writeValue (which requires bytes is not
> empty). The problem is that EmptyType never expects writes to happen, but it
> still writes them; and does not read them (since it says it is fixed length
> of 0, so does read(buffer, 0)).
--
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-15158) Wait for schema agreement rather then in flight schema requests when bootstrapping
[
https://issues.apache.org/jira/browse/CASSANDRA-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102037#comment-17102037
]
Blake Eggleston commented on CASSANDRA-15158:
-
It's likely we'll want to fix this in 3.0 and up, so I'll review the 3.0
version to start with and we can go from there.
I haven't completed my review yet, but there are some structural and design
issues we should address up front.
*Structural issues*
First, the {{waitForSchema*}} methods should live in the MigrationManager. This
will prevent you from setting an updated status if you're sending out
additional schema pulls, but we can revisit that later if we think it's
neccesary.
Second, instantiating MigrationTaskCallbacks in StorageService/MigrationManager
and passing it into MigrationTask is a little awkward. I'd prefer if the
callback remained an anonymous class. We can communicate endpoint to send
schema pulls to with an inetaddress argument, and we need to rethink what
`isRunningForcibly` is doing and why. First, we shouldn't be adding it to
{{IAsyncCallback}} for this narrow use case. Next, it's use seems to be
changing how schema pulls actually work, but only in a test environment, which
is something we should avoid.
*Design issues*
This doesn't deal with multiple schema versions. If a node joins, and there are
2 or more schema versions floating around, it will only wait until it has
_some_ schema to begin bootstrapping, not all. Related to this, we also need a
plan for unreachable schema versions. For instance, if a single node is
reporting a schema version that no one else has, but the node is unreachable,
what do we do?
Next, I like how this limits the number of messages sent to a given endpoint,
but we should also limit the number of messages we send out for a given schema
version. If we have a large cluster, and all nodes are reporting the same
version, we don't need to ask every node for it's schema.
> Wait for schema agreement rather then in flight schema requests when
> bootstrapping
> --
>
> Key: CASSANDRA-15158
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15158
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip, Cluster/Schema
>Reporter: Vincent White
>Assignee: Ben Bromhead
>Priority: Normal
>
> Currently when a node is bootstrapping we use a set of latches
> (org.apache.cassandra.service.MigrationTask#inflightTasks) to keep track of
> in-flight schema pull requests, and we don't proceed with
> bootstrapping/stream until all the latches are released (or we timeout
> waiting for each one). One issue with this is that if we have a large schema,
> or the retrieval of the schema from the other nodes was unexpectedly slow
> then we have no explicit check in place to ensure we have actually received a
> schema before we proceed.
> While it's possible to increase "migration_task_wait_in_seconds" to force the
> node to wait on each latche longer, there are cases where this doesn't help
> because the callbacks for the schema pull requests have expired off the
> messaging service's callback map
> (org.apache.cassandra.net.MessagingService#callbacks) after
> request_timeout_in_ms (default 10 seconds) before the other nodes were able
> to respond to the new node.
> This patch checks for schema agreement between the bootstrapping node and the
> rest of the live nodes before proceeding with bootstrapping. It also adds a
> check to prevent the new node from flooding existing nodes with simultaneous
> schema pull requests as can happen in large clusters.
> Removing the latch system should also prevent new nodes in large clusters
> getting stuck for extended amounts of time as they wait
> `migration_task_wait_in_seconds` on each of the latches left orphaned by the
> timed out callbacks.
>
> ||3.11||
> |[PoC|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:check_for_schema]|
> |[dtest|https://github.com/apache/cassandra-dtest/compare/master...vincewhite:wait_for_schema_agreement]|
>
--
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-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102038#comment-17102038 ] David Capwell commented on CASSANDRA-15776: --- Latest patch is YELLOW, failing test ([see here|https://app.circleci.com/pipelines/github/dcapwell/cassandra/278/workflows/5d568580-5794-4359-a72c-065ead293c83/jobs/1356/tests]) is test_optimized_primary_range_repair - transient_replication_test.TestTransientReplication, which is a known issue. > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > Time Spent: 1.5h > Remaining Estimate: 0h > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle > CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] > and > [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). -- 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-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15776: -- Status: In Progress (was: Changes Suggested) > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > Time Spent: 1.5h > Remaining Estimate: 0h > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle > CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] > and > [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). -- 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-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15776: -- Status: Patch Available (was: In Progress) > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > Time Spent: 1.5h > Remaining Estimate: 0h > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle > CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] > and > [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). -- 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-15790) EmptyType doesn't override writeValue so could attempt to write bytes when expected not to
[
https://issues.apache.org/jira/browse/CASSANDRA-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15790:
--
Status: Patch Available (was: In Progress)
> EmptyType doesn't override writeValue so could attempt to write bytes when
> expected not to
> --
>
> Key: CASSANDRA-15790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15790
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
>
> EmptyType.writeValues is defined here
> https://github.com/apache/cassandra/blob/e394dc0bb32f612a476269010930c617dd1ed3cb/src/java/org/apache/cassandra/db/marshal/AbstractType.java#L407-L414
> {code}
> public void writeValue(ByteBuffer value, DataOutputPlus out) throws
> IOException
> {
> assert value.hasRemaining();
> if (valueLengthIfFixed() >= 0)
> out.write(value);
> else
> ByteBufferUtil.writeWithVIntLength(value, out);
> }
> {code}
> This is fine when the value is empty as the write of empty no-ops (the
> readValue also noops since the length is 0), but if the value is not empty
> (possible during upgrades or random bugs) then this could silently cause
> corruption; ideally this should throw a exception if the ByteBuffer has data.
> This was called from
> org.apache.cassandra.db.rows.BufferCell.Serializer#serialize, here we check
> to see if data is present or not and update the flags. If data is present
> then and only then do we call type.writeValue (which requires bytes is not
> empty). The problem is that EmptyType never expects writes to happen, but it
> still writes them; and does not read them (since it says it is fixed length
> of 0, so does read(buffer, 0)).
--
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-15790) EmptyType doesn't override writeValue so could attempt to write bytes when expected not to
[
https://issues.apache.org/jira/browse/CASSANDRA-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15790:
--
Status: In Progress (was: Changes Suggested)
> EmptyType doesn't override writeValue so could attempt to write bytes when
> expected not to
> --
>
> Key: CASSANDRA-15790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15790
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
>
> EmptyType.writeValues is defined here
> https://github.com/apache/cassandra/blob/e394dc0bb32f612a476269010930c617dd1ed3cb/src/java/org/apache/cassandra/db/marshal/AbstractType.java#L407-L414
> {code}
> public void writeValue(ByteBuffer value, DataOutputPlus out) throws
> IOException
> {
> assert value.hasRemaining();
> if (valueLengthIfFixed() >= 0)
> out.write(value);
> else
> ByteBufferUtil.writeWithVIntLength(value, out);
> }
> {code}
> This is fine when the value is empty as the write of empty no-ops (the
> readValue also noops since the length is 0), but if the value is not empty
> (possible during upgrades or random bugs) then this could silently cause
> corruption; ideally this should throw a exception if the ByteBuffer has data.
> This was called from
> org.apache.cassandra.db.rows.BufferCell.Serializer#serialize, here we check
> to see if data is present or not and update the flags. If data is present
> then and only then do we call type.writeValue (which requires bytes is not
> empty). The problem is that EmptyType never expects writes to happen, but it
> still writes them; and does not read them (since it says it is fixed length
> of 0, so does read(buffer, 0)).
--
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-15790) EmptyType doesn't override writeValue so could attempt to write bytes when expected not to
[
https://issues.apache.org/jira/browse/CASSANDRA-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102028#comment-17102028
]
David Capwell commented on CASSANDRA-15790:
---
bq. should we figure out which branch of code to use upfront instead of doing
the switch call each time?
Saw that after patching. If I understand you, you are saying "function >
switch"? If so not sure, its more verbose in the enum but has cleaner logic in
the body. I prefer the switch but not tied to it.
> EmptyType doesn't override writeValue so could attempt to write bytes when
> expected not to
> --
>
> Key: CASSANDRA-15790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15790
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
>
> EmptyType.writeValues is defined here
> https://github.com/apache/cassandra/blob/e394dc0bb32f612a476269010930c617dd1ed3cb/src/java/org/apache/cassandra/db/marshal/AbstractType.java#L407-L414
> {code}
> public void writeValue(ByteBuffer value, DataOutputPlus out) throws
> IOException
> {
> assert value.hasRemaining();
> if (valueLengthIfFixed() >= 0)
> out.write(value);
> else
> ByteBufferUtil.writeWithVIntLength(value, out);
> }
> {code}
> This is fine when the value is empty as the write of empty no-ops (the
> readValue also noops since the length is 0), but if the value is not empty
> (possible during upgrades or random bugs) then this could silently cause
> corruption; ideally this should throw a exception if the ByteBuffer has data.
> This was called from
> org.apache.cassandra.db.rows.BufferCell.Serializer#serialize, here we check
> to see if data is present or not and update the flags. If data is present
> then and only then do we call type.writeValue (which requires bytes is not
> empty). The problem is that EmptyType never expects writes to happen, but it
> still writes them; and does not read them (since it says it is fixed length
> of 0, so does read(buffer, 0)).
--
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-15790) EmptyType doesn't override writeValue so could attempt to write bytes when expected not to
[
https://issues.apache.org/jira/browse/CASSANDRA-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102024#comment-17102024
]
David Capwell commented on CASSANDRA-15790:
---
bq. instead of using null as the default value in parse, if you use "" (empty
string) you can short circuit that special case in addition to handling the no
value passed condition.
Can't short-circuit as this would log, this also confuses since users could
define "". I switched to java.lang.System#getProperty(java.lang.String) which
defaults to null.
bq. Consider trimming the string passed to NonEmptyWriteHandler.valueOf
Done
bq. Consider renaming “LOG_DATA_LOSS” to “LOG” for succinctness
We spoke in slack, I rather not as doing this causes data loss, so I care more
that you are aware of that than how succinct the name is. Renamed silent to
silent_DATA_LOSS for the same reasons.
bq. Really minor style nit: consider remaking *handle(r) to *mode or *behavior
Switched to behavior
bq. Minor style nit: define the NonEmptyWriteHandle enum closer to parse()
done.
[~jwest] commit for all feedback can be located
[here|https://github.com/dcapwell/cassandra/commit/166ab9c82401f0588959376ffcf2384f7a66f9f1]
> EmptyType doesn't override writeValue so could attempt to write bytes when
> expected not to
> --
>
> Key: CASSANDRA-15790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15790
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
>
> EmptyType.writeValues is defined here
> https://github.com/apache/cassandra/blob/e394dc0bb32f612a476269010930c617dd1ed3cb/src/java/org/apache/cassandra/db/marshal/AbstractType.java#L407-L414
> {code}
> public void writeValue(ByteBuffer value, DataOutputPlus out) throws
> IOException
> {
> assert value.hasRemaining();
> if (valueLengthIfFixed() >= 0)
> out.write(value);
> else
> ByteBufferUtil.writeWithVIntLength(value, out);
> }
> {code}
> This is fine when the value is empty as the write of empty no-ops (the
> readValue also noops since the length is 0), but if the value is not empty
> (possible during upgrades or random bugs) then this could silently cause
> corruption; ideally this should throw a exception if the ByteBuffer has data.
> This was called from
> org.apache.cassandra.db.rows.BufferCell.Serializer#serialize, here we check
> to see if data is present or not and update the flags. If data is present
> then and only then do we call type.writeValue (which requires bytes is not
> empty). The problem is that EmptyType never expects writes to happen, but it
> still writes them; and does not read them (since it says it is fixed length
> of 0, so does read(buffer, 0)).
--
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-15790) EmptyType doesn't override writeValue so could attempt to write bytes when expected not to
[
https://issues.apache.org/jira/browse/CASSANDRA-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102007#comment-17102007
]
Jordan West commented on CASSANDRA-15790:
-
One other follow-up thought. Since the property is not changeable at runtime:
should we figure out which branch of code to use upfront instead of doing the
switch call each time?
> EmptyType doesn't override writeValue so could attempt to write bytes when
> expected not to
> --
>
> Key: CASSANDRA-15790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15790
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
>
> EmptyType.writeValues is defined here
> https://github.com/apache/cassandra/blob/e394dc0bb32f612a476269010930c617dd1ed3cb/src/java/org/apache/cassandra/db/marshal/AbstractType.java#L407-L414
> {code}
> public void writeValue(ByteBuffer value, DataOutputPlus out) throws
> IOException
> {
> assert value.hasRemaining();
> if (valueLengthIfFixed() >= 0)
> out.write(value);
> else
> ByteBufferUtil.writeWithVIntLength(value, out);
> }
> {code}
> This is fine when the value is empty as the write of empty no-ops (the
> readValue also noops since the length is 0), but if the value is not empty
> (possible during upgrades or random bugs) then this could silently cause
> corruption; ideally this should throw a exception if the ByteBuffer has data.
> This was called from
> org.apache.cassandra.db.rows.BufferCell.Serializer#serialize, here we check
> to see if data is present or not and update the flags. If data is present
> then and only then do we call type.writeValue (which requires bytes is not
> empty). The problem is that EmptyType never expects writes to happen, but it
> still writes them; and does not read them (since it says it is fixed length
> of 0, so does read(buffer, 0)).
--
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-15790) EmptyType doesn't override writeValue so could attempt to write bytes when expected not to
[
https://issues.apache.org/jira/browse/CASSANDRA-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West updated CASSANDRA-15790:
Status: Changes Suggested (was: Review In Progress)
Tests look good. Agreed that the failures are known/unrelated. A few comments:
* instead of using {{null}} as the default value in {{parse}}, if you use
{{""}} (empty string) you can short circuit that special case in addition to
handling the no value passed condition.
* Consider trimming the string passed to {{NonEmptyWriteHandler.valueOf}}
* Consider renaming “LOG_DATA_LOSS” to “LOG” for succinctness
* Really minor style nit: consider remaking *handle(r) to *mode or *behavior.
* Minor style nit: define the {{NonEmptyWriteHandle}} enum closer to {{parse()}}
> EmptyType doesn't override writeValue so could attempt to write bytes when
> expected not to
> --
>
> Key: CASSANDRA-15790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15790
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-alpha
>
>
> EmptyType.writeValues is defined here
> https://github.com/apache/cassandra/blob/e394dc0bb32f612a476269010930c617dd1ed3cb/src/java/org/apache/cassandra/db/marshal/AbstractType.java#L407-L414
> {code}
> public void writeValue(ByteBuffer value, DataOutputPlus out) throws
> IOException
> {
> assert value.hasRemaining();
> if (valueLengthIfFixed() >= 0)
> out.write(value);
> else
> ByteBufferUtil.writeWithVIntLength(value, out);
> }
> {code}
> This is fine when the value is empty as the write of empty no-ops (the
> readValue also noops since the length is 0), but if the value is not empty
> (possible during upgrades or random bugs) then this could silently cause
> corruption; ideally this should throw a exception if the ByteBuffer has data.
> This was called from
> org.apache.cassandra.db.rows.BufferCell.Serializer#serialize, here we check
> to see if data is present or not and update the flags. If data is present
> then and only then do we call type.writeValue (which requires bytes is not
> empty). The problem is that EmptyType never expects writes to happen, but it
> still writes them; and does not read them (since it says it is fixed length
> of 0, so does read(buffer, 0)).
--
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-15676) flaky test testWriteUnknownResult- org.apache.cassandra.distributed.test.CasWriteTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15676:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Ekaterina Dimitrova, Ekaterina Dimitrova
Status: Review In Progress (was: Patch Available)
> flaky test testWriteUnknownResult-
> org.apache.cassandra.distributed.test.CasWriteTest
> -
>
> Key: CASSANDRA-15676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15676
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest
>Reporter: Kevin Gallardo
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Failure observed in:
> https://app.circleci.com/pipelines/github/newkek/cassandra/33/workflows/54007cf7-4424-4ec1-9655-665f6044e6d1/jobs/187/tests
> {noformat}
> testWriteUnknownResult - org.apache.cassandra.distributed.test.CasWriteTest
> junit.framework.AssertionFailedError: Expecting cause to be
> CasWriteUncertainException
> at
> org.apache.cassandra.distributed.test.CasWriteTest.testWriteUnknownResult(CasWriteTest.java:257)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
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-15262) server_encryption_options is not backwards compatible with 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-15262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101982#comment-17101982
]
Ekaterina Dimitrova commented on CASSANDRA-15262:
-
The patch looks good to me.
On trunk I see two new failures which as per Jenkins were not presented up to
now but they don't look related on high level:
- test_dead_sync_initiator - repair_tests.repair_test.TestRepair
- test_resume_stopped_build - materialized_views_test.TestMaterializedViews
I am lost with 2.2 and 3.0 as I haven't been working on them for quite some
time and I am not acquainted with the current CI issues there. Looks like more
of cqlsh unrelated ones?
> server_encryption_options is not backwards compatible with 3.11
> ---
>
> Key: CASSANDRA-15262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15262
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0, 4.0-alpha
>
>
> The current `server_encryption_options` configuration options are as follows:
> {noformat}
> server_encryption_options:
> # set to true for allowing secure incoming connections
> enabled: false
> # If enabled and optional are both set to true, encrypted and unencrypted
> connections are handled on the storage_port
> optional: false
> # if enabled, will open up an encrypted listening socket on
> ssl_storage_port. Should be used
> # during upgrade to 4.0; otherwise, set to false.
> enable_legacy_ssl_storage_port: false
> # on outbound connections, determine which type of peers to securely
> connect to. 'enabled' must be set to true.
> internode_encryption: none
> keystore: conf/.keystore
> keystore_password: cassandra
> truststore: conf/.truststore
> truststore_password: cassandra
> # More advanced defaults below:
> # protocol: TLS
> # store_type: JKS
> # cipher_suites:
> [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
> # require_client_auth: false
> # require_endpoint_verification: false
> {noformat}
> A couple of issues here:
> 1. optional defaults to false, which will break existing TLS configurations
> for (from what I can tell) no particularly good reason
> 2. The provided protocol and cipher suites are not good ideas (in particular
> encouraging anyone to use CBC ciphers is a bad plan
> I propose that before the 4.0 cut we fixup server_encryption_options and even
> client_encryption_options :
> # Change the default {{optional}} setting to true. As the new Netty code
> intelligently decides to open a TLS connection or not this is the more
> sensible default (saves operators a step while transitioning to TLS as well)
> # Update the defaults to what netty actually defaults to
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15773) Add test to cover metrics related to the BufferPool
[
https://issues.apache.org/jira/browse/CASSANDRA-15773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101951#comment-17101951
]
David Capwell commented on CASSANDRA-15773:
---
+1 from me.
I ran the build and the only failures were the View/Checkum tests (all known
flaky tests)
> Add test to cover metrics related to the BufferPool
> ---
>
> Key: CASSANDRA-15773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
>
> At this time there do not appear to be unit tests to validate
> {{BufferPoolMetrics}}.
--
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-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15776: -- Reviewers: Dinesh Joshi, Eduard Tudenhoefner, Michael Semb Wever (was: Dinesh Joshi) > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > Time Spent: 1.5h > Remaining Estimate: 0h > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle > CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] > and > [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). -- 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-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15776: -- Reviewers: Dinesh Joshi, Eduard Martinescu (was: Dinesh Joshi) > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > Time Spent: 1.5h > Remaining Estimate: 0h > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle > CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] > and > [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). -- 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-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15776: -- Reviewers: Dinesh Joshi (was: Dinesh Joshi, Eduard Martinescu) > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > Time Spent: 1.5h > Remaining Estimate: 0h > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle > CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] > and > [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). -- 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-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101930#comment-17101930 ] David Capwell commented on CASSANDRA-15776: --- [~djoshi] [~mck] [~eduard.tudenhoefner] can you review again? > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > Time Spent: 1.5h > Remaining Estimate: 0h > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle > CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] > and > [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). -- 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-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101929#comment-17101929 ] David Capwell commented on CASSANDRA-15776: --- Pushed change to truncate, this avoids all the needs to query and makes it so clusters with many tables are not impacted more. I deleted the functions which are now dead code, so only clear(keyspace, table) exists (needed when we drop a table) > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > Time Spent: 1h 20m > Remaining Estimate: 0h > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle > CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] > and > [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). -- 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-15776) python dtest regression caused by CASSANDRA-15637
[
https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101928#comment-17101928
]
Dinesh Joshi commented on CASSANDRA-15776:
--
[~dcapwell] Could you please ensure that you add a comment to the effect that
the values from {{table_estimates}} are supposed to override {{size_estimates}}?
> python dtest regression caused by CASSANDRA-15637
> -
>
> Key: CASSANDRA-15776
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15776
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.0-alpha
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to
> allow for local primary range estimates (needed for MapReduce). This appears
> to have caused a regression in the python dtest nodetool_test.TestNodetool.
> test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle
> CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests]
> and
> [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]).
--
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-15783) test_optimized_primary_range_repair - transient_replication_test.TestTransientReplication
[ https://issues.apache.org/jira/browse/CASSANDRA-15783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101925#comment-17101925 ] Ekaterina Dimitrova commented on CASSANDRA-15783: - [~jasonstack] The only reason I pointed to that ticket is to make our lives easier during the debugging of this test and to understand faster and better what is going on: - is it a bug? - is it a need of additional change? Thanks for your involvement, that helped! > test_optimized_primary_range_repair - > transient_replication_test.TestTransientReplication > - > > Key: CASSANDRA-15783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15783 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-alpha > > > Dtest failure. > Example: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/118/workflows/9e57522d-52fa-4d44-88d8-5cec0e87f517/jobs/585/tests -- 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-15262) server_encryption_options is not backwards compatible with 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-15262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101924#comment-17101924
]
Joey Lynch commented on CASSANDRA-15262:
Alright CI runs for:
*
[trunk|https://app.circleci.com/pipelines/github/jolynch/cassandra/14/workflows/e8af29fd-1232-43cf-85ad-f7539e16b301],
only two unrelated dtest failures.
*
[2.2|https://app.circleci.com/pipelines/github/jolynch/cassandra/16/workflows/e8b14e66-80fd-4574-9acd-9740e44dbd15]
has some errors, will double check they're unrelated
*
[3.0|https://app.circleci.com/pipelines/github/jolynch/cassandra/15/workflows/be9286c2-cb73-4ff2-9db2-394ee2251d6f]
has some errors, will double check they're unrelated.
I think this patch is ready for review. I've put code comments indicating where
we need to do more refactoring in the future tickets (specifically splitting
these classes and changing the names to be sensible, e.g. require_client_auth
is just odd in server options, but let's defer that work to beta or rc).
[~benedict] or [~e.dimitrova] please let me know if you have any feedback on
the patch (and dtest patch) as is.
> server_encryption_options is not backwards compatible with 3.11
> ---
>
> Key: CASSANDRA-15262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15262
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0, 4.0-alpha
>
>
> The current `server_encryption_options` configuration options are as follows:
> {noformat}
> server_encryption_options:
> # set to true for allowing secure incoming connections
> enabled: false
> # If enabled and optional are both set to true, encrypted and unencrypted
> connections are handled on the storage_port
> optional: false
> # if enabled, will open up an encrypted listening socket on
> ssl_storage_port. Should be used
> # during upgrade to 4.0; otherwise, set to false.
> enable_legacy_ssl_storage_port: false
> # on outbound connections, determine which type of peers to securely
> connect to. 'enabled' must be set to true.
> internode_encryption: none
> keystore: conf/.keystore
> keystore_password: cassandra
> truststore: conf/.truststore
> truststore_password: cassandra
> # More advanced defaults below:
> # protocol: TLS
> # store_type: JKS
> # cipher_suites:
> [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
> # require_client_auth: false
> # require_endpoint_verification: false
> {noformat}
> A couple of issues here:
> 1. optional defaults to false, which will break existing TLS configurations
> for (from what I can tell) no particularly good reason
> 2. The provided protocol and cipher suites are not good ideas (in particular
> encouraging anyone to use CBC ciphers is a bad plan
> I propose that before the 4.0 cut we fixup server_encryption_options and even
> client_encryption_options :
> # Change the default {{optional}} setting to true. As the new Netty code
> intelligently decides to open a TLS connection or not this is the more
> sensible default (saves operators a step while transitioning to TLS as well)
> # Update the defaults to what netty actually defaults to
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101923#comment-17101923 ] David Capwell commented on CASSANDRA-15776: --- Thought about it more, I can just truncate the table that avoids the query all together =D > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > Time Spent: 1h 20m > Remaining Estimate: 0h > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle > CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] > and > [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). -- 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-15685) flaky testWithMismatchingPending - org.apache.cassandra.distributed.test.PreviewRepairTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101922#comment-17101922
]
David Capwell commented on CASSANDRA-15685:
---
[~e.dimitrova] I stopped working on it as I lost my time =(. If you want, feel
free to pick it up! =D
The current state is that the test requires knowing the result of the previous
repair which only happens as a JMX notification, which is lossy; if the
notification is lost, the test fails.
I was planning to append the result to the completion message as we can get
that via polling, for this reason the test could not use the nodetool API but
would need to poll directly (which it does today). I also had a patch a bit
back to fix nodetool to detect failures in case of JMX loosing the error
message, this polling would need to do similar (so should probably be a common
function).
Now, the change to the completion message is better IMO since it also fixes
this for operators (if the notification is lost you don't know if there was a
conflict), since polling will also see the latest message and will report it
correctly.
For now I will unassigned myself.
> flaky testWithMismatchingPending -
> org.apache.cassandra.distributed.test.PreviewRepairTest
> --
>
> Key: CASSANDRA-15685
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15685
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Kevin Gallardo
>Assignee: David Capwell
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Observed in:
> https://app.circleci.com/pipelines/github/newkek/cassandra/34/workflows/1c6b157d-13c3-48a9-85fb-9fe8c153256b/jobs/191/tests
> Failure:
> {noformat}
> testWithMismatchingPending -
> org.apache.cassandra.distributed.test.PreviewRepairTest
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.distributed.test.PreviewRepairTest.testWithMismatchingPending(PreviewRepairTest.java:97)
> {noformat}
> [Circle
> CI|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FCASSANDRA-15685]
--
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-15685) flaky testWithMismatchingPending - org.apache.cassandra.distributed.test.PreviewRepairTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell reassigned CASSANDRA-15685:
-
Assignee: (was: David Capwell)
> flaky testWithMismatchingPending -
> org.apache.cassandra.distributed.test.PreviewRepairTest
> --
>
> Key: CASSANDRA-15685
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15685
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Kevin Gallardo
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0-alpha
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Observed in:
> https://app.circleci.com/pipelines/github/newkek/cassandra/34/workflows/1c6b157d-13c3-48a9-85fb-9fe8c153256b/jobs/191/tests
> Failure:
> {noformat}
> testWithMismatchingPending -
> org.apache.cassandra.distributed.test.PreviewRepairTest
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.distributed.test.PreviewRepairTest.testWithMismatchingPending(PreviewRepairTest.java:97)
> {noformat}
> [Circle
> CI|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FCASSANDRA-15685]
--
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-15783) test_optimized_primary_range_repair - transient_replication_test.TestTransientReplication
[ https://issues.apache.org/jira/browse/CASSANDRA-15783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101916#comment-17101916 ] Ekaterina Dimitrova commented on CASSANDRA-15783: - [~djoshi] thanks, that was my point. If that is fine we have to add testing for the second strategy in that case and leave the current test as a correct behavior. I can look at it on Monday if no one else get to it until then. (I'll be off tomorrow) > test_optimized_primary_range_repair - > transient_replication_test.TestTransientReplication > - > > Key: CASSANDRA-15783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15783 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-alpha > > > Dtest failure. > Example: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/118/workflows/9e57522d-52fa-4d44-88d8-5cec0e87f517/jobs/585/tests -- 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-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101910#comment-17101910 ] David Capwell commented on CASSANDRA-15776: --- [~mck] thanks for running through Jenkins! * [~mck] yes, the cost of the function goes up since its now two queries rather than one; not sure if its avoidable sadly... =( * [~djoshi] [~eduard.tudenhoefner] replied in GitHub. The function doesn't get the estimates, it only gets the keyspace/table names, and uses a set to dedup so its fine if they conflict (and expected to 99% of the time). > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > Time Spent: 1h 20m > Remaining Estimate: 0h > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle > CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] > and > [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). -- 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-15783) test_optimized_primary_range_repair - transient_replication_test.TestTransientReplication
[ https://issues.apache.org/jira/browse/CASSANDRA-15783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101897#comment-17101897 ] Dinesh Joshi edited comment on CASSANDRA-15783 at 5/7/20, 5:20 PM: --- CASSANDRA-15793 is resolved. So we shouldn't get the Transient Replication related warnings. We should also update this dtest to test with both LCS and STCS to ensure we cover both strategies going forward. FTR from the logs it seems that the SSTables are streamed to Node 2 but are immediately deleted. was (Author: djoshi3): CASSANDRA-15793 is resolved. So we shouldn't get the Transient Replication related warnings. We should also update this dtest to test with both LCS and STCS to ensure we cover both strategies going forward. > test_optimized_primary_range_repair - > transient_replication_test.TestTransientReplication > - > > Key: CASSANDRA-15783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15783 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-alpha > > > Dtest failure. > Example: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/118/workflows/9e57522d-52fa-4d44-88d8-5cec0e87f517/jobs/585/tests -- 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-15783) test_optimized_primary_range_repair - transient_replication_test.TestTransientReplication
[ https://issues.apache.org/jira/browse/CASSANDRA-15783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101897#comment-17101897 ] Dinesh Joshi commented on CASSANDRA-15783: -- CASSANDRA-15793 is resolved. So we shouldn't get the Transient Replication related warnings. We should also update this dtest to test with both LCS and STCS to ensure we cover both strategies going forward. > test_optimized_primary_range_repair - > transient_replication_test.TestTransientReplication > - > > Key: CASSANDRA-15783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15783 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-alpha > > > Dtest failure. > Example: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/118/workflows/9e57522d-52fa-4d44-88d8-5cec0e87f517/jobs/585/tests -- 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-15783) test_optimized_primary_range_repair - transient_replication_test.TestTransientReplication
[ https://issues.apache.org/jira/browse/CASSANDRA-15783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101887#comment-17101887 ] ZhaoYang edited comment on CASSANDRA-15783 at 5/7/20, 5:17 PM: --- [~bdeggleston] the streamed sstable is dropped by [transient replica|https://issues.apache.org/jira/browse/CASSANDRA-15783?focusedCommentId=17100449=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17100449] on node2 after CASSANDRA-15657.. I didn't check node3.. I don't think it's caused by 15657 which just makes ZCS more efficient and allows ZCS for tables with non-leveled-compaction strategy. The test failure can be reproduced with leveled-compaction strategy without 15657 (ZCS will be used). I might be able to look at it next 1~2 week.. was (Author: jasonstack): [~bdeggleston] the streamed sstable is dropped by [transient replica|https://issues.apache.org/jira/browse/CASSANDRA-15783?focusedCommentId=17100449=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17100449] on node2 after CASSANDRA-15657.. I didn't check node3.. I don't think it's caused by 15657 which just makes ZCS more efficient and allows ZCS for tables with non-leveled-compaction strategy. The test failure can be reproduced with leveled-compaction strategy without 15657. I might be able to look at it next 1~2 week.. > test_optimized_primary_range_repair - > transient_replication_test.TestTransientReplication > - > > Key: CASSANDRA-15783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15783 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-alpha > > > Dtest failure. > Example: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/118/workflows/9e57522d-52fa-4d44-88d8-5cec0e87f517/jobs/585/tests -- 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-15783) test_optimized_primary_range_repair - transient_replication_test.TestTransientReplication
[ https://issues.apache.org/jira/browse/CASSANDRA-15783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101887#comment-17101887 ] ZhaoYang edited comment on CASSANDRA-15783 at 5/7/20, 5:16 PM: --- [~bdeggleston] the streamed sstable is dropped by [transient replica|https://issues.apache.org/jira/browse/CASSANDRA-15783?focusedCommentId=17100449=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17100449] on node2 after CASSANDRA-15657.. I didn't check node3.. I don't think it's caused by 15657 which just makes ZCS more efficient and allows ZCS for tables with non-leveled-compaction strategy. The test failure can be reproduced with leveled-compaction strategy without 15657. I might be able to look at it next 1~2 week.. was (Author: jasonstack): [~bdeggleston] the streamed sstable is dropped by transient replica on node2 after CASSANDRA-15657.. I didn't check node3.. I don't think it's caused by 15657 which just makes ZCS more efficient and allows ZCS for tables with non-leveled-compaction strategy. The test failure can be reproduced with leveled-compaction strategy without 15657. I might be able to look at it next 1~2 week.. > test_optimized_primary_range_repair - > transient_replication_test.TestTransientReplication > - > > Key: CASSANDRA-15783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15783 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-alpha > > > Dtest failure. > Example: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/118/workflows/9e57522d-52fa-4d44-88d8-5cec0e87f517/jobs/585/tests -- 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-15773) Add test to cover metrics related to the BufferPool
[
https://issues.apache.org/jira/browse/CASSANDRA-15773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101895#comment-17101895
]
Stephen Mallette commented on CASSANDRA-15773:
--
{{assertThatThrownBy()}} is better - should have thought of that. done
> Add test to cover metrics related to the BufferPool
> ---
>
> Key: CASSANDRA-15773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
>
> At this time there do not appear to be unit tests to validate
> {{BufferPoolMetrics}}.
--
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-15783) test_optimized_primary_range_repair - transient_replication_test.TestTransientReplication
[ https://issues.apache.org/jira/browse/CASSANDRA-15783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101887#comment-17101887 ] ZhaoYang edited comment on CASSANDRA-15783 at 5/7/20, 5:03 PM: --- [~bdeggleston] the streamed sstable is dropped by transient replica on node2 after CASSANDRA-15657.. I didn't check node3.. I don't think it's caused by 15657 which just makes ZCS more efficient and allows ZCS for tables with non-leveled-compaction strategy. The test failure can be reproduced with leveled-compaction strategy without 15657. I might be able to look at it next 1~2 week.. was (Author: jasonstack): [~bdeggleston] the streamed sstable is dropped on node2 after CASSANDRA-15657.. I didn't check node3.. I don't think it's caused by 15657 which just makes ZCS more efficient and allows ZCS for tables with non-leveled-compaction strategy. The test failure can be reproduced with leveled-compaction strategy without 15657. I might be able to look at it next 1~2 week.. > test_optimized_primary_range_repair - > transient_replication_test.TestTransientReplication > - > > Key: CASSANDRA-15783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15783 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-alpha > > > Dtest failure. > Example: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/118/workflows/9e57522d-52fa-4d44-88d8-5cec0e87f517/jobs/585/tests -- 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-15773) Add test to cover metrics related to the BufferPool
[
https://issues.apache.org/jira/browse/CASSANDRA-15773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15773:
--
Status: Review In Progress (was: Changes Suggested)
> Add test to cover metrics related to the BufferPool
> ---
>
> Key: CASSANDRA-15773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
>
> At this time there do not appear to be unit tests to validate
> {{BufferPoolMetrics}}.
--
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-15773) Add test to cover metrics related to the BufferPool
[
https://issues.apache.org/jira/browse/CASSANDRA-15773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101888#comment-17101888
]
David Capwell commented on CASSANDRA-15773:
---
bq. I've initialized the test with a fixed size to the pool
Sorry, must have missed that.
bq. I might not understand something but I thought that this would prevent such
problems:
I most likely didn't look close enough, feel free to ignore me with regard to
leaking.
Thanks for the new failure tests!
*
https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15773-trunk#diff-790a43fcd6ed69f4122cd0fe205c847bR187-R198.
You could use
org.assertj.core.api.Assertions#assertThatThrownBy(org.assertj.core.api.ThrowableAssert.ThrowingCallable).
Other than that, this patch LGTM so I am +1. Ill run it through CI to make
sure its stable
> Add test to cover metrics related to the BufferPool
> ---
>
> Key: CASSANDRA-15773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
>
> At this time there do not appear to be unit tests to validate
> {{BufferPoolMetrics}}.
--
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-15783) test_optimized_primary_range_repair - transient_replication_test.TestTransientReplication
[ https://issues.apache.org/jira/browse/CASSANDRA-15783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101887#comment-17101887 ] ZhaoYang edited comment on CASSANDRA-15783 at 5/7/20, 5:02 PM: --- [~bdeggleston] the streamed sstable is dropped on node2 after CASSANDRA-15657.. I didn't check node3.. I don't think it's caused by 15657 which just makes ZCS more efficient and allows ZCS for tables with non-leveled-compaction strategy. The test failure can be reproduced with leveled-compaction strategy without 15657. I might be able to look at it next 1~2 week.. was (Author: jasonstack): [~bdeggleston] the streamed sstable is dropped on node2 after CASSANDRA-15657.. I didn't check node3.. I don't think it's caused by 15657 which just makes ZCS more efficient and allows ZCS for tables with non-leveled-compaction strategy. The test failure can be reproduced with leveled-compaction strategy without 15657. I might be able to look at it next week.. > test_optimized_primary_range_repair - > transient_replication_test.TestTransientReplication > - > > Key: CASSANDRA-15783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15783 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-alpha > > > Dtest failure. > Example: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/118/workflows/9e57522d-52fa-4d44-88d8-5cec0e87f517/jobs/585/tests -- 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-15783) test_optimized_primary_range_repair - transient_replication_test.TestTransientReplication
[ https://issues.apache.org/jira/browse/CASSANDRA-15783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101887#comment-17101887 ] ZhaoYang edited comment on CASSANDRA-15783 at 5/7/20, 5:02 PM: --- [~bdeggleston] the streamed sstable is dropped on node2 after CASSANDRA-15657.. I didn't check node3.. I don't think it's caused by 15657 which just makes ZCS more efficient and allows ZCS for tables with non-leveled-compaction strategy. The test failure can be reproduced with leveled-compaction strategy without 15657. I might be able to look at it next week.. was (Author: jasonstack): [~bdeggleston] the streamed sstable is dropped on node2 after CASSANDRA-15657.. I don't think it's caused by 15657 which just makes ZCS more efficient and allows ZCS for tables with non-leveled-compaction strategy. The test failure can be reproduced with leveled-compaction strategy without 15657. I might be able to look at it next week.. > test_optimized_primary_range_repair - > transient_replication_test.TestTransientReplication > - > > Key: CASSANDRA-15783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15783 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-alpha > > > Dtest failure. > Example: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/118/workflows/9e57522d-52fa-4d44-88d8-5cec0e87f517/jobs/585/tests -- 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-15783) test_optimized_primary_range_repair - transient_replication_test.TestTransientReplication
[ https://issues.apache.org/jira/browse/CASSANDRA-15783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101887#comment-17101887 ] ZhaoYang commented on CASSANDRA-15783: -- [~bdeggleston] the streamed sstable is dropped on node2 after CASSANDRA-15657.. I don't think it's caused by 15657 which just makes ZCS more efficient and allows ZCS for tables with non-leveled-compaction strategy. The test failure can be reproduced with leveled-compaction strategy without 15657. I might be able to look at it next week.. > test_optimized_primary_range_repair - > transient_replication_test.TestTransientReplication > - > > Key: CASSANDRA-15783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15783 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-alpha > > > Dtest failure. > Example: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/118/workflows/9e57522d-52fa-4d44-88d8-5cec0e87f517/jobs/585/tests -- 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-15793) Update Python driver for cqlsh to 3.23
[ https://issues.apache.org/jira/browse/CASSANDRA-15793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-15793: - Source Control Link: https://github.com/apache/cassandra/commit/036750083ddbd10c34052e272e13e17b29a4eace Resolution: Fixed Status: Resolved (was: Ready to Commit) Thanks for the review [~e.dimitrova]. Committed. > Update Python driver for cqlsh to 3.23 > -- > > Key: CASSANDRA-15793 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15793 > Project: Cassandra > Issue Type: Task > Components: Legacy/Tools >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Fix For: 4.0-alpha > > Attachments: image-2020-05-06-17-49-56-758.png > > > We should update cqlsh python driver to v3.23 which includes support for > transient replication and other fixes. -- 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: Update Python driver for cqlsh to 3.23
This is an automated email from the ASF dual-hosted git repository. djoshi 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 0367500 Update Python driver for cqlsh to 3.23 0367500 is described below commit 036750083ddbd10c34052e272e13e17b29a4eace Author: Dinesh A. Joshi AuthorDate: Wed May 6 16:26:14 2020 -0700 Update Python driver for cqlsh to 3.23 Patch by Dinesh Joshi; Reviewed by Ekaterina Dimitrova for CASSANDRA-15793 --- CHANGES.txt| 1 + ...driver-internal-only-3.23.0.post0-1a184b99.zip} | Bin 339123 -> 348039 bytes 2 files changed, 1 insertion(+) diff --git a/CHANGES.txt b/CHANGES.txt index 7f1930d..e617498 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 4.0-alpha5 + * Update to Python driver 3.23 for cqlsh (CASSANDRA-15793) * Add tunable initial size and growth factor to RangeTombstoneList (CASSANDRA-15763) * Improve debug logging in SSTableReader for index summary (CASSANDRA-15755) * bin/sstableverify should support user provided token ranges (CASSANDRA-15753) diff --git a/lib/cassandra-driver-internal-only-3.21.0.post0-05fb2c8d.zip b/lib/cassandra-driver-internal-only-3.23.0.post0-1a184b99.zip similarity index 50% rename from lib/cassandra-driver-internal-only-3.21.0.post0-05fb2c8d.zip rename to lib/cassandra-driver-internal-only-3.23.0.post0-1a184b99.zip index 59e1654..9b25bc1 100644 Binary files a/lib/cassandra-driver-internal-only-3.21.0.post0-05fb2c8d.zip and b/lib/cassandra-driver-internal-only-3.23.0.post0-1a184b99.zip differ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15783) test_optimized_primary_range_repair - transient_replication_test.TestTransientReplication
[ https://issues.apache.org/jira/browse/CASSANDRA-15783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101864#comment-17101864 ] Blake Eggleston commented on CASSANDRA-15783: - This looks like a legit regression. If this is definitely caused by CASSANDRA-15657, then it's probably broken streaming and sstables are not being streamed to node 2 when then should be. [~jasonstack] are you seeing the sstable getting dropped on node 2 or 3? > test_optimized_primary_range_repair - > transient_replication_test.TestTransientReplication > - > > Key: CASSANDRA-15783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15783 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-alpha > > > Dtest failure. > Example: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/118/workflows/9e57522d-52fa-4d44-88d8-5cec0e87f517/jobs/585/tests -- 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-15757) CustomIndexTest.indexBuildingPagesLargePartitions is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-15757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-15757:
--
Fix Version/s: 3.11.7
3.0.21
Since Version: 3.0.21
Source Control Link:
[f858a800f05d33679b2bce2a08a701b5e61f36bc|https://github.com/apache/cassandra/commit/f858a800f05d33679b2bce2a08a701b5e61f36bc]
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> CustomIndexTest.indexBuildingPagesLargePartitions is flaky
> --
>
> Key: CASSANDRA-15757
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15757
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.21, 3.11.7, 4.0-alpha
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> CustomIndexTest.indexBuildingPagesLargePartitions is flaky. Failed in CI and
> was able to reproduce failure inside IntelliJ by setting test Repeat to ‘Run
> Until Failure’. Failed after 459 iterations.
> {code}
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.cassandra.index.CustomIndexTest.lambda$indexBuildingPagesLargePartitions$1(CustomIndexTest.java:687)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> at
> org.apache.cassandra.index.CustomIndexTest.indexBuildingPagesLargePartitions(CustomIndexTest.java:687)
> at jdk.internal.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:53)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15757) CustomIndexTest.indexBuildingPagesLargePartitions is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-15757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101849#comment-17101849
]
Andres de la Peña commented on CASSANDRA-15757:
---
Thanks for the review, committed to 3.0 as
[f858a800f05d33679b2bce2a08a701b5e61f36bc|https://github.com/apache/cassandra/commit/f858a800f05d33679b2bce2a08a701b5e61f36bc]
and merged up without conflicts to
[3.11|https://github.com/apache/cassandra/commit/b9de3f60f0a9b895757a2a414ec80a3cdac396e0]
and
[trunk|https://github.com/apache/cassandra/commit/ba508d009727bd4f6a9c80096b65888abafefa65].
> CustomIndexTest.indexBuildingPagesLargePartitions is flaky
> --
>
> Key: CASSANDRA-15757
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15757
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-alpha
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> CustomIndexTest.indexBuildingPagesLargePartitions is flaky. Failed in CI and
> was able to reproduce failure inside IntelliJ by setting test Repeat to ‘Run
> Until Failure’. Failed after 459 iterations.
> {code}
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.cassandra.index.CustomIndexTest.lambda$indexBuildingPagesLargePartitions$1(CustomIndexTest.java:687)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> at
> org.apache.cassandra.index.CustomIndexTest.indexBuildingPagesLargePartitions(CustomIndexTest.java:687)
> at jdk.internal.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:53)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated: Fix flaky test CustomIndexTest#indexBuildingPagesLargePartitions
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
new f858a80 Fix flaky test
CustomIndexTest#indexBuildingPagesLargePartitions
f858a80 is described below
commit f858a800f05d33679b2bce2a08a701b5e61f36bc
Author: Andrés de la Peña
AuthorDate: Thu May 7 17:14:57 2020 +0100
Fix flaky test CustomIndexTest#indexBuildingPagesLargePartitions
patch by Andres de la Peña; reviewed by Berenguer Blasi for CASSANDRA-15757
---
test/unit/org/apache/cassandra/index/CustomIndexTest.java | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/test/unit/org/apache/cassandra/index/CustomIndexTest.java
b/test/unit/org/apache/cassandra/index/CustomIndexTest.java
index dcd6d34..1ab08fd 100644
--- a/test/unit/org/apache/cassandra/index/CustomIndexTest.java
+++ b/test/unit/org/apache/cassandra/index/CustomIndexTest.java
@@ -684,7 +684,11 @@ public class CustomIndexTest extends CQLTester
assertTrue(index.writeGroups.size() > 1);
assertFalse(index.readOrderingAtFinish.isBlocking());
index.writeGroups.forEach(group -> assertFalse(group.isBlocking()));
-index.barriers.forEach(b -> assertTrue(b.getSyncPoint().isFinished()));
+index.readBarriers.forEach(b ->
assertTrue(b.getSyncPoint().isFinished()));
+index.writeBarriers.forEach(b -> {
+b.await(); // Keyspace.writeOrder is global, so this might be
temporally blocked by other tests
+assertTrue(b.getSyncPoint().isFinished());
+});
}
@Test
@@ -1054,7 +1058,8 @@ public class CustomIndexTest extends CQLTester
OpOrder.Group readOrderingAtStart = null;
OpOrder.Group readOrderingAtFinish = null;
Set writeGroups = new HashSet<>();
-List barriers = new ArrayList<>();
+List readBarriers = new ArrayList<>();
+List writeBarriers = new ArrayList<>();
static final int ROWS_IN_PARTITION = 1000;
@@ -1099,10 +1104,10 @@ public class CustomIndexTest extends CQLTester
// indexing of a partition
OpOrder.Barrier readBarrier =
baseCfs.readOrdering.newBarrier();
readBarrier.issue();
-barriers.add(readBarrier);
+readBarriers.add(readBarrier);
OpOrder.Barrier writeBarrier =
Keyspace.writeOrder.newBarrier();
writeBarrier.issue();
-barriers.add(writeBarrier);
+writeBarriers.add(writeBarrier);
}
public void insertRow(Row row)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (80cade1 -> ba508d0)
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 80cade1 Merge branch 'cassandra-3.11' into trunk new f858a80 Fix flaky test CustomIndexTest#indexBuildingPagesLargePartitions new b9de3f6 Merge branch 'cassandra-3.0' into cassandra-3.11 new ba508d0 Merge branch 'cassandra-3.11' into trunk The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: test/unit/org/apache/cassandra/index/CustomIndexTest.java | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit b9de3f60f0a9b895757a2a414ec80a3cdac396e0 Merge: 01cf685 f858a80 Author: Andrés de la Peña AuthorDate: Thu May 7 17:15:15 2020 +0100 Merge branch 'cassandra-3.0' into cassandra-3.11 test/unit/org/apache/cassandra/index/CustomIndexTest.java | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (01cf685 -> b9de3f6)
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 01cf685 Merge branch 'cassandra-3.0' into cassandra-3.11 new f858a80 Fix flaky test CustomIndexTest#indexBuildingPagesLargePartitions new b9de3f6 Merge branch 'cassandra-3.0' into cassandra-3.11 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: test/unit/org/apache/cassandra/index/CustomIndexTest.java | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. adelapena pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit ba508d009727bd4f6a9c80096b65888abafefa65 Merge: 80cade1 b9de3f6 Author: Andrés de la Peña AuthorDate: Thu May 7 17:15:23 2020 +0100 Merge branch 'cassandra-3.11' into trunk test/unit/org/apache/cassandra/index/CustomIndexTest.java | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15797) Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-15797:
-
Bug Category: Parent values: Code(13163)Level 1 values: Bug - Unclear
Impact(13164)
Complexity: Normal
Component/s: Test/unit
Discovered By: Unit Test
Fix Version/s: 4.0-alpha
Severity: Normal
Status: Open (was: Triage Needed)
> Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
> ---
>
> Key: CASSANDRA-15797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15797
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> An internal CI system is failing BinLogTest somewhat frequently under JDK11.
> Configuration was recently changed to reduce the number of cores the tests
> run with, however it is reproducible on an 8 core laptop.
> {code}
> [junit-timeout] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC
> was deprecated in version 9.0 and will likely be removed in a future release.
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [Junit-timeout] WARNING: An illegal reflective access operation has occurred
> [junit-timeout] WARNING: Illegal reflective access by
> net.openhft.chronicle.core.Jvm (file:/.../lib/chronicle-core-1.16.4.jar) to
> field java.nio.Bits.RESERVED_MEMORY
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.895 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testPutAfterStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected: but
> was:
> [junit-timeout] junit.framework.AssertionFailedError: expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testPutAfterStop(BinLogTest.java:431)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> There's also a different failure under JDK8
> {code}
> junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 15.273 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testBinLogStartStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected:<2> but was:<0>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<2> but was:<0>
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testBinLogStartStop(BinLogTest.java:172)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> Reproducer
> {code}
> PASSED=0; time { while ant testclasslist -Dtest.classlistprefix=unit
> -Dtest.classlistfile=<(echo
> org/apache/cassandra/utils/binlog/BinLogTest.java); do PASSED=$((PASSED+1));
> echo PASSED $PASSED; done }; echo FAILED after $PASSED runs.
> {code}
> In the last four attempts it has taken 31, 38, 27 and 10 rounds respectively
> under JDK11 and took 51 under JDK8 (about 15 minutes).
> I have not tried running in a cpu-limited container or anything like that yet.
> Additionally, this went past in the logs a few times (under JDK11). No idea
> if it's just an artifact of weird test setup, or something more serious.
> {code}
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.839 sec
> [junit-timeout]
> [junit-timeout] java.lang.Throwable: 1e53135d-main creation ref-count=1
>
[jira] [Created] (CASSANDRA-15797) Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
Jon Meredith created CASSANDRA-15797:
Summary: Fix flaky BinLogTest -
org.apache.cassandra.utils.binlog.BinLogTest
Key: CASSANDRA-15797
URL: https://issues.apache.org/jira/browse/CASSANDRA-15797
Project: Cassandra
Issue Type: Bug
Reporter: Jon Meredith
An internal CI system is failing BinLogTest somewhat frequently under JDK11.
Configuration was recently changed to reduce the number of cores the tests run
with, however it is reproducible on an 8 core laptop.
{code}
[junit-timeout] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was
deprecated in version 9.0 and will likely be removed in a future release.
[junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
[Junit-timeout] WARNING: An illegal reflective access operation has occurred
[junit-timeout] WARNING: Illegal reflective access by
net.openhft.chronicle.core.Jvm (file:/.../lib/chronicle-core-1.16.4.jar) to
field java.nio.Bits.RESERVED_MEMORY
[junit-timeout] WARNING: Please consider reporting this to the maintainers of
net.openhft.chronicle.core.Jvm
[junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
further illegal reflective access operations
[junit-timeout] WARNING: All illegal access operations will be denied in a
future release
[junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.895 sec
[junit-timeout]
[junit-timeout] Testcase:
testPutAfterStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
[junit-timeout] expected: but
was:
[junit-timeout] junit.framework.AssertionFailedError: expected: but
was:
[junit-timeout] at
org.apache.cassandra.utils.binlog.BinLogTest.testPutAfterStop(BinLogTest.java:431)
[junit-timeout] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit-timeout] at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit-timeout] at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit-timeout]
[junit-timeout]
[junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
{code}
There's also a different failure under JDK8
{code}
junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
[junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 15.273 sec
[junit-timeout]
[junit-timeout] Testcase:
testBinLogStartStop(org.apache.cassandra.utils.binlog.BinLogTest):FAILED
[junit-timeout] expected:<2> but was:<0>
[junit-timeout] junit.framework.AssertionFailedError: expected:<2> but was:<0>
[junit-timeout] at
org.apache.cassandra.utils.binlog.BinLogTest.testBinLogStartStop(BinLogTest.java:172)
[junit-timeout]
[junit-timeout]
[junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
{code}
Reproducer
{code}
PASSED=0; time { while ant testclasslist -Dtest.classlistprefix=unit
-Dtest.classlistfile=<(echo org/apache/cassandra/utils/binlog/BinLogTest.java);
do PASSED=$((PASSED+1)); echo PASSED $PASSED; done }; echo FAILED after $PASSED
runs.
{code}
In the last four attempts it has taken 31, 38, 27 and 10 rounds respectively
under JDK11 and took 51 under JDK8 (about 15 minutes).
I have not tried running in a cpu-limited container or anything like that yet.
Additionally, this went past in the logs a few times (under JDK11). No idea if
it's just an artifact of weird test setup, or something more serious.
{code}
[junit-timeout] WARNING: Please consider reporting this to the maintainers of
net.openhft.chronicle.core.Jvm
[junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
further illegal reflective access operations
[junit-timeout] WARNING: All illegal access operations will be denied in a
future release
[junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.839 sec
[junit-timeout]
[junit-timeout] java.lang.Throwable: 1e53135d-main creation ref-count=1
[junit-timeout] at
net.openhft.chronicle.core.ReferenceCounter.newRefCountHistory(ReferenceCounter.java:45)
[junit-timeout] at
net.openhft.chronicle.core.ReferenceCounter.(ReferenceCounter.java:35)
[junit-timeout] at
net.openhft.chronicle.core.ReferenceCounter.onReleased(ReferenceCounter.java:40)
[junit-timeout] at
net.openhft.chronicle.bytes.AbstractBytes.(AbstractBytes.java:38)
[junit-timeout] at
net.openhft.chronicle.bytes.MappedBytes.(MappedBytes.java:59)
[junit-timeout] at
net.openhft.chronicle.bytes.MappedBytes.(MappedBytes.java:55)
[junit-timeout] at
net.openhft.chronicle.bytes.MappedBytes.mappedBytes(MappedBytes.java:113)
[jira] [Updated] (CASSANDRA-15793) Update Python driver for cqlsh to 3.23
[ https://issues.apache.org/jira/browse/CASSANDRA-15793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15793: Status: Ready to Commit (was: Review In Progress) > Update Python driver for cqlsh to 3.23 > -- > > Key: CASSANDRA-15793 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15793 > Project: Cassandra > Issue Type: Task > Components: Legacy/Tools >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Fix For: 4.0-alpha > > Attachments: image-2020-05-06-17-49-56-758.png > > > We should update cqlsh python driver to v3.23 which includes support for > transient replication and other fixes. -- 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-15793) Update Python driver for cqlsh to 3.23
[ https://issues.apache.org/jira/browse/CASSANDRA-15793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101812#comment-17101812 ] Ekaterina Dimitrova commented on CASSANDRA-15793: - LGTM, thanks [~djoshi] The only issue is I am not a committer :-) > Update Python driver for cqlsh to 3.23 > -- > > Key: CASSANDRA-15793 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15793 > Project: Cassandra > Issue Type: Task > Components: Legacy/Tools >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Fix For: 4.0-alpha > > Attachments: image-2020-05-06-17-49-56-758.png > > > We should update cqlsh python driver to v3.23 which includes support for > transient replication and other fixes. -- 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-15793) Update Python driver for cqlsh to 3.23
[ https://issues.apache.org/jira/browse/CASSANDRA-15793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15793: Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina Dimitrova) Ekaterina Dimitrova, Ekaterina Dimitrova Status: Review In Progress (was: Patch Available) > Update Python driver for cqlsh to 3.23 > -- > > Key: CASSANDRA-15793 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15793 > Project: Cassandra > Issue Type: Task > Components: Legacy/Tools >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Fix For: 4.0-alpha > > Attachments: image-2020-05-06-17-49-56-758.png > > > We should update cqlsh python driver to v3.23 which includes support for > transient replication and other fixes. -- 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-15783) test_optimized_primary_range_repair - transient_replication_test.TestTransientReplication
[ https://issues.apache.org/jira/browse/CASSANDRA-15783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101773#comment-17101773 ] Ekaterina Dimitrova commented on CASSANDRA-15783: - Thanks [~djoshi] I am trying to poke around now and check whether this is a correct behavior now or not. Want to be sure about that. > test_optimized_primary_range_repair - > transient_replication_test.TestTransientReplication > - > > Key: CASSANDRA-15783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15783 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-alpha > > > Dtest failure. > Example: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/118/workflows/9e57522d-52fa-4d44-88d8-5cec0e87f517/jobs/585/tests -- 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-15773) Add test to cover metrics related to the BufferPool
[
https://issues.apache.org/jira/browse/CASSANDRA-15773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101742#comment-17101742
]
Stephen Mallette commented on CASSANDRA-15773:
--
thanks [~djoshi]
> You're making gets of the same size. I feel randomizing the size of requested
> buffers would be better
> We should add negative test cases i.e. request buffers with bad sizes
I've made some adjustment there. Please let me know if that's in line with
what you were thinking.
> Add test to cover metrics related to the BufferPool
> ---
>
> Key: CASSANDRA-15773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
>
> At this time there do not appear to be unit tests to validate
> {{BufferPoolMetrics}}.
--
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-15792) test_speculative_data_request - read_repair_test.TestSpeculativeReadRepair
[ https://issues.apache.org/jira/browse/CASSANDRA-15792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianluca Righetto reassigned CASSANDRA-15792: - Assignee: Gianluca Righetto > test_speculative_data_request - read_repair_test.TestSpeculativeReadRepair > -- > > Key: CASSANDRA-15792 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15792 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Gianluca Righetto >Priority: Normal > Fix For: 4.0-alpha > > > Failing on the latest trunk here: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/127/workflows/dfba669d-4a5c-4553-b6a2-85647d0d8d2b/jobs/668/tests > Failing once in 30 times as per Jenkins: > https://jenkins-cm4.apache.org/job/Cassandra-trunk-dtest/69/testReport/dtest.read_repair_test/TestSpeculativeReadRepair/test_speculative_data_request/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15676) flaky test testWriteUnknownResult- org.apache.cassandra.distributed.test.CasWriteTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gianluca Righetto updated CASSANDRA-15676:
--
Test and Documentation Plan: Verify that
CasWriteTest::testWriteUnknownResult passes consistently now and doesn't throw
a timeout exception anymore.
Status: Patch Available (was: In Progress)
> flaky test testWriteUnknownResult-
> org.apache.cassandra.distributed.test.CasWriteTest
> -
>
> Key: CASSANDRA-15676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15676
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest
>Reporter: Kevin Gallardo
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Failure observed in:
> https://app.circleci.com/pipelines/github/newkek/cassandra/33/workflows/54007cf7-4424-4ec1-9655-665f6044e6d1/jobs/187/tests
> {noformat}
> testWriteUnknownResult - org.apache.cassandra.distributed.test.CasWriteTest
> junit.framework.AssertionFailedError: Expecting cause to be
> CasWriteUncertainException
> at
> org.apache.cassandra.distributed.test.CasWriteTest.testWriteUnknownResult(CasWriteTest.java:257)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
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-15676) flaky test testWriteUnknownResult- org.apache.cassandra.distributed.test.CasWriteTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101697#comment-17101697
]
Gianluca Righetto commented on CASSANDRA-15676:
---
The current implementation of this test is non-deterministic, it executes two
diverging compare-and-set statements in a while-true loop until it breaks
QUORUM. The issue is it may throw a WriteTimeoutException before that happens,
because the loop creates too many requests. At the time this ticket was opened,
the timeout exception was masked due to a poor assert statement, but that
specifically has been addressed already.
Another issue was that the generated PK for the INSERT statements was non-final
in the test method, it was overwritten at every iteration of the loop, so
multiple threads would see only the last assigned value of the PK, which
contributed to the overhead.
I have re-written the test to make it deterministic. Now it will intercept the
{{PAXOS_PROPOSE_RSP}} messages from the nodes back to the coordinator and
replace them with failure responses, such that QUORUM is never reached and it
will throw the expected {{CasWriteUnknownResultException}}. This way it removes
the "chance" aspect, but still exercises the same code path (which is mostly
testing o.a.c.s.StorageProxy::cas).
[PR|https://github.com/grighetto/cassandra/pull/2]
[JVM 11
Tests|https://app.circleci.com/pipelines/github/grighetto/cassandra/17/workflows/f9930861-5765-469f-970e-d4cf6a08563b/jobs/91]
[JVM 8
Tests|https://app.circleci.com/pipelines/github/grighetto/cassandra/17/workflows/2cfc7b5f-6acc-420f-9fcd-ee4abfe3aa8a/jobs/92]
> flaky test testWriteUnknownResult-
> org.apache.cassandra.distributed.test.CasWriteTest
> -
>
> Key: CASSANDRA-15676
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15676
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest
>Reporter: Kevin Gallardo
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Failure observed in:
> https://app.circleci.com/pipelines/github/newkek/cassandra/33/workflows/54007cf7-4424-4ec1-9655-665f6044e6d1/jobs/187/tests
> {noformat}
> testWriteUnknownResult - org.apache.cassandra.distributed.test.CasWriteTest
> junit.framework.AssertionFailedError: Expecting cause to be
> CasWriteUncertainException
> at
> org.apache.cassandra.distributed.test.CasWriteTest.testWriteUnknownResult(CasWriteTest.java:257)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
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-15748) Provide ability to configure IAuditLogger
[ https://issues.apache.org/jira/browse/CASSANDRA-15748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101648#comment-17101648 ] Marcus Eriksson commented on CASSANDRA-15748: - LGTM, +1 > Provide ability to configure IAuditLogger > - > > Key: CASSANDRA-15748 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15748 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 50m > Remaining Estimate: 0h > > Currently there is a parameterless constructor expected for IAuditLogger > instances. There is not any way how to "inject" configuration properties from > cassandra.yaml into these concrete classes. This would be very handy for > custom IAuditLogger implementations. > > PR: [https://github.com/apache/cassandra/pull/555] > [|https://github.com/smiklosovic/cassandra/tree/CASSANDRA-15748] -- 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-15759) Add progress column in percents for system_views.sstable_tasks
[
https://issues.apache.org/jira/browse/CASSANDRA-15759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-15759:
--
Test and Documentation Plan:
Status: Patch Available (was: Open)
[https://github.com/apache/cassandra/pull/566]
> Add progress column in percents for system_views.sstable_tasks
> --
>
> Key: CASSANDRA-15759
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15759
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It would be very handy to have a percentage column in
> system_views.sstable_tasks which would say how far a respective task is.
> Indeed, there are currently "progress" and "total" columns but honestly, for
> every day usage, it is rather strange to expect that humans will divide these
> numbers in head if they want to roughly know what the overall progress is.
> One just does not have a rough estimation of the task progress when he is
> presented with two quite big numbers and to estimate the progress from the.
> In the following output, the field "progress_in_percents" is introduced.
>
> PR is here [https://github.com/apache/cassandra/pull/566]
>
> {code:java}
> admin@cqlsh> select * from system_views.sstable_tasks ;
> @ Row 1
> ---+--
> keyspace_name | mykeyspace
> table_name| mytable
> task_id | 0db5d9b1-8726-11ea-8a6c-b92f3be367bb
> kind | secondary index build
> progress | 19456965
> progress_in_percents | 8.17
> total | 238208674
> unit | bytes
> @ Row 2
> --+--
> keyspace_name| mykeyspace
> table_name | mytable.mytable_surname_idx
> task_id | 1817ee71-8726-11ea-8a6c-b92f3be367bb
> kind | compaction
> progress | 284396233
> progress_in_percents | 75.92
> total| 374598446
> unit | bytes
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15759) Add progress column in percents for system_views.sstable_tasks
[
https://issues.apache.org/jira/browse/CASSANDRA-15759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-15759:
Change Category: Operability
Complexity: Normal
Status: Open (was: Triage Needed)
> Add progress column in percents for system_views.sstable_tasks
> --
>
> Key: CASSANDRA-15759
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15759
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It would be very handy to have a percentage column in
> system_views.sstable_tasks which would say how far a respective task is.
> Indeed, there are currently "progress" and "total" columns but honestly, for
> every day usage, it is rather strange to expect that humans will divide these
> numbers in head if they want to roughly know what the overall progress is.
> One just does not have a rough estimation of the task progress when he is
> presented with two quite big numbers and to estimate the progress from the.
> In the following output, the field "progress_in_percents" is introduced.
>
> PR is here [https://github.com/apache/cassandra/pull/566]
>
> {code:java}
> admin@cqlsh> select * from system_views.sstable_tasks ;
> @ Row 1
> ---+--
> keyspace_name | mykeyspace
> table_name| mytable
> task_id | 0db5d9b1-8726-11ea-8a6c-b92f3be367bb
> kind | secondary index build
> progress | 19456965
> progress_in_percents | 8.17
> total | 238208674
> unit | bytes
> @ Row 2
> --+--
> keyspace_name| mykeyspace
> table_name | mytable.mytable_surname_idx
> task_id | 1817ee71-8726-11ea-8a6c-b92f3be367bb
> kind | compaction
> progress | 284396233
> progress_in_percents | 75.92
> total| 374598446
> unit | bytes
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (18736b4 -> 01cf685)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 18736b4 Merge branch 'cassandra-3.0' into cassandra-3.11 new 1c898f9 ninja-fix: slackSend fix on `Jenkins Test Results Report in plaintext for ASF ML` new 8de45af Merge branch 'cassandra-2.2' into cassandra-3.0 new 01cf685 Merge branch 'cassandra-3.0' into cassandra-3.11 The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .jenkins/Jenkinsfile | 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
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 01cf685946fcfc1dea1ae6e608af74542a99b025 Merge: 18736b4 8de45af Author: Mick Semb Wever AuthorDate: Thu May 7 13:31:04 2020 +0200 Merge branch 'cassandra-3.0' into cassandra-3.11 .jenkins/Jenkinsfile | 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
[cassandra] branch trunk updated (d95aebe -> 80cade1)
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 d95aebe Merge branch 'cassandra-3.11' into trunk new 1c898f9 ninja-fix: slackSend fix on `Jenkins Test Results Report in plaintext for ASF ML` new 8de45af Merge branch 'cassandra-2.2' into cassandra-3.0 new 01cf685 Merge branch 'cassandra-3.0' into cassandra-3.11 new 80cade1 Merge branch 'cassandra-3.11' into trunk The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .jenkins/Jenkinsfile | 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
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 80cade176bce03bba06a60fcc692d509fe6f6bef Merge: d95aebe 01cf685 Author: Mick Semb Wever AuthorDate: Thu May 7 13:35:16 2020 +0200 Merge branch 'cassandra-3.11' into trunk .jenkins/Jenkinsfile | 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
[cassandra] branch cassandra-3.0 updated (b105e91 -> 8de45af)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from b105e91 liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if IndexSummaryRedistribution gets interrupted new 1c898f9 ninja-fix: slackSend fix on `Jenkins Test Results Report in plaintext for ASF ML` new 8de45af Merge branch 'cassandra-2.2' into cassandra-3.0 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .jenkins/Jenkinsfile | 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
[cassandra] 01/01: Merge branch 'cassandra-2.2' into cassandra-3.0
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 8de45af3f1a667a8183896e7e6d6af2db34715d1 Merge: b105e91 1c898f9 Author: Mick Semb Wever AuthorDate: Thu May 7 13:28:53 2020 +0200 Merge branch 'cassandra-2.2' into cassandra-3.0 .jenkins/Jenkinsfile | 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
[cassandra] branch cassandra-2.2 updated: ninja-fix: slackSend fix on `Jenkins Test Results Report in plaintext for ASF ML`
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch cassandra-2.2
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-2.2 by this push:
new 1c898f9 ninja-fix: slackSend fix on `Jenkins Test Results Report in
plaintext for ASF ML`
1c898f9 is described below
commit 1c898f9eb26b1342ab55c5dc26ca98cc44d35a75
Author: Mick Semb Wever
AuthorDate: Thu May 7 13:21:42 2020 +0200
ninja-fix: slackSend fix on `Jenkins Test Results Report in plaintext for
ASF ML`
---
.jenkins/Jenkinsfile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.jenkins/Jenkinsfile b/.jenkins/Jenkinsfile
index f7cbefc..932485cd 100644
--- a/.jenkins/Jenkinsfile
+++ b/.jenkins/Jenkinsfile
@@ -260,7 +260,7 @@ pipeline {
// the following should fail on any installation other than
builds.apache.org
// TODO: keep jenkins infrastructure related settings in
`cassandra_job_dsl_seed.groovy`
warnError('cannot send notifications') {
- slackSend channel: '#cassandra-builds', message: ":apache:
<${env.BUILD_URL}|${currentBuild.fullDisplayName}> completed:
${currentBuild.result}. ${env.GIT_COMMIT}\n${CHANGES}"
+ slackSend channel: '#cassandra-builds', message: ":apache:
<${env.BUILD_URL}|${currentBuild.fullDisplayName}> completed:
${currentBuild.result}. ${env.GIT_COMMIT}\n${currentBuild.changeSets}"
emailext to: 'bui...@cassandra.apache.org', subject: "Build
complete: ${currentBuild.fullDisplayName} [${currentBuild.result}]
${env.GIT_COMMIT}", body: '''
---
Build ${ENV,var="JOB_NAME"} #${BUILD_NUMBER} ${BUILD_STATUS}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15795) Cannot read data from a 3-node cluster which has two nodes down
[ https://issues.apache.org/jira/browse/CASSANDRA-15795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101560#comment-17101560 ] YCozy commented on CASSANDRA-15795: --- Kishan reported a similar issue. The test in 11804 is flaky, while I can always successfully reproduce this issue. And Kishan said 'I was able to repro on C* 3.5 but not in C* 3.6', but I find this bug in 3.11.6. So maybe it's a new issue? > Cannot read data from a 3-node cluster which has two nodes down > --- > > Key: CASSANDRA-15795 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15795 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip, Consistency/Coordination >Reporter: YCozy >Priority: Normal > > I start up a 3 nodes cluster, and write a row with 'replication_factor' : > '3'. The consistency level is ONE. > Then I kill two nodes, and try to get the row that I just inserted by cqlsh. > But cqlsh returns NoHostAvailable. > My Cassandra version is 3.11.6. -- 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-15674) liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if IndexSummaryRedistribution gets interrupted
[ https://issues.apache.org/jira/browse/CASSANDRA-15674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-15674: Since Version: 3.0.0 Source Control Link: https://github.com/apache/cassandra/commit/b105e919678240b5f448df9acaf6c93117f0c0cc Resolution: Fixed Status: Resolved (was: Ready to Commit) +1, committed, thanks > liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if > IndexSummaryRedistribution gets interrupted > - > > Key: CASSANDRA-15674 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15674 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction, Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > > IndexSummaryRedistribution is a compaction task and as such extends Holder > and supports cancelation by throwing a CompactionInterruptedException. The > issue is that IndexSummaryRedistribution tries to use transactions, but > mutates the sstable in-place; transaction is unable to roll back. > This would be fine (only updates summary) if it wasn’t for the fact the task > attempts to also mutate the two metrics liveDiskSpaceUsed and > totalDiskSpaceUsed, since these can’t be rolled back any cancelation could > corrupt these metrics. -- 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
