[
https://issues.apache.org/jira/browse/CASSANDRA-17904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606614#comment-17606614
]
Ekaterina Dimitrova edited comment on CASSANDRA-17904 at 9/19/22 2:10 PM:
--------------------------------------------------------------------------
Slept on it and had some discussion with [~marcuse] and [~dcapwell] about those
three parameters as I was wondering whether we missed to take some action
around them when we added the new flags - _allow_duplicate_config_keys_ and
_allow_new_old_config_keys_ in CASSANDRA-17379
The key names haven't been changed so we technically didn't deprecate the three
properties but we added an option to be able to add value both in numeric and
numeric+unit format.
The fix should be to make those not deprecated in the Replaces annotation. I
will add it soon. Also, I plan to add quick additional note in the config docs
to remind people that _allow_duplicate_config_keys_ is the only way to not be
able to add that property more than once with both formats; Those three are a
special case that is already mentioned in the docs but I think it will be nice
to stress on them when talking about the flags.
I will push a patch soon, thanks
was (Author: e.dimitrova):
Slept on it and had some discussion with [~marcuse] and [~dcapwell] about those
three parameters as I was wondering whether we missed to take some action
around them when we added the new flags - _allow_duplicate_config_keys_ and
_allow_new_old_config_keys_ in CASSANDRA-17379
The key names haven't been changed so we technically didn't deprecate the three
properties but we added an option to be able to add value both in numeric or
numeric+unit format.
The fix should be to make those not deprecated in the Replaces annotation. I
will add it soon. Also, I plan to add quick additional note in the config docs
to remind people that _allow_duplicate_config_keys_ is the only way to not be
able to add that property more than once with both formats; Those three are a
special case that is already mentioned in the docs but I think it will be nice
to stress on them when talking about the flags.
I will push a patch soon, thanks
> Consider to not warn about deprecated properties in logs when the value is
> not deprecated
> -----------------------------------------------------------------------------------------
>
> Key: CASSANDRA-17904
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17904
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
> Reporter: Stefan Miklosovic
> Assignee: Ekaterina Dimitrova
> Priority: Low
> Fix For: 4.1-rc, 4.x
>
>
> When there is an initialisation of database descriptor for tools, for example
> via "Util.initDatabaseDescriptor()", it will eventually buble up to
> "YamlConfigurationLoader.check" where this is logged:
> {code}
> if (!deprecationWarnings.isEmpty())
> logger.warn("{} parameters have been deprecated. They have new names and/or
> value format; For more information, please refer to NEWS.txt",
> deprecationWarnings);
> {code}
> For example, I saw this log:
> {code}
> WARN 09:07:42,486 [key_cache_save_period, counter_cache_save_period,
> row_cache_save_period] parameters have been deprecated. They have new names
> and/or value format; For more information, please refer to NEWS.txt
> {code}
> The "problems" I see are two:
> 1) it pollutes the console for tool commands, when a tool needs to initialise
> DD, at the very beginning of the output.
> 2) When you look closely, for example at key_cache_save_period, by default,
> in cassandra.yaml, it has value "4h". My question is: why is it necessary to
> mark that as deprecated when the value is already in new format? In other
> words, I would log that warning only in case that the expected value of a
> property is not in the new format. But when it already is, why do we need to
> inform a user about that?
> I think it would require to take some extra care for cases like these in
> YamlConfigurationLoader.getProperty to not add deprecated properties if their
> value is already new.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
