[
https://issues.apache.org/jira/browse/IGNITE-27156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-27156:
---------------------------------------
Description:
h3. Motivation
We have a generic timeout for any RAFT operation
(RaftConfigurationSchema#retryTimeoutMillis), but for some cases we suppose
that the operation has never ended. Also, reties are excessive in the time when
the RAFT group is not formed.
The new RAFT client API should get a timeout from outside, and waiting for
availability may be solved using a topology-aware client (IGNITE-27154).
h3. Definition of done
A RAFT client that has a method to run a command with a timeout.
The method has to match the following rules:
If the service is called without a timeout (timeout = 0), a single attempt will
be made to send the command for replication.
If the service is called with an infinite timeout (timeout = Long.MAX_VALUE),
replication attempts will continue indefinitely, or the call will wait until
the service becomes ready.
If the service is called with a bounded timeout, replication attempts will
continue only for the specified duration (timeout).
If the replication command cannot be executed due to the service being
unavailable, a ReplicationGroupUnavailableException will be thrown.
was:
h3. Motivation
We have a generic timeout for any RAFT operation
(RaftConfigurationSchema#retryTimeoutMillis), but for some cases we suppose
that the operation has never ended. Also, reties are excessive in the time when
the RAFT group is not formed.
The new RAFT client API should get a timeout from outside, and waiting for
availability may be solved using a topology-aware client (IGNITE-27154).
> Rework RAFT client to wait for group availability
> -------------------------------------------------
>
> Key: IGNITE-27156
> URL: https://issues.apache.org/jira/browse/IGNITE-27156
> Project: Ignite
> Issue Type: Improvement
> Components: replication ai3
> Reporter: Vladislav Pyatkov
> Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> We have a generic timeout for any RAFT operation
> (RaftConfigurationSchema#retryTimeoutMillis), but for some cases we suppose
> that the operation has never ended. Also, reties are excessive in the time
> when the RAFT group is not formed.
> The new RAFT client API should get a timeout from outside, and waiting for
> availability may be solved using a topology-aware client (IGNITE-27154).
> h3. Definition of done
> A RAFT client that has a method to run a command with a timeout.
> The method has to match the following rules:
> If the service is called without a timeout (timeout = 0), a single attempt
> will be made to send the command for replication.
> If the service is called with an infinite timeout (timeout = Long.MAX_VALUE),
> replication attempts will continue indefinitely, or the call will wait until
> the service becomes ready.
> If the service is called with a bounded timeout, replication attempts will
> continue only for the specified duration (timeout).
> If the replication command cannot be executed due to the service being
> unavailable, a ReplicationGroupUnavailableException will be thrown.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
