[
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17603904#comment-17603904
]
Leonard Ma commented on CASSANDRA-17668:
----------------------------------------
As far as I can tell, I still think the failures are unassociated with my
changes. Here's what I found on the failures though:
The following tests has ticket associated with them
|| || ||
|dtest.configuration_test.TestConfiguration.test_change_durable_writes|https://issues.apache.org/jira/browse/CASSANDRA-17872|
|org.apache.cassandra.net.ConnectionTest.testMessageDeliveryOnReconnect-compression|https://issues.apache.org/jira/browse/CASSANDRA-16677|
|org.apache.cassandra.distributed.test.CASTest.testSucccessfulWriteDuringRangeMovementFollowedByRead
org.apache.cassandra.distributed.test.CASTest.testSuccessfulWriteBeforeRangeMovement
org.apache.cassandra.distributed.test.CASTest.testConflictingWritesWithStaleRingInformation|https://issues.apache.org/jira/browse/CASSANDRA-17461|
----
The following failures don't have tickets associated with them, but has been
marked flaky one way or another
|| || ||
|dtest.materialized_views_test.TestMaterializedViews.test_no_base_column_in_view_pk_complex_timestamp_with_flush|Consistently
passing on Cassandra CI and locally too, but apparently has a flaky annotation
added some time ago|
|org.apache.cassandra.net.ProxyHandlerConnectionsTest.testExpireSome-cdc|Has
'Flaky' tag on Butler and has history of flakiness|
----
The following failures don't have any markings on them, but in the test
results, it seems we might be running some of the tests twice? Not sure if
this is a sign of flakiness, since it's a sample size of 2. I was not able
find anything wrong from running them repeatedly locally either:
*
org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest.testMetricsWithRepairAndStreamingToTwoNodes
*
org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=3/v3]
*
org.apache.cassandra.distributed.test.repair.ForceRepairTest.forceWithDifference
!Screen Shot 2022-09-13 at 11.27.30 PM.png!
----
BinAuditLoggerTest.testSelectRoundTripQuery-compression - no idea at all. It
does seem to pass consistently locally too.
> Fix leak of non-standard Java types in our Exceptions as clients using JMX
> are unable to handle them
> ----------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-17668
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17668
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability, Observability/JMX
> Reporter: Ekaterina Dimitrova
> Assignee: Leonard Ma
> Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Attachments: Screen Shot 2022-09-13 at 11.27.30 PM.png
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> This is a continuation of CASSANDRA-17638 where we fixed leaks introduced
> during development of 4.1 to ensure no regressions.
> This ticket is to fix a few leakages which are there since previous major
> versions, not 4.1 regressions.
> {_}setRepairSessionMaxTreeDepth{_}(exists since 3.0) and
> _setRepairSessionSpaceInMegabytes(since 4.0)_
> in the DatabaseDescriptor.
> checkValidForByteConversion and _validateMaxConcurrentAutoUpgradeTasksConf
> (both since 4.0)_
> are used in both setters and on startup. They shouldn't throw
> ConfigurationException in the setters.
> There might be more but those are at least a few obvious I found in the
> DatabaseDescriptor.
> CC [~dcapwell]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
