[jira] [Updated] (CASSANDRA-17804) AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically on missing stdout contents
[
https://issues.apache.org/jira/browse/CASSANDRA-17804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-17804:
Test and Documentation Plan: test fixed
Status: Patch Available (was: In Progress)
> AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically
> on missing stdout contents
> ---
>
> Key: CASSANDRA-17804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17804
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Caleb Rackliffe
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> See
> [https://app.circleci.com/pipelines/github/maedhroz/cassandra/487/workflows/0ad42210-2979-4c5d-a4e8-d8cedf9285a7/jobs/4686/tests#failed-test-0]
>
> My guess is that in some resource constrained environment, even the first
> {{nodeool listsnapshots}} invocation doesn’t have “dropped” in the stdout. In
> other words, we skip to the state of the world the last assertion in the test
> is checking.
--
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
[jira] [Commented] (CASSANDRA-17804) AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically on missing stdout contents
[
https://issues.apache.org/jira/browse/CASSANDRA-17804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579469#comment-17579469
]
Paulo Motta commented on CASSANDRA-17804:
-
This test makes the following assertions to ensure snapshots of dropped tables
are properly expired after a node restart when auto_snapshot_ttl=20s:
a) that a snapshot of a dropped table exists after a node restart
b) that the snapshot is gone after expiration (20s)
This test assumes that the restart will take less than auto_snapshot_ttl=20s.
If a restart takes longer than that then the snapshot is cleared as soon as the
node starts and the first assertion fails.
The trivial fix is to increase auto_snapshot_ttl=60s, in the hope that a
restart will never take longer than a minute and the first assertion will never
fail. Unfortunately this will make the test longer but a bit more deterministic.
* PR: https://github.com/apache/cassandra/pull/1789
* CI: https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1871/
> AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically
> on missing stdout contents
> ---
>
> Key: CASSANDRA-17804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17804
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Caleb Rackliffe
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 4.1-beta, 4.x
>
>
> See
> [https://app.circleci.com/pipelines/github/maedhroz/cassandra/487/workflows/0ad42210-2979-4c5d-a4e8-d8cedf9285a7/jobs/4686/tests#failed-test-0]
>
> My guess is that in some resource constrained environment, even the first
> {{nodeool listsnapshots}} invocation doesn’t have “dropped” in the stdout. In
> other words, we skip to the state of the world the last assertion in the test
> is checking.
--
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
[jira] [Updated] (CASSANDRA-17668) Fix leak of non-standard Java types in our Exceptions as clients using JMX are unable to handle them
[
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonard Ma updated CASSANDRA-17668:
---
Test and Documentation Plan: Test using JConsole
Status: Patch Available (was: In Progress)
> 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
>
>
> 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
[jira] [Comment Edited] (CASSANDRA-17668) Fix leak of non-standard Java types in our Exceptions as clients using JMX are unable to handle them
[
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579456#comment-17579456
]
Leonard Ma edited comment on CASSANDRA-17668 at 8/14/22 10:34 PM:
--
I believe I have a fix for this now -
[https://github.com/apache/cassandra/pull/1788] .
Some notes/observations:
* '{_}validateMaxConcurrentAutoUpgradeTasksConf{_} ' has been left alone as we
have some try catch logic for one of the functions that calls this and
'ConfigurationExceptions' will get converted to 'IllegalArgumentException'
* 'checkValidForByteConversion' seems to be used in tandem with the
constructor 'DataStorageSpec.IntKibibytesBound' for the jmx setters
** 'StorageService.setColumnIndexSize' (added in 4.1)
** 'StorageService.setColumnIndexCacheSize' (added in 4.0)
** 'StorageService.setBatchSizeWarnThreshold' (added in 4.0)
There were some recent changes to this constructor (
https://issues.apache.org/jira/browse/CASSANDRA-17571 ) in 4.1 that will cause
the aforementioned jmx setters to throw 'IllegalArgumentException' when certain
values are encountered. I was tempted to just modify
'checkValidForByteConversion' so it throws 'IllegalArgumentException' as this
will make my solution much simpler/cleaner and because it already throws it
elsewhere. However, for now I have opted to create new methods as from my
understanding, modifying the exceptions thrown is still a breaking change to
two of the APIs that have been released in 4.0.
was (Author: JIRAUSER292010):
I believe I have a fix for this now -
[https://github.com/apache/cassandra/pull/1788] .
Some notes/observations:
* '{_}validateMaxConcurrentAutoUpgradeTasksConf{_} ' has been left alone as we
have some try catch logic for one of the functions that calls this and
'ConfigurationExceptions' will get converted to 'IllegalArgumentException'
* 'checkValidForByteConversion' seems to be used in tandem with the
constructor 'DataStorageSpec.IntKibibytesBound' for the jmx setters -
'StorageService.setColumnIndexSize' (added in 4.1),
'StorageService.setColumnIndexCacheSize' (added in 4.0), and
'StorageService.setBatchSizeWarnThreshold' (added in 4.0)
There were some recent changes to this constructor (
https://issues.apache.org/jira/browse/CASSANDRA-17571 ) in 4.1 that will cause
the aforementioned jmx setters to throw 'IllegalArgumentException' when certain
values are encountered. I was tempted to just modify
'checkValidForByteConversion' so it throws 'IllegalArgumentException' as this
will make my solution much simpler/cleaner and because it already throws it
elsewhere. However, for now I have opted to create new methods as from my
understanding, modifying the exceptions thrown is still a breaking change to
two of the APIs that have been released in 4.0.
> 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
>
>
> 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
[jira] [Comment Edited] (CASSANDRA-17668) Fix leak of non-standard Java types in our Exceptions as clients using JMX are unable to handle them
[
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579456#comment-17579456
]
Leonard Ma edited comment on CASSANDRA-17668 at 8/14/22 10:33 PM:
--
I believe I have a fix for this now -
[https://github.com/apache/cassandra/pull/1788] .
Some notes/observations:
* '{_}validateMaxConcurrentAutoUpgradeTasksConf{_} ' has been left alone as we
have some try catch logic for one of the functions that calls this and
'ConfigurationExceptions' will get converted to 'IllegalArgumentException'
* 'checkValidForByteConversion' seems to be used in tandem with the
constructor 'DataStorageSpec.IntKibibytesBound' for the jmx setters -
'StorageService.setColumnIndexSize' (added in 4.1),
'StorageService.setColumnIndexCacheSize' (added in 4.0), and
'StorageService.setBatchSizeWarnThreshold' (added in 4.0)
There were some recent changes to this constructor (
https://issues.apache.org/jira/browse/CASSANDRA-17571 ) in 4.1 that will cause
the aforementioned jmx setters to throw 'IllegalArgumentException' when certain
values are encountered. I was tempted to just modify
'checkValidForByteConversion' so it throws 'IllegalArgumentException' as this
will make my solution much simpler/cleaner and because it already throws it
elsewhere. However, for now I have opted to create new methods as from my
understanding, modifying the exceptions thrown is still a breaking change to
two of the APIs that have been released in 4.0.
was (Author: JIRAUSER292010):
I believe I have a fix for this now -
[https://github.com/apache/cassandra/pull/1788] .
Some notes/observations:
* '{_}validateMaxConcurrentAutoUpgradeTasksConf{_} ' has been left alone as we
have some try catch logic for one of the functions that calls this and
'ConfigurationExceptions' will get converted to 'IllegalArgumentException'
* 'checkValidForByteConversion' seems to be used in tandem with the
constructor 'DataStorageSpec.IntKibibytesBound' for the following jmx setters:
*
-- 'StorageService.setColumnIndexSize' (added in 4.1)
-- 'StorageService.setColumnIndexCacheSize' (added in 4.0)
-- 'StorageService.setBatchSizeWarnThreshold' (added in 4.0)
There were some recent changes to this constructor (
https://issues.apache.org/jira/browse/CASSANDRA-17571 ) in 4.1 that will cause
the aforementioned jmx setters to throw 'IllegalArgumentException' when certain
values are encountered. I was tempted to just modify
'checkValidForByteConversion' so it throws 'IllegalArgumentException' as this
will make my solution much simpler/cleaner and because it already throws it
elsewhere. However, for now I have opted to create new methods as from my
understanding, modifying the exceptions thrown is still a breaking change to
two of the APIs that have been released in 4.0.
> 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
>
>
> 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
[jira] [Comment Edited] (CASSANDRA-17668) Fix leak of non-standard Java types in our Exceptions as clients using JMX are unable to handle them
[
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579456#comment-17579456
]
Leonard Ma edited comment on CASSANDRA-17668 at 8/14/22 10:33 PM:
--
I believe I have a fix for this now -
[https://github.com/apache/cassandra/pull/1788] .
Some notes/observations:
* '{_}validateMaxConcurrentAutoUpgradeTasksConf{_} ' has been left alone as we
have some try catch logic for one of the functions that calls this and
'ConfigurationExceptions' will get converted to 'IllegalArgumentException'
* 'checkValidForByteConversion' seems to be used in tandem with the
constructor 'DataStorageSpec.IntKibibytesBound' for the following jmx setters:
*
-- 'StorageService.setColumnIndexSize' (added in 4.1)
-- 'StorageService.setColumnIndexCacheSize' (added in 4.0)
-- 'StorageService.setBatchSizeWarnThreshold' (added in 4.0)
There were some recent changes to this constructor (
https://issues.apache.org/jira/browse/CASSANDRA-17571 ) in 4.1 that will cause
the aforementioned jmx setters to throw 'IllegalArgumentException' when certain
values are encountered. I was tempted to just modify
'checkValidForByteConversion' so it throws 'IllegalArgumentException' as this
will make my solution much simpler/cleaner and because it already throws it
elsewhere. However, for now I have opted to create new methods as from my
understanding, modifying the exceptions thrown is still a breaking change to
two of the APIs that have been released in 4.0.
was (Author: JIRAUSER292010):
I believe I have a fix for this now -
[https://github.com/apache/cassandra/pull/1788] .
Some notes/observations:
* '{_}validateMaxConcurrentAutoUpgradeTasksConf{_} ' has been left alone as we
have some try catch logic for one of the functions that calls this and
'ConfigurationExceptions' will get converted to 'IllegalArgumentException'
* 'checkValidForByteConversion' seems to be used in tandem with the
constructor 'DataStorageSpec.IntKibibytesBound' for the following jmx setters:
- 'StorageService.setColumnIndexSize' (added in 4.1)
- 'StorageService.setColumnIndexCacheSize' (added in 4.0)
- 'StorageService.setBatchSizeWarnThreshold' (added in 4.0)
There were some recent changes to this constructor (
https://issues.apache.org/jira/browse/CASSANDRA-17571 ) in 4.1 that will cause
the aforementioned jmx setters to throw 'IllegalArgumentException' when certain
values are encountered. I was tempted to just modify
'checkValidForByteConversion' so it throws 'IllegalArgumentException' as this
will make my solution much simpler/cleaner and because it already throws it
elsewhere. However, for now I have opted to create new methods as from my
understanding, modifying the exceptions thrown is still a breaking change to
two of the APIs that have been released in 4.0.
> 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
>
>
> 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
[jira] [Commented] (CASSANDRA-17668) Fix leak of non-standard Java types in our Exceptions as clients using JMX are unable to handle them
[
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579456#comment-17579456
]
Leonard Ma commented on CASSANDRA-17668:
I believe I have a fix for this now -
[https://github.com/apache/cassandra/pull/1788] .
Some notes/observations:
* '{_}validateMaxConcurrentAutoUpgradeTasksConf{_} ' has been left alone as we
have some try catch logic for one of the functions that calls this and
'ConfigurationExceptions' will get converted to 'IllegalArgumentException'
* 'checkValidForByteConversion' seems to be used in tandem with the
constructor 'DataStorageSpec.IntKibibytesBound' for the following jmx setters:
- 'StorageService.setColumnIndexSize' (added in 4.1)
- 'StorageService.setColumnIndexCacheSize' (added in 4.0)
- 'StorageService.setBatchSizeWarnThreshold' (added in 4.0)
There were some recent changes to this constructor (
https://issues.apache.org/jira/browse/CASSANDRA-17571 ) in 4.1 that will cause
the aforementioned jmx setters to throw 'IllegalArgumentException' when certain
values are encountered. I was tempted to just modify
'checkValidForByteConversion' so it throws 'IllegalArgumentException' as this
will make my solution much simpler/cleaner and because it already throws it
elsewhere. However, for now I have opted to create new methods as from my
understanding, modifying the exceptions thrown is still a breaking change to
two of the APIs that have been released in 4.0.
> 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
>
>
> 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
