[
https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688065#comment-17688065
]
David Capwell commented on CASSANDRA-15254:
-------------------------------------------
bq. just so as not to overload the discussion with too much detail and focus
on a high-level approach.
The reason I focus on this is that we can't choose a solution without
understanding the impact on the system as a whole. If handling everything
properly requires a large, complex system, and/or more work on authors, then we
should be questioning if we could use a simpler solution.
Right now the getter/setter proposal is requiring a large, complex system, and
more verbosity for authors, that needs a lot more work to flesh out mappings
from config -> other accessors; right now I strongly question why bother going
down this road?
bq. I want to break the whole change into several small patches.
I think this gets back to my comment above, if we need to split this into
smaller patches to be manageable, then we should question this solution.
Looking at the domain this work is in, it has to do the following (anything
else becomes implementation detail)
* able to update DD's config object (capability exists today)
* make sure what is returned from the vtable is accepted by the vtable (this
isn't currently being focused on in this work)
* able to notify cases that need to know about config changes (patch handles
this via config listeners)
* able to know what is mutable
Given this, I don't think multiple patches is justifiable as the work should
not be too large.
bq. 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
I feel we shouldn't be changing JMX, this system should be able to live in
parallel to the JMX work and should not require everything goes through it.
For cases that need to "listen" to config changes, refactors will be required
to avoid duplication, but JMX should not be required to go through this system.
Your patch shows an example of this by having JMX call a new function that
took the old JMX logic out into a new method, and the config listener calls
this new function.
bq. The ConfigFields class is a set of constants based on Config's field names
and is generated during the build
I am neutral to this. the vtable wouldn't be using this, and normal code flow
wouldn't be using this, so I only see this impacting a very small set of cases
that "listen" to config changes. It would be nice to know we broke things at
compile time, but we also know if we broke things when we run tests as we
validate config changes are allowed or not (you can not remove configs without
going through our agreed on deprecation process, violations should be detected).
> 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]
