Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: release-0.9: implement TryAsRef<ForwardToLeader> for RaftError #1091

Closed
wants to merge 18 commits into from
Closed

Feature: release-0.9: implement TryAsRef<ForwardToLeader> for RaftError #1091

wants to merge 18 commits into from

Conversation

HaHa421
Copy link
Contributor

@HaHa421 HaHa421 commented Apr 7, 2024

this should backport the main pull request to v0.9


This change is Reviewable

drmingdrmer and others added 17 commits March 16, 2024 10:11
Update the example to return unreachable error for connection errors to
prevent immediate retries.
…ng.vote

Previously, `Leading.vote.utime()` held the last timestamp acknowledged
by a quorum, marking the beginning of the leader lease. The `Leading`
struct updates and calculates this timestamp upon receiving an
`AppendEntries` reply (includes heartbeat) from a follower.

However, the leader's own timestamp was not being updated in this
process.

With this commit, we now update the leader's timestamp every time the
**last-quorum-acked-time** is accessed. This constant recalculation
makes storing the timestamp in `Leading.vote` unnecessary, hence it has
been removed to streamline the code.
Previously, the heartbeat results were not sent back to
`RaftCore`, which requires these results to calculate the **last
timestamp acknowledged by a quorum**.

This commit resolves the issue by ensuring that the heartbeat RPC
results are sent back to `RaftCore`, allowing it to correctly update the
**last timestamp acknowledged by a quorum**.
`RaftMetrics::millis_since_quorum_ack` is the interval in milliseconds
since the last timestamp a quorum acknowledged.

This duration is used by the application to assess the likelihood that
the leader has lost synchronization with the cluster.
A longer duration without acknowledgment may suggest a higher
probability of the leader being partitioned from the cluster.
…erverMetrics`

This commit addresses an issue where `RaftMetrics` could be sent before
`RaftDataMetrics` and `RaftServerMetrics`. Since `Wait` relies solely on
`RaftMetrics` to reflect the latest state, it is crucial that
`RaftMetrics` are dispatched only after the other two metrics have been
updated. This change guarantees that once a change in `RaftMetrics` is
detected, it accurately represents the most recent changes from both
`RaftDataMetrics` and `RaftServerMetrics`.
@HaHa421 HaHa421 changed the title Release 0.9 implement TryAsRef<ForwardToLeader> for RaftError Feature: release-0.9 implement TryAsRef<ForwardToLeader> for RaftError Apr 7, 2024
@HaHa421 HaHa421 changed the title Feature: release-0.9 implement TryAsRef<ForwardToLeader> for RaftError Feature: release-0.9: implement TryAsRef<ForwardToLeader> for RaftError Apr 7, 2024
@drmingdrmer
Copy link
Member

@HaHa421
You do not need to re-write it for release-0.9
I already shipped it to 0.9.4:

https://github.com/datafuselabs/openraft/releases/tag/v0.9.4

And you can just use it on crates.io:

https://crates.io/crates/openraft/0.9.4

@HaHa421
Copy link
Contributor Author

HaHa421 commented Apr 8, 2024 via email

@HaHa421 HaHa421 closed this by deleting the head repository Apr 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants