[
https://issues.apache.org/jira/browse/RATIS-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17562914#comment-17562914
]
Song Ziyang commented on RATIS-1598:
------------------------------------
I'm not sure if RetryCache is purposefully designed to be only checked before
AppendLog and let statemachine implements its own filter to guarantee the
exactly-once semantic. Could you please take a look, thanks! [~szetszwo]
> 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)
