[
https://issues.apache.org/jira/browse/HDDS-16374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18130503#comment-18130503
]
Siyao Meng commented on HDDS-16374:
-----------------------------------
[Jira cleanup 2026-10-22] Resolving as Fixed. Reconfiguration rereads the
datanode-specific interval from DatanodeConfiguration.
Evidence:
* https://github.com/apache/ozone/pull/11193
*
https://github.com/apache/ozone/commit/a21f3eeb8a9fbfa3e1ea7948b7c59057d3fda988
*
https://github.com/apache/ozone/blob/bf3829e6c8ac69ae17585585703f91426dcdf6b3/hadoop-hdds/container-service/src/main/java/org/apache/hadoop/ozone/container/common/impl/BlockDeletingService.java#L126
Feel free to reopen if further work is needed.
> Datanode BlockDeletingService reconfiguration uses a different interval key
> than startup
> ----------------------------------------------------------------------------------------
>
> Key: HDDS-16374
> URL: https://issues.apache.org/jira/browse/HDDS-16374
> Project: Apache Ozone
> Issue Type: Bug
> Reporter: Meng-Shuan Tsai
> Assignee: Meng-Shuan Tsai
> Priority: Major
> Labels: pull-request-available
>
> h2. Problem
> This is a bug. Datanode `BlockDeletingService` starts with one interval key,
> then rereads a different, unaaliased key on dynamic reconfiguration.
> * Startup (`OzoneContainer`) uses
> `hdds.datanode.block.deleting.service.interval` via
> `DatanodeConfiguration.getBlockDeletionInterval()`.
> * Reconfiguration (`HddsDatanodeService` registration +
> `BlockDeletingService.updateAndRestart`) uses
> `ozone.block.deleting.service.interval`.
> Timeout and workers already share one key on both paths. Only interval is
> split. Both keys default to 60s, so a default-only cluster never shows the
> mismatch.
> HDDS-4367 split OM / SCM / Datanode deletion intervals on purpose. OM still
> uses `ozone.block.deleting.service.interval`. The later Datanode
> reconfiguration path (HDDS-11513) registered and reread the old shared key,
> so runtime restart no longer follows the datanode-specific contract.
> h2. Root cause
> `HddsDatanodeService` registers `OZONE_BLOCK_DELETING_SERVICE_INTERVAL`
> (`ozone.block.deleting.service.interval`). The complete callback treats a
> change to workers, timeout, or that old interval key as a full restart, and
> `updateAndRestart` always rereads the old key:
> {code:java}
> long newInterval = ozoneConf.getTimeDuration(
> OZONE_BLOCK_DELETING_SERVICE_INTERVAL,
> OZONE_BLOCK_DELETING_SERVICE_INTERVAL_DEFAULT,
> TimeUnit.SECONDS);
> // ...
> setInterval(newInterval, TimeUnit.SECONDS);{code}
> `hdds.datanode.block.deleting.service.interval` is not `reconfigurable =
> true`, so it is not in the DataNode reconfigurable set. There is no
> `DeprecationDelta` between the two keys; setting one does not fill the other.
> h2. Impact
> After an unrelated workers/timeout reconfig, the deletion scheduler can
> silently leave the operator-configured datanode interval. Scope is Datanode
> `BlockDeletingService` only. OM still owns
> `ozone.block.deleting.service.interval`.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
