[
https://issues.apache.org/jira/browse/IGNITE-22207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852389#comment-17852389
]
Vladislav Pyatkov commented on IGNITE-22207:
--------------------------------------------
Merged 7b9e845b681c27cb5ceca293badca8748cb31d89
> Handling of AwaitPrimaryReplica request maight lead to the dedalock
> -------------------------------------------------------------------
>
> Key: IGNITE-22207
> URL: https://issues.apache.org/jira/browse/IGNITE-22207
> Project: Ignite
> Issue Type: Bug
> Reporter: Vladislav Pyatkov
> Assignee: Mirza Aliev
> Priority: Major
> Labels: ignite-3
> Time Spent: 40m
> Remaining Estimate: 0h
>
> h3. Motivation
> We handle ReplicaUnavailableException in ReplicaService to handle request
> transparency even if the replica had not been read at the time the request
> was sent. To do this, we send AwaitReplicaRequest as a handling of the
> exception and then process the origin request when the replica is guaranteed
> ready.
> In the event that the AwaitReplicaRequest is handled locally, we will do it
> synchronously in pendingInvokes.computeIfAbsent:
> {code}
> CompletableFuture<NetworkMessage> awaitReplicaFut =
> pendingInvokes.computeIfAbsent(
> targetNodeConsistentId,
> consistentId -> {
> AwaitReplicaRequest awaitReplicaReq =
> REPLICA_MESSAGES_FACTORY.awaitReplicaRequest()
> .groupId(req.groupId())
> .build();
> return messagingService.invoke(
> targetNodeConsistentId,
> awaitReplicaReq,
> replicationConfiguration.rpcTimeout().value()
> );
> }
> );
> {code}
> and then hands on handling of AwaitReplicaRequest, due to removing from
> pendingInvokes:
> {code}
> awaitReplicaFut.handle((response0, throwable0) -> {
> pendingInvokes.remove(targetNodeConsistentId, awaitReplicaFut);
> ...
> {code}
> h3. Definition of doe
> Take out of the network invokation from the map compute closure.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
