[
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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: [email protected]
For additional commands, e-mail: [email protected]
