[
https://issues.apache.org/jira/browse/CASSANDRA-12661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965906#comment-15965906
]
Edward Capriolo commented on CASSANDRA-12661:
---------------------------------------------
{noformat}
it silently changes the default of gc_warn_threshold_in_ms from 0 to 1000
{noformat}
>From this one I do not believe this is the case. I believe the value was unset
>in the config but statically set in the class. So it had a default value but
>it was not supplied as thee other ones were.
{noformat}
due to the checks in the implementation, the order of calls to
setGcLogThresholdInMs + setGcWarnThresholdInMs depend on the current values,
which should not be the case. this could be changed by having just one method
that changes both values.
{noformat}
That was the idea because one can not be lower then the other. I can see how
this would be problematic.We could simply set both or silently raise the value
of one before the other. Or do what you suggest.
{noformat}
i’m missing a reason for the new if (!mbs.isRegistered(me)) and the other
change in the static initializer
{noformat}
Running unit tests bark about instance already being registered.
> Make gc_log and gc_warn settable at runtime
> -------------------------------------------
>
> Key: CASSANDRA-12661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12661
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Edward Capriolo
> Assignee: Edward Capriolo
> Priority: Minor
>
> Changes:
> * Move gc_log_threshold_in_ms and gc_warn_threshold_in_ms close together in
> the config
> * rename variables to match properties
> * add unit tests to ensure hybration
> * add unit tests to ensure variables are set propertly
> * minor perf (do not consturct string from buffer f not logging)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
