[ 
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 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

Reply via email to