[
https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687205#comment-17687205
]
David Capwell edited comment on CASSANDRA-15254 at 2/10/23 5:39 PM:
--------------------------------------------------------------------
bq. it's not 100% correct
I agree its not 100% correct (as I pointed out), but the inference method is
also not 100% correct... so I wouldn't reject it for not being 100% then use
another solution that is possibly equal or less correct... Also keep in mind
how do we maintain this solution. If I am adding a new config and want to make
it mutable, but do not want to add to JMX... do I now have to add to JMX to
trigger this inference system? Why do I need so much boiler plate?
Its also possible the best solution is a new annotation that denotes that the
config is "mutable", so the system can generate it for us... As an author I
strongly prefer the following methods over adding more boilerplate methods
{code}
public volatile boolean my_feature_enabled = false; // volatile makes this
mutable to settings table
@Mutable
public volatile boolean my_feature_enabled = false; // the annotation marks
this as mutable for the settings table.
@Immutable
public volatile boolean my_feature_enabled = false; // the annotation marks
this as immutable for the settings table.
@Internal
public volatile boolean my_feature_enabled = false; // the annotation tells the
settings table to hid this config... there be dragons!
{code}
bq. Take a look at the following example, the field has the volatile keyword,
but it must not be exposed to the public.
I actually don't think that example is bad to expose to users, and since its a
setter in DD wouldn't the existence also flag it to be exposed? So wouldn't
both solutions expose a config that you are saying shouldn't be exposed?
bq. Looking through the DatabaseDescriptor and GuardrailsOptions, they both
make configuration changes;
The API we expose to users is the yaml one, so must always be careful to only
use the naming/patterns from yaml and not internal types. We also must be
aware that our configs are nested, so the following cases should "just work"
{code}
replica_filtering_protection.cached_rows_warn_threshold = 2000;
replica_filtering_protection.cached_rows_fail_threshold = 32000;
{code}
If you look at our internal naming, those configs are here
{code}
public static int getCachedReplicaRowsWarnThreshold()
{
return conf.replica_filtering_protection.cached_rows_warn_threshold;
}
public static void setCachedReplicaRowsWarnThreshold(int threshold)
{
conf.replica_filtering_protection.cached_rows_warn_threshold =
threshold;
}
public static int getCachedReplicaRowsFailThreshold()
{
return conf.replica_filtering_protection.cached_rows_fail_threshold;
}
public static void setCachedReplicaRowsFailThreshold(int threshold)
{
conf.replica_filtering_protection.cached_rows_fail_threshold =
threshold;
}
{code}
so, w/e the solution is, it has to expose the config
"replica_filtering_protection.cached_rows_fail_threshold" and
"replica_filtering_protection.cached_rows_warn_threshold" and not the internal
names we use
was (Author: dcapwell):
bq. it's not 100% correct
I agree its not 100% correct (as I pointed out), but the inference method is
also not 100% correct... so I wouldn't reject it for not being 100% then use
another solution that is possibly equal or less correct... Also keep in mind
how do we maintain this solution. If I am adding a new config and want to make
it mutable, but do not want to add to JMX... do I now have to add to JMX to
trigger this inference system? Why do I need so much boiler plate?
Its also possible the best solution is a new annotation that denotes that the
config is "mutable", so the system can generate it for us... As an author I
strongly prefer the following 2 methods over adding more boilerplate methods
{code}
public volatile boolean my_feature_enabled = false; // volatile makes this
mutable to settings table
@Mutable
public volatile boolean my_feature_enabled = false; // the annotation marks
this as mutable for the settings table.
{code}
bq. Take a look at the following example, the field has the volatile keyword,
but it must not be exposed to the public.
I actually don't think that example is bad to expose to users, and since its a
setter in DD wouldn't the existence also flag it to be exposed? So wouldn't
both solutions expose a config that you are saying shouldn't be exposed?
bq. Looking through the DatabaseDescriptor and GuardrailsOptions, they both
make configuration changes;
The API we expose to users is the yaml one, so must always be careful to only
use the naming/patterns from yaml and not internal types. We also must be
aware that our configs are nested, so the following cases should "just work"
{code}
replica_filtering_protection.cached_rows_warn_threshold = 2000;
replica_filtering_protection.cached_rows_fail_threshold = 32000;
{code}
If you look at our internal naming, those configs are here
{code}
public static int getCachedReplicaRowsWarnThreshold()
{
return conf.replica_filtering_protection.cached_rows_warn_threshold;
}
public static void setCachedReplicaRowsWarnThreshold(int threshold)
{
conf.replica_filtering_protection.cached_rows_warn_threshold =
threshold;
}
public static int getCachedReplicaRowsFailThreshold()
{
return conf.replica_filtering_protection.cached_rows_fail_threshold;
}
public static void setCachedReplicaRowsFailThreshold(int threshold)
{
conf.replica_filtering_protection.cached_rows_fail_threshold =
threshold;
}
{code}
so, w/e the solution is, it has to expose the config
"replica_filtering_protection.cached_rows_fail_threshold" and
"replica_filtering_protection.cached_rows_warn_threshold" and not the internal
names we use
> Allow UPDATE on settings virtual table to change running configurations
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-15254
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15254
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
> Reporter: Chris Lohfink
> Assignee: Maxim Muzafarov
> Priority: Normal
> Attachments: Configuration Registry Diagram.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Allow using UPDATE on the system_views.settings virtual table to update
> configs at runtime for the equivalent of the dispersed JMX
> attributes/operations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
