[jira] [Resolved] (HDDS-4484) Use RatisServerImpl isLeader instead of periodic leader update logic in OM and isLeaderReady for read requests

["Bharat Viswanadham (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HDDS-4484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bharat Viswanadham resolved HDDS-4484.
--------------------------------------
    Fix Version/s: 1.1.0
       Resolution: Fixed

> Use RatisServerImpl isLeader instead of periodic leader update logic in OM and isLeaderReady for read requests
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: HDDS-4484
>                 URL: https://issues.apache.org/jira/browse/HDDS-4484
>             Project: Hadoop Distributed Data Store
>          Issue Type: Improvement
>            Reporter: Bharat Viswanadham
>            Assignee: Bharat Viswanadham
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 1.1.0
>
>
> Previously RatisServer which is network-partitoned/split-brain does not step down from leader state, so we require custom logic to determine leader(But that is also not completely correct, as the role state is updated based on server state not a quorum based information)
> Now, in Ratis leader steps down after the leader election max time out, so we can use RaftServer Api isLeader check. (RATIS-981 fixed this behavior)
> This also fixes when serving read requests it should check leaderReady, not just isLeader because when it is leader, it might be still applying pending commit transactions, so there is a chance that acked transactions of write, might not be visible until we wait for isLeaderReady.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org