[
https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17684732#comment-17684732
]
Maxim Muzafarov commented on CASSANDRA-15254:
---------------------------------------------
[~blerer]
{quote}Just to make sure that we have all the same understanding. The plan is
only to allow setting the properties that can be set dynamically today (which
is a small subset of the properties), right? I have not checked but it might be
possible that some setters or getters are actually not used by JMX.
{quote}
This is a good comment. Yes, we will provide the same guarantees here as we do
today - changing only those properties through the SettingsTable that can
already be updated at runtime. Let's focus on the set of properties that can be
altered with JMX and provide a user ability to change the same set of
properties with SettingsTable, leaving the rest of the changeable set of
properties to another patch.
{quote}I am simply not sure that it is feasible in practice as setting the
property is also often only a minor part of the logic involved in changing a
configuration. Configuration are often use at start up to initialize some C*
components and in case of configuration update that component somehow need to
be modified in a non generic way. Up to now that logic was performed in the
different JMX implementation classes. Each of them was usually setting the
config parameter and then updating the impacted component that they were
managing.
{quote}
If I have understood your concerns correctly, the case you are talking about is
also handled by this solution with the subscription mechanism for a property
change event in the Registry. These listeners cover all the cases:
{code:java}
void onBeforeChange(String propertyName, T oldValue, T newValue);
void onAfterChange(String propertyName, T oldValue, T newValue);
{code}
Did I get your point right?
----
I'd also like to clarify my term _"auto-generated classes"_ for better
understanding. Such classes based on DatabaseDescriptor/GuardrailsOptions
metadata will not be generated every time on build or at runtime. I plan to
provide a util class that will create a new class body that implements all the
necessary interfaces (SetterWalker, GetterWalker) that we rely on and will be
committed as a regular class to remove the manual work of coupling a property
name with its getter/setter methods.
> 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]
