Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
Description
Motivation
In order to implement RW part of tx protocol it's required to check whether we touch same primary replica that was previously enlisted and await primary replica appearance on group readiness. Currently it's implemented using same raft-leader check on top of retry logic with throttling which is inefficient and doesn't support overall idea of hiding replication protocol details under replicas umbrella.
Definition of done
Long story short, it's required to implement following API (exact one or similar)
/** * Returns a future for the primary replica for the specified replication group whose expiration time (the right border of the * corresponding lease interval) is greater than or equal to the timestamp passed as a parameter. Please pay attention that there are * no restriction on the lease start time (left border), it can either be less or greater than or equal to proposed timestamp. * Given method will await for an appropriate primary replica appearance if there's no already existing one. Such awaiting logic is * unbounded, so it's mandatory to use explicit await termination like {@code orTimeout}. * * @param replicationGroupId Replication group id. * @param timestamp Timestamp reference value. * @return Primary replica future. */ public CompletableFuture<ReplicaMeta> awaitPrimaryReplica(ReplicationGroupId replicationGroupId, HybridTimestamp timestamp) { return CompletableFuture.completedFuture(null); } /** * Same as {@link PlacementDriverManager#awaitPrimaryReplica(ReplicationGroupId, HybridTimestamp)} despite the fact that given method * won't await for an appropriate primary replica appearance if there's no already existing one, in that case null will be returned. * * @param replicationGroupId Replication group id. * @param timestamp Timestamp reference value. * @return Primary replica future. */ public CompletableFuture<ReplicaMeta> getPrimaryReplica(ReplicationGroupId replicationGroupId, HybridTimestamp timestamp) { return CompletableFuture.completedFuture(null); }
Implementation Notes
Seems reasonable to reuse PendingComparableValuesTracker logic in order to implement aforementioned API. Some PendingComparableValuesTracker enhancement are required though, see https://issues.apache.org/jira/browse/IGNITE-18859 for more details.
Attachments
Issue Links
- blocks
-
IGNITE-18856 Switch primary replica calls from Raft leader to primary replica
- Resolved
- is blocked by
-
IGNITE-18859 PendingComparableValuesTracker extension in order to support multiple idependent waiters assosiated with values
- Resolved
- links to