[jira] [Updated] (RATIS-924) rename raft group dir on disk when remove group is invoked
[ https://issues.apache.org/jira/browse/RATIS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cyrus Jackson updated RATIS-924: Attachment: RATIS-924.001.patch > rename raft group dir on disk when remove group is invoked > -- > > Key: RATIS-924 > URL: https://issues.apache.org/jira/browse/RATIS-924 > Project: Ratis > Issue Type: Bug >Reporter: runzhiwang >Assignee: runzhiwang >Priority: Major > Attachments: RATIS-924.001.patch, screenshot-1.png > > > !screenshot-1.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (RATIS-924) rename raft group dir on disk when remove group is invoked
[ https://issues.apache.org/jira/browse/RATIS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17156312#comment-17156312 ] Cyrus Jackson commented on RATIS-924: - [~shashikant] [~yjxxtd] I have added a patch for the same. Please review it and give your thoughts on it. In this patch, when a groupRemove is called from the client and deleteDirectory is set to false, the group gets renamed. Also, I have included a properties file which holds the original group name in the renamed group directory, this can be helpful in case the client wants to restore the group. When deleteDirectory is set to true, the group is permanently deleted. > rename raft group dir on disk when remove group is invoked > -- > > Key: RATIS-924 > URL: https://issues.apache.org/jira/browse/RATIS-924 > Project: Ratis > Issue Type: Bug >Reporter: runzhiwang >Assignee: runzhiwang >Priority: Major > Attachments: RATIS-924.001.patch, screenshot-1.png > > > !screenshot-1.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RATIS-996) Include ratis-docs in source and binary tar
[ https://issues.apache.org/jira/browse/RATIS-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Glen Geng updated RATIS-996: Labels: pull-request-available (was: ) > Include ratis-docs in source and binary tar > --- > > Key: RATIS-996 > URL: https://issues.apache.org/jira/browse/RATIS-996 > Project: Ratis > Issue Type: Bug >Reporter: Lokesh Jain >Assignee: Lokesh Jain >Priority: Blocker > Labels: pull-request-available > Fix For: 0.6.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Currently ratis-docs is not included in source and binary tar. Further > ratis-docs is the last module built. This causes failure in package phase of > ratis-assembly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RATIS-996) Include ratis-docs in source and binary tar
[ https://issues.apache.org/jira/browse/RATIS-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Glen Geng updated RATIS-996: Labels: (was: pull-request-available) > Include ratis-docs in source and binary tar > --- > > Key: RATIS-996 > URL: https://issues.apache.org/jira/browse/RATIS-996 > Project: Ratis > Issue Type: Bug >Reporter: Lokesh Jain >Assignee: Lokesh Jain >Priority: Blocker > Fix For: 0.6.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Currently ratis-docs is not included in source and binary tar. Further > ratis-docs is the last module built. This causes failure in package phase of > ratis-assembly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (RATIS-998) shouldWithholdVotes() should be triggered for handling higher term
[
https://issues.apache.org/jira/browse/RATIS-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Glen Geng updated RATIS-998:
Labels: pull-request-available (was: )
> shouldWithholdVotes() should be triggered for handling higher term
> --
>
> Key: RATIS-998
> URL: https://issues.apache.org/jira/browse/RATIS-998
> Project: Ratis
> Issue Type: Bug
> Components: server
>Affects Versions: 0.5.0
>Reporter: Glen Geng
>Assignee: Glen Geng
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
>
> I assume that {{shouldWithholdVotes()}} is used to handle request vote
> request with higher candidate term from disruptive server, but currently it
> just ignored such requests, since it only take effect when
> {{(state.getCurrentTerm() >= candidateTerm)}} .
> shouldWithholdVotes() should be triggered for handling higher term. If
> currentTerm is larger or equal to candidateTerm, just reject the request
> vote, no need further handling.
>
> Current code is
> {code:java}
> private boolean shouldWithholdVotes(long candidateTerm) {
> if (state.getCurrentTerm() < candidateTerm) {
> return false;
> } else if (isLeader()) {
> return true;
> } else {
> // following a leader and not yet timeout
> return isFollower() && state.hasLeader()
> &&
> role.getFollowerState().map(FollowerState::shouldWithholdVotes).orElse(false);
> }
> }
> {code}
> Modify to
> {code:java}
> private boolean shouldWithholdVotes(long candidateTerm) {
> if (state.getCurrentTerm() >= candidateTerm) {
> return false;
> } else if (isLeader()) {
> return true;
> } else {
> // following a leader and not yet timeout
> return isFollower() && state.hasLeader()
> &&
> role.getFollowerState().map(FollowerState::shouldWithholdVotes).orElse(false);
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (RATIS-981) Step-down stale leader in case of split-brain
[ https://issues.apache.org/jira/browse/RATIS-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Glen Geng updated RATIS-981: Labels: pull-request-available (was: ) > Step-down stale leader in case of split-brain > - > > Key: RATIS-981 > URL: https://issues.apache.org/jira/browse/RATIS-981 > Project: Ratis > Issue Type: Improvement >Reporter: Nanda kumar >Assignee: Glen Geng >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > We should make sure that the stale leader steps down to the candidate state > before the next leader election. > Proposal: > In the heartbeat thread in the Leader node, we should check if the last > response time of the follower is less than the leader election timeout. If > the majority of the follower’s last response time is less than the leader > election timeout, the current leader is still the active leader. Majority of > the followers are heartbeating to the current leader, so there can’t be a new > leader. > If the majority of follower’s last response time is greater than the leader > election timeout, the current leader should step down and become a candidate. > With this check, we can be sure that the current leader will step down and > become a candidate before the new leader election starts in case of a network > partition. -- This message was sent by Atlassian Jira (v8.3.4#803005)
