[
https://issues.apache.org/jira/browse/IGNITE-22837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872055#comment-17872055
]
Vladislav Pyatkov commented on IGNITE-22837:
--------------------------------------------
In the result above, we do not have a switching thread between operations
(resolvePeer and deserializedCommand) any more.
But we still have an unexpectedly long time interval (about 3 microseconds).
The issue is in this code:
{code}
CompletableFuture<NetworkMessage> responseFuture = new
CompletableFuture<NetworkMessage>()
.orTimeout(timeout, TimeUnit.MILLISECONDS);
{code}
A setting of a timeout for the complete future may take about 3 microseconds.
It has to be optimized soon in other tiket.
Moreover I do not shure the timeout is necessory for the local network
invokation.
> Invocation of the local raft client happens in a different pool
> ---------------------------------------------------------------
>
> Key: IGNITE-22837
> URL: https://issues.apache.org/jira/browse/IGNITE-22837
> Project: Ignite
> Issue Type: Improvement
> Reporter: Vladislav Pyatkov
> Assignee: Vladislav Pyatkov
> Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> By our architecture, we are involving RAFT client from the same node where
> the RAFT node is. In this case, we do not need to change threads (the only
> case where we have it is an invocation in the network thread).
> {noformat}
> resolvePeer:org.apache.ignite.internal.benchmark.InsertBenchmark.kvInsert-jmh-worker-1
> 0.301 782499 782800
> Here is hidden 9.3 us
> deserializedCommand:%node_3344%JRaft-Request-Processor-2 0.1 792100 792200
> {noformat}
> h3. Definition of done
> Get rid of chnaging threads in loca RAFT node invocation.
> We already have the same logic for the replica manager
> (ReplicaManager#onReplicaMessageReceived).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
