[
https://issues.apache.org/jira/browse/RATIS-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tsz-wo Sze updated RATIS-1874:
------------------------------
Attachment: 906_review.patch
> Add notifyLeaderReady function in IStateMachine
> -----------------------------------------------
>
> Key: RATIS-1874
> URL: https://issues.apache.org/jira/browse/RATIS-1874
> Project: Ratis
> Issue Type: Improvement
> Components: StateMachine
> Reporter: Xinyu Tan
> Assignee: Xinyu Tan
> Priority: Major
> Attachments: 906_review.patch
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In a highly available metadata service built on top of Ratis, such as IoTDB's
> confignode, the Leader node launches more modules compared to the Follower
> node. These additional modules include functionalities like load balancing
> and others.
> Currently, we employ the "notifyLeaderChange" callback to prompt the Leader
> to initiate the corresponding modules like load balancing. However, within
> this callback, the leader's state machine might not have fully recovered,
> potentially leading to the retrieval of outdated data when directly reading
> from certain modules.
> One approach in this scenario would involve utilizing a linearizable read
> interface along with implementing corresponding retry logic (such as timeouts
> or waiting until a leader is elected). However, such modifications would
> result in significant changes to our codebase. Therefore, we are inclined to
> opt for an alternative solution – adding a "notifyLeaderReady" interface to
> the "StateMachine". This interface would be invoked only when the Leader's
> state machine applies the first log entry of its current term. This
> adjustment would ensure the accurate recovery of certain modules.
>
> [~szetszwo] What's your opinion?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)