[
https://issues.apache.org/jira/browse/RATIS-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Song Ziyang updated RATIS-1598:
-------------------------------
Description:
RetryCache can filter redundant retry requests when a client-request arrives at
RaftServer. This filtering happens before AppendLog. However, to support
exactly-once semantic, it is necessary to check RetryCache also before ApplyLog.
Consider this scenario:
RetryCache is updated when the request is *successfully committed to RaftLog,
before replying to client.*
If the same 2 requests arrive at roughly same time, the req#1 pass the
RetryCache check and successfully appended to RaftLog, but before updating
RetryCache and reply, the req#2 arrives. Since req#1 is not completely
processed, the RetryCache will not have the entry for #req1. In this case,
req#2 will also pass RetryCache check and start to be appended to log. This
leads to these 2 same requests both be applied.
If the RetryCache is also checked before applyLog, we can still filter #req2
before statemachine knows it.
was:
RetryCache is used to reduce redundant retry requests before AppendLog. To
support exactly-once semantic, it is necessary also to check RetryCache before
ApplyLog.
Consider this scenario:
RetryCache is updated when the request is successfully committed to RaftLog,
before replying to client.
If the same 2 requests arrive at same time, the req#1 pass the RetryCache check
and successfully appended to RaftLog, but before updating RetryCache and reply,
the req#2 arrives. Req#2 will also pass RetryCache check and start to be
appended to log.
> Check RetryCache before applyLog
> --------------------------------
>
> Key: RATIS-1598
> URL: https://issues.apache.org/jira/browse/RATIS-1598
> Project: Ratis
> Issue Type: Improvement
> Reporter: Song Ziyang
> Priority: Major
>
> RetryCache can filter redundant retry requests when a client-request arrives
> at RaftServer. This filtering happens before AppendLog. However, to support
> exactly-once semantic, it is necessary to check RetryCache also before
> ApplyLog.
>
> Consider this scenario:
> RetryCache is updated when the request is *successfully committed to
> RaftLog, before replying to client.*
> If the same 2 requests arrive at roughly same time, the req#1 pass the
> RetryCache check and successfully appended to RaftLog, but before updating
> RetryCache and reply, the req#2 arrives. Since req#1 is not completely
> processed, the RetryCache will not have the entry for #req1. In this case,
> req#2 will also pass RetryCache check and start to be appended to log. This
> leads to these 2 same requests both be applied.
>
> If the RetryCache is also checked before applyLog, we can still filter #req2
> before statemachine knows it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
