[smengcl]

Generated-by: Claude Code (Opus 5.5)

What changes were proposed in this pull request?

With a single OM, the OM client increases the wait time between retries linearly and without a cap when the OM is not reachable, because round robin failover selects the same OM again and getWaitTime treats that as a retry on the same OM requested by the OM. A client started before OM is ready (e.g. right after starting a Docker Compose cluster) can keep sleeping long after OM is up.

This change checks whether all OMs were attempted in the current round first, so a single OM gets the same fixed wait as a full round over multiple OMs. Retries on the same OM requested by the OM (e.g. OMLeaderNotReadyException) still increase the wait time. Behavior with multiple OMs is unchanged.

As a result, a client talking to a single OM that stays down gives up much sooner: with the defaults (ozone.client.failover.max.attempts=500, ozone.client.wait.between.retries.millis=2000), the total wait drops from about 70 hours to about 17 minutes, in line with a full round over multiple OMs.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-17302

How was this patch tested?

Added TestOMFailoverProxyProvider#testWaitTimeWithSingleNode, which fails without the fix, including when the reset of the same-OM retry count is removed. Existing failover proxy provider and transport unit tests pass.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[jojochuang]

Optional, non-blocking documentation suggestion: we could update the HA Client Failover documentation to distinguish the two retry-delay cases. This does not need to hold up this PR and can be done later in a separate task.

The page currently describes a fixed 2-second delay between every failover retry, but the policy distinguishes:

• Round-robin failover: wait for ozone.client.wait.between.retries.millis after each complete round. With this fix, a single-OM connection failure completes a round on every retry and therefore uses the fixed delay.
• Explicit same-OM retry, such as OMLeaderNotReadyException: increase the delay linearly—2s, 4s, 6s, etc. with defaults. There is no separate delay cap; retries are bounded by ozone.client.failover.max.attempts.

It would also help to mention that the fix reduces accumulated sleep for 500 single-OM connection-failure retries from approximately 70 hours to 17 minutes, excluding connection/RPC time. No configuration defaults change.

[smengcl]

Thanks @jojochuang for the review.