[
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17599573#comment-17599573
]
Ekaterina Dimitrova commented on CASSANDRA-17668:
-------------------------------------------------
It seems the decision will be on me, then trunk with deprecation and be nice to
our end users.
{quote}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...
{quote}
Very good question that I also struggle with sometimes... In general we would
say deprecate, keep in 5, remove in 6. Although, I see people keep on
deprecating and when it comes to just method or config parameter it seems they
prefer to keep it without deadline. So I am not sure. I guess in this case it
will depend until when we keep JMX around too. I guess that will be the main
guideline in this case.
> 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
