[
https://issues.apache.org/jira/browse/IGNITE-27524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Laletin updated IGNITE-27524:
-----------------------------------
Description:
In PlacementDriverMessageProcessor there is waitForActualState which reads
index from raft and then wait until storage index reaches raft one.
The proposal is to improve logging to differentiate timeout scenarios, i.e. in
case of failure it should be clear what what was the cause raft index
retrieval, storage index tracking etc.
Moreover the following code applies 2 similar timeouts to the raft index read,
meanwhile storage tracking doesn't have one.
{code:java}
retryOperationUntilSuccess(raftClient::readIndex, e -> currentTimeMillis() >
expirationTime, executor)
.orTimeout(timeout, TimeUnit.MILLISECONDS)
.thenCompose(storageIndexTracker::waitFor);
{code}
I propose to add timeout for storage tracking and remove extra one for raft
index
{code:java}
retryOperationUntilSuccess(raftClient::readIndex, e -> currentTimeMillis() >
expirationTime, executor)
.thenCompose(storageIndexTracker::waitFor)
.orTimeout(timeout, TimeUnit.MILLISECONDS);
{code}
Plus, it seems it doesn't make sense to wait more than lease lifespan, so let's
calculate remaining time after raft index retrieval and use this time for
timeout.
was:
In PlacementDriverMessageProcessor there is waitForActualState which reads
index from raft and then wait until storage index reaches raft one.
The proposal is to improve logging to differentiate timeout scenarios.
Moreover the following code applies 2 similar timeouts to the raft index read,
meanwhile storage tracking doesn't have one.
{code:java}
retryOperationUntilSuccess(raftClient::readIndex, e -> currentTimeMillis() >
expirationTime, executor)
.orTimeout(timeout, TimeUnit.MILLISECONDS)
.thenCompose(storageIndexTracker::waitFor);
{code}
I propose to add timeout for storage tracking and remove extra one for raft
index
{code:java}
retryOperationUntilSuccess(raftClient::readIndex, e -> currentTimeMillis() >
expirationTime, executor)
.thenCompose(storageIndexTracker::waitFor)
.orTimeout(timeout, TimeUnit.MILLISECONDS);
{code}
Plus, it seems it doesn't make sense to wait more than lease lifespan, so let's
calculate remaining time after raft index retrieval and use this time for
timeout.
> Improve logging and timeout management of waitForActualState
> ------------------------------------------------------------
>
> Key: IGNITE-27524
> URL: https://issues.apache.org/jira/browse/IGNITE-27524
> Project: Ignite
> Issue Type: Improvement
> Reporter: Anton Laletin
> Assignee: Anton Laletin
> Priority: Major
>
> In PlacementDriverMessageProcessor there is waitForActualState which reads
> index from raft and then wait until storage index reaches raft one.
> The proposal is to improve logging to differentiate timeout scenarios, i.e.
> in case of failure it should be clear what what was the cause raft index
> retrieval, storage index tracking etc.
> Moreover the following code applies 2 similar timeouts to the raft index
> read, meanwhile storage tracking doesn't have one.
> {code:java}
> retryOperationUntilSuccess(raftClient::readIndex, e -> currentTimeMillis() >
> expirationTime, executor)
> .orTimeout(timeout, TimeUnit.MILLISECONDS)
> .thenCompose(storageIndexTracker::waitFor);
> {code}
> I propose to add timeout for storage tracking and remove extra one for raft
> index
> {code:java}
> retryOperationUntilSuccess(raftClient::readIndex, e -> currentTimeMillis() >
> expirationTime, executor)
> .thenCompose(storageIndexTracker::waitFor)
> .orTimeout(timeout, TimeUnit.MILLISECONDS);
> {code}
> Plus, it seems it doesn't make sense to wait more than lease lifespan, so
> let's calculate remaining time after raft index retrieval and use this time
> for timeout.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
