[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17475083#comment-17475083
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/13/22, 3:24 AM:
---------------------------------------------------------------------------
While rebasing and adding more parameters I hit a corner case, three duration
parameters without unit suffixes which I personally don't think they need name
change. That's fine. A converter was easy to add for them, BUT... what about
Virtual tables? In order to support backward compatibility we currently list
old parameters, those with new names are available in the old and the new form.
For example:
{code:java}
memtable_heap_space 2018MiB
meltable_heap_space_in_mb 2018
{code}
The parameters that I personally didn't find a reason to change names but only
the value formatting (adding the units to the value) are:
_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I
can easily say we introduce a breaking change and leave those alone in the new
format but I am open to hear also others' opinion. I feel I am getting too used
to this work and I might be missing something. Also, IMHO it's worth it not to
introduce breaking changes when/if possible.
In other news during the latest rebase and addition of parameters I found we
need to improve the precision for the _DataRateSpec._ I will publish this in a
separate patch soon, already handled.
I am doing last cleaning of tests and I will publish the final version with all
latest changes from November until now for the reviewers' consideration.
was (Author: e.dimitrova):
While rebasing and adding more parameters I hit a corner case, three duration
parameters without unit suffixes which I personally don't think they need name
change. That's fine. A converter was easy to add for them, BUT... what about
Virtual tables? In order to support backward compatibility we currently list
old parameters, those with new names are available in the old and the new form.
For example:
{code:java}
memtable_heap_space 2018MiB
meltable_heap_space_in_mb 2018
{code}
The parameters that I personally didn't find a reason to change names but only
the value formatting (adding the units to the value) are:
_key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I
can easily say we introduce a breaking change and leave those alone in the new
format but I am open to hear also others' opinion. I feel I am getting too used
to this work and I might be missing something. Also, IMHO it's worth it not to
introduce breaking changes when/if possible.
In other news during the latest rebase and addition of parameters I found we
need to improve the precision for the _DataRateSpec._ I will publish this in a
separate patch soon.
I am doing last cleaning of tests and I will publish the final version with all
latest changes from November until now for the reviewers' consideration.
> Standardise config and JVM parameters
> -------------------------------------
>
> Key: CASSANDRA-15234
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15234
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
> Reporter: Benedict Elliott Smith
> Assignee: Ekaterina Dimitrova
> Priority: Normal
> Fix For: 4.x
>
> Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt
>
>
> We have a bunch of inconsistent names and config patterns in the codebase,
> both from the yams and JVM properties. It would be nice to standardise the
> naming (such as otc_ vs internode_) as well as the provision of values with
> units - while maintaining perpetual backwards compatibility with the old
> parameter names, of course.
> For temporal units, I would propose parsing strings with suffixes of:
> {{code}}
> u|micros(econds?)?
> ms|millis(econds?)?
> s(econds?)?
> m(inutes?)?
> h(ours?)?
> d(ays?)?
> mo(nths?)?
> {{code}}
> For rate units, I would propose parsing any of the standard {{B/s, KiB/s,
> MiB/s, GiB/s, TiB/s}}.
> Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or
> powers of 1000 such as {{KB/s}}, given these are regularly used for either
> their old or new definition e.g. {{KiB/s}}, or we could support them and
> simply log the value in bytes/s.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
