[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089105#comment-17089105
]
David Capwell commented on CASSANDRA-15234:
-------------------------------------------
Part 3 appears to be a mix of com.google.common.base.StandardSystemProperty,
JMX properties, and 3 Cassandra properties (focus on starting up; I know this
is showing the idea, so totally fine with this); how I read the class is as the
DatabaseDescriptor for system properties/env, is this the thinking?
I kinda feel that it would be best to split this in 3
1) guava's StandardSystemProperty, if there is anything missing, see #2
2) JavaProperties (not tied to a name, just a placeholder). This stores the
JMX and anything not in StandardSystemProperty
3) SysProperties. This manages Cassandra specific configs.
Im not tied to that so flexible if people only want one class to rule them
all...
For part 3 I am more curious on how this ties into part 1 and 2; prototype or
small informal writeup (1-2 sentences, just want to know your thinking) would
be good.
> 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.0, 4.0-beta
>
>
> 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.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
