[
https://issues.apache.org/jira/browse/HDDS-11043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated HDDS-11043:
----------------------------------
Labels: pull-request-available (was: )
> Explore client retry optimizations after write() and hsync() are desynced
> -------------------------------------------------------------------------
>
> Key: HDDS-11043
> URL: https://issues.apache.org/jira/browse/HDDS-11043
> Project: Apache Ozone
> Issue Type: Sub-task
> Components: Ozone Client
> Reporter: Siyao Meng
> Assignee: Chu Cheng Li
> Priority: Major
> Labels: pull-request-available
>
> Posting this as a follow-up to HDDS-9844.
> Ozone client retry handling wasn't built for multi-threading. There could be
> tons of room for optimization.
> 1. consecutive request failures could be combined into one before the retry.
> For instance, we have the following Ratis requests from the same client as a
> result of 2 hsync() calls (not considering piggybacking so far):
> {code}
> 1. writeChunk1
> 2. putBlock2
> 3. writeChunk3
> 4. putBlock4
> {code}
> If all 4 Ratis requests failed due to say, Raft leader being not available,
> for the next retry attempt, ideally the request can be combined into:
> {code}
> 1. writeChunk1 + writeChunk3
> 2. putBlock4
> {code}
> writeChunks can be combined.
> putBlock2 metadata is no longer the latest, so it is not useful anymore and
> can be ignored.
> And essentially the Ozone client buffer would be similar to what TCP sliding
> window's buffer looks like:
> https://www.researchgate.net/profile/Rasool-Al-Saadi/publication/331853081/figure/fig1/AS:738951123972098@1553191085167/TCP-sliding-window-mechanism.png
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
