[ https://issues.apache.org/jira/browse/CASSANDRA-17904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17606373#comment-17606373 ]
Ekaterina Dimitrova commented on CASSANDRA-17904: ------------------------------------------------- Thanks [~smiklosovic], those three are special case where only the value format was changed and their names were kept (the only 3 which had proper names and no unit as part of the name... ), that's why your valid observation - they emit deprecation warning even with the value being in the new format. You made me wonder whether it was worth it to special case them at all, I will take a look tomorrow. > 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 > Reporter: Stefan Miklosovic > Priority: Normal > > 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org