[jira] [Updated] (IGNITE-17255) Implement ReplicaService

["Alexander Lapin (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-17255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Lapin updated IGNITE-17255:
-------------------------------------
    Reviewer: Vladislav Pyatkov

> Implement ReplicaService
> ------------------------
>
>                 Key: IGNITE-17255
>                 URL: https://issues.apache.org/jira/browse/IGNITE-17255
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Alexander Lapin
>            Assignee: Sergey Uttsel
>            Priority: Major
>              Labels: ignite-3, transaction3_rw
>
> For general context please check IGNITE-17252
> Within given ticket it's required to
>  * Implement ReplicaService itself.
>  * Substitute RaftGroupService with ReplicaService from within InternalTableImpl and others
> Please pay attention that according to tx protocol it's valid to fail the transaction in case of primary replica change - we'll introduce support of graceful primary replica switch later on. For now, within the scope of RW transactions it's enough to detect where primary replica is and enlist it to transaction with corresponding partition in order to reuse for further in-partition communication.
> We should make it very clear, that any replicaService.invoke(nodeId) might fail with primaryReplicaMiss or replicaUnavailable, it's up to the outer logic to remap such failed requests.
> However it's still required to detect proper primary replica initially and check whether it's still primary during further queries. Proper lease-based primary replica stability engine will be introduced within [IGNITE-17256|https://issues.apache.org/jira/browse/IGNITE-17256] , as a staring point it's possible to reuse sendWithRetry logic with true readIndex leader checks, meaning that primary replica is the replica collocated with the current leader (not the node that is thinking that it's a leader, but a node that was proved to be a leader based on readIndex logic).
> In addition to all points mentioned above we should be aware that lot's of tests will become flaky  because sendWithRetry logic will only be available with initial primaryReplica detection method and not within common invokes. Generally speaking I believe that it's a good chance to rework them and thus make them stable.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)