[
https://issues.apache.org/jira/browse/CASSANDRA-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17597319#comment-17597319
]
David Capwell edited comment on CASSANDRA-17668 at 8/29/22 5:28 PM:
--------------------------------------------------------------------
The patch asks users to "migrate" to a new method that does the same thing but
fixes the bug... rather than asking users to migrate we should just fix the
bug... can we just catch ConfigurationException and throw the new exception
without changing the methods?
bq. The breaking change is one very valid point.
The examples found do not document this behavior, so we are not changing the
documented APIs but instead fixing a bug in JMX. There may be some users that
talk to JMX and can handle the ConfigurationException and check for it, so they
would no longer catch what they expect, but that was also an internal detail
that they are depending on... The only cases I remember where we asked users
to migrate to the new methods were when the methods actually documented this
behavior...
was (Author: dcapwell):
The patch asks users to "migrate" to a new method that does the same thing but
fixes the bug... rather than asking users to migrate we should just fix the
bug... can we just catch ConfigurationException and throw the new exception
without changing the methods?
> 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: [email protected]
For additional commands, e-mail: [email protected]
