[
https://issues.apache.org/jira/browse/IGNITE-17255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17255:
-------------------------------------
Reviewer: Alexander Lapin (was: 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)