[ 
https://issues.apache.org/jira/browse/CASSANDRA-17904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-17904:
------------------------------------------
    Description: 
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.


 

  was:
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 defaul, 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.


 


> 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

Reply via email to