[ 
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17598109#comment-17598109
 ] 

David Capwell commented on CASSANDRA-17668:
-------------------------------------------

bq. If it is only trunk  probably it is fine to just fix it there

If the concern is backwards compatibility then the arguments don't go away 
because its trunk... I am cool fixing or adding new and marking old as 
Deprecated; will leave it up to [~e.dimitrova] and [~lmtrombone].

bq.  I wanted to go for the deprecation because of the old versions

Well, I guess I would ask "when do we want to remove them?"  To me trunk is 
currently 4.2 so earliest we could drop is 5.0 (or was it 6.0? Forget exactly 
what we agreed in terms of minor and Deprecated)... back porting to add the 
Deprecated doesn't change that...

> 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
>
>          Time Spent: 20m
>  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

Reply via email to