You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ozone.apache.org by "Tsz-wo Sze (Jira)" <ji...@apache.org> on 2023/12/05 00:36:00 UTC
[jira] [Resolved] (HDDS-9821) XceiverServerRatis SyncTimeoutRetry is overridden
[ https://issues.apache.org/jira/browse/HDDS-9821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tsz-wo Sze resolved HDDS-9821.
------------------------------
Resolution: Fixed
The pull request is now merged. Thanks, [~ivanandika]!
> XceiverServerRatis SyncTimeoutRetry is overridden
> --------------------------------------------------
>
> Key: HDDS-9821
> URL: https://issues.apache.org/jira/browse/HDDS-9821
> Project: Apache Ozone
> Issue Type: Bug
> Components: Ozone Datanode
> Reporter: Ivan Andika
> Assignee: Ivan Andika
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.4.0
>
>
> In XceiverServerRatis#newRaftProperties, setSyncTimeoutRetry was set twice
> First, it is set to
> {code:java}
> (int) nodeFailureTimeoutMs / dataSyncTimeout.toIntExact(TimeUnit.MILLISECONDS) {code}
> which by default equals to 300_000 ms / 10_000 ms = 30 retries
> From the comment, the intention of setting a finite number of retries is:
> Even if the leader is not able to complete write calls within the timeout seconds, it should just fail the operation and trigger pipeline close. failing the writeStateMachine call with limited retries will ensure even the leader initiates a pipeline close if its not able to complete write in the timeout configured.
> However, it was overridden in
> {code:java}
> int numSyncRetries = conf.getInt(
> OzoneConfigKeys.DFS_CONTAINER_RATIS_STATEMACHINEDATA_SYNC_RETRIES,
> OzoneConfigKeys.
> DFS_CONTAINER_RATIS_STATEMACHINEDATA_SYNC_RETRIES_DEFAULT);
> RaftServerConfigKeys.Log.StateMachineData.setSyncTimeoutRetry(properties,
> numSyncRetries); {code}
> Which set it to the default value -1 (retry indefinitely).
> This might cause the leader to never initiate a pipeline close when its writeStateMachine time out (e.g. write chunk timeout due to I/O issue).
> I propose we use the finite timeout retry calculation as the default configuration.
>
> This is also a good avenue to re-evaluate the state machine data policy in Container State Machine.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org