CRZbulabula opened a new pull request, #18091:
URL: https://github.com/apache/iotdb/pull/18091
## Motivation
While tidying the ConfigNode cluster-operations tunables, several parameters
were either exposed in the config template despite being advanced/experimental,
or documented as `restart`-only despite being safely applicable at runtime.
This PR:
1. **Hides** four advanced tunables (removes them from
`iotdb-system.properties.template`; they are still parsed with their
config-class defaults, matching the existing convention used by
`leader_distribution_policy` / `route_priority_policy`):
- `enable_auto_leader_balance_for_ratis_consensus`
- `enable_topology_probing`
- `topology_probing_base_interval_in_ms`
- `topology_probing_timeout_ratio`
2. **Makes hot-reloadable** (`effectiveMode: restart` → `hot_reload`, with
the runtime plumbing to actually apply the new value):
- `procedure_completed_evict_ttl`
- `procedure_completed_clean_interval`
- `disk_space_warning_threshold`
## Changes
### Procedure completed-cleaner hot reload
`procedure_completed_evict_ttl` and `procedure_completed_clean_interval` are
captured by `CompletedProcedureRecycler` at construction, so applying new
values requires rescheduling it:
- `ProcedureExecutor` keeps a reference to the recycler and adds
`restartCompletedCleaner()` (remove old + schedule fresh). The reference field
is `volatile` and both writers (`startCompletedCleaner`,
`restartCompletedCleaner`) are `synchronized`.
- `ProcedureManager.updateCompletedProcedureCleaner()` re-applies on the
running (leader) executor; followers are no-ops and pick up the value on the
next leader switch.
- `ConfigManager.setConfiguration` captures the previous values and
re-applies via `handleProcedureCleanerHotReload`, mirroring the existing
`handleHeartbeatIntervalHotReload` / `handleTopologyProbingHotReload` pattern.
Values are validated (`> 0`), consistent with existing hot-reload loaders.
### `disk_space_warning_threshold` hot reload
- New shared helper
`CommonDescriptor.loadHotModifiedDiskSpaceWarningThreshold()` parses, validates
(`[0, 1)`) and applies the value.
- Used by the **ConfigNode** path so `SHOW VARIABLES` / cluster-parameter
consistency checks reflect the change, and by the **DataNode** path, which
additionally refreshes the `JVMCommonUtils` static copy that the ReadOnly disk
guard actually consumes.
### `effectiveMode` / template
`iotdb-system.properties.template` updated accordingly (the four hidden keys
removed; the three keys above flipped to `hot_reload`).
## Note on "hidden" parameters
Removing a key from the template means it can no longer be changed via `set
configuration "key"="value"` (that path validates keys against the
template-derived default map and drops unknown keys). Hidden parameters remain
changeable by editing `iotdb-system.properties` and restarting, or via `load
configuration` for hot-reloadable ones. This matches the behavior of the
pre-existing hidden parameters.
## Testing
- `mvn compile` passes for `node-commons`, `confignode`, `datanode`;
`spotless:check` clean.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]