[
https://issues.apache.org/jira/browse/HDDS-11043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siyao Meng updated HDDS-11043:
------------------------------
Description:
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 buffer would be similar to
was:
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.
> 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: Task
> Components: Ozone Client
> Reporter: Siyao Meng
> Priority: Major
>
> 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 buffer would be similar to
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
