[
https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688015#comment-17688015
]
Maxim Muzafarov commented on CASSANDRA-15254:
---------------------------------------------
[~dcapwell] ,
I like the approach with the annotations you suggested. We can play with the
naming/quantity of annotations, for example, we can put everything we need
under a single annotation with different parameter types
Exposure(ExposurePolicy.READ), Exposure(ExposurePolicy.READ_WRITE),
Exposure(ExposurePolicy.INTERNAL). But at a high level, this approach will
definitely work and has advantages. I don't know why I didn't suggest this
option earlier, I was too afraid to make any changes to something as important
to the whole system as the Config class.
Another possible way to solve the "whether the field is modifiable at runtime
or not" problem we have discussed and what was shown in the PoC is to have
appropriate setters/getters in the DatabaseDescriptor (GuardrailsOptions) that
match the Config's field name of the camel case and filed type methods. This is
precisely what was shown in the pull request using the "cdc_block_writes" field
as an example, and assuming that instead of using the reflection (option #2) to
call the right field's setter method by matching the camel case method pattern,
we are using the generated "walkers" - helper classes (option #1) to call the
same setter method. In this case, the existence of the right patterned method
in DatabaseDescriptor by itself makes the field itself available for
modification with APIs.
Of course, setter methods that have the @VisibleForTesting annotation will be
filtered out of the result set of methods that might change configuration
fields. I also explicitly don't talk about the way nested configuration options
like the ReplicaFilteringProtectionOptions you mentioned will be handled, just
so as not to overload the discussion with too much detail and focus on a
high-level approach.
_As a summary of all that, we have two paths to go:_
- tag configuration fields with a dedicated annotation/annotations;
- add new setter methods matching camel case pattern in the DatabaseDescriptor
and others;
I'm happy going with annotations to solve the "is the field modifiable"
problem, annotations bring a lot less boilerplate code we could face either.
h4. The scope of the initial patch
This has been discussed implicitly (through several questions you've asked), so
I'd like to highlight it here again in different words. To make the first patch
observable, and to limit the number of changes to review, I want to break the
whole change into several small patches. We can go through each component from
the list one by one, applying the changes to each component and its associated
configuration properties.
We can take the list of all available components to change from the list of
MBean classes we have:
[https://github.com/Mmuzaf/cassandra/blob/cassandra-15254-wip/src/java/org/apache/cassandra/utils/AccessorFields.java#L142]
For example, we can take CommitLogMBean or StorageServiceMBean as a starting
point and move all the properties they can change to a new framework we
introduce here, changing the configuration setters they use accordingly.
h4. Minor questions
{quote}If a property name needs to be renamed, the auto-generated ConfigFields
will immediately show which other calls we should fix;
{quote}
That's what I mean. The ConfigFields class is a set of constants based on
Config's field names and is generated during the build. These constants are
used like this:
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/GuardrailsOptions.java#L300].
Because the ConfigFields are generated during the build, if we change the
Config's field name, the appropriate constant will disappear from the
ConfigFields class. This in turn will cause the build compilation to fail and
force us to change the constant where it was used so that we do not miss any
changes to Config's field names during renaming.
> 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]
