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

Sergey Uttsel reassigned IGNITE-17255:
--------------------------------------

    Assignee: Sergey Uttsel

> 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)

Reply via email to