[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089921#comment-17089921 ]
Michael Semb Wever commented on CASSANDRA-15234: ------------------------------------------------ After a chat with [~e.dimitrova] I understand the null issue a bit better now. In the current codebase the {{int}} properties can not be left blank, but it can be commented out. - A commented value means a default of {{0}} (though it will also report an error in system.log). - A blankĀ {{int}} property throws an exception. In this patch some of these {{int}} properties will become {{String}} properties. For example {{commitlog_sync_period_in_ms}} will become {{commitlog_sync_period}}, changing its type from {{int}} to {{String}}. The values will then permit unit suffixes, eg {{100ms}} and {{3s}}. These values still need to support the existing behaviour: blank throws an exception and commented out means zero. This is not possible with snakeyaml as, for {{String}} properties, both commented out and blank get interpreted as {{null}}. A suggestion to differentiate between a commented out {{String}} yaml property versus a blank {{String}} yaml property was to add a simple {{isPropertyBlank(name)}} method that performs a regular expression match against the plaintext of the yaml file. It is simple because the parsing of units suffix and {{int}} prefix happens in the C* code. The regexp match would then be: {{"^" + property + " *: *$"}} > 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