[
https://issues.apache.org/jira/browse/CASSANDRA-17736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18072373#comment-18072373
]
Pedro Gordo edited comment on CASSANDRA-17736 at 4/9/26 4:29 PM:
-----------------------------------------------------------------
Updated the patch based on [~marcuse] feedback.
For FQL and audit logging, instead of updating Config when JMX setters are
called, the Settings Virtual Table now reads directly from the runtime
instances ({{{}FullQueryLogger.instance.getFullQueryLoggerOptions(){}}} and
{{{}AuditLogManager.instance.getAuditLogOptions(){}}}). Both already have
fallback logic that returns yaml defaults when disabled, so the VT
automatically reflects the active runtime state and reverts when the feature is
disabled — without needing to keep Config in sync.
On 4.1/trunk this is done via a {{resolveValue()}} method in {{SettingsTable}}
that intercepts FQL/audit properties and resolves them from the runtime
instances instead of from Config. On 4.0 the existing explicit handler methods
({{{}addAuditLoggingOptions{}}}, {{{}addFullQueryLoggingOptions{}}}) were
updated to read from the runtime instances.
Snitch/dynamic snitch still update Config directly (no runtime instance to read
from).
All three branches (4.0, 4.1, trunk) are consistent and tested.
----
was (Author: pedro_gordo):
Updated the patch based on Marcus's feedback on the trunk PR.
For FQL and audit logging, instead of updating Config when JMX setters are
called, the Settings Virtual Table now reads directly from the runtime
instances (\{{FullQueryLogger.instance.getFullQueryLoggerOptions()}} and
\{{AuditLogManager.instance.getAuditLogOptions()}}). Both already have fallback
logic that returns yaml defaults when disabled, so the VT automatically
reflects the active runtime state and reverts when the feature is disabled —
without needing to keep Config in sync.
On 4.1/trunk this is done via a \{{resolveValue()}} method in
\{{SettingsTable}} that intercepts FQL/audit properties and resolves them from
the runtime instances instead of from Config. On 4.0 the existing explicit
handler methods (\{{addAuditLoggingOptions}}, \{{addFullQueryLoggingOptions}})
were updated to read from the runtime instances.
Snitch/dynamic snitch still update Config directly (no runtime instance to read
from).
All three branches (4.0, 4.1, trunk) are consistent and tested.
----
> Settings Virtual Table should display the values assigned to a property in
> the DatabaseDescriptor on startup and not null (as per the yaml)
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-17736
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17736
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Local/Config
> Reporter: Ekaterina Dimitrova
> Assignee: Pedro Gordo
> Priority: Normal
> Fix For: 4.0.x, 4.1.x, 6.x
>
> Attachments: CASSANDRA-17736-audit.md
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> There are a few properties that after startup do not show their assigned
> values as per the DatabaseDescriptor assignment but the cassandra.yaml value.
> They will not be also updated in the virtual table down the road in case they
> are updated through JMX, nodetool etc.
> *EDIT: This ticket should serve to check the properties that are not type
> Duration, Data Storage and Data Rate; also that are not new to 4.1.* I will
> post a list of who are those later today for convenience. We target all those
> in Config class (some advanced properties are not broadly advertised in
> cassandra.yaml intentionally).
> There is [Settings Virtual Table
> |https://cassandra.apache.org/doc/trunk/cassandra/new/virtualtables.html#settings-virtual-table]
> which is supposed to show the values for our config parameters at any time.
> Especially useful if any property was changed after startup through
> JMX/nodetool and it doesn't match anymore the value in cassandra.yaml. For
> this to be possible, we need to ensure that the parameters are always updated
> in the Config class. It was observed that some are not always updating in
> Config class, but after startup delegating to other internal variables. This
> is a bug and this task should review and address any new findings.
> Classes of interest -
> [SettingsTable|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/virtual/SettingsTable.java]
> where you can see how config parameters are listed;
> [Config|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/Config.java]
> class where our configuration parameters are defined.
> We need patches 4.0 and above. I suggest you start looking into 4.0 branch
> and then merge into higher branches. As you won't be checking the data
> storage, data rate and duration type parameters, there shouldn't be many
> conflicts on merge.
> We have a lot of parameters and I suggest you split the list into batches to
> check and produce patches where/if needed to make the work more incremental
> and easier to work on and review it.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
