-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Resolve some coordination-layer TODOs #54511
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -163,7 +163,6 @@ private void handleFollowerCheck(FollowerCheckRequest request, TransportChannel | |
FastResponseState responder = this.fastResponseState; | ||
|
||
if (responder.mode == Mode.FOLLOWER && responder.term == request.term) { | ||
// TODO trigger a term bump if we voted for a different leader in this term | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This happens by sending a publish response with no associated join. |
||
logger.trace("responding to {} on fast path", request); | ||
transportChannel.sendResponse(Empty.INSTANCE); | ||
return; | ||
|
@@ -198,15 +197,6 @@ public String toString() { | |
}); | ||
} | ||
|
||
// TODO in the PoC a faulty node was considered non-faulty again if it sent us a PeersRequest: | ||
// - node disconnects, detected faulty, removal is enqueued | ||
// - node reconnects, pings us, finds we are master, requests to join, all before removal is applied | ||
// - join is processed before removal, but we do not publish to known-faulty nodes so the joining node does not receive this publication | ||
// - it doesn't start its leader checker since it receives nothing to cause it to become a follower | ||
// Apparently this meant that it remained a candidate for too long, leading to a test failure. At the time this logic was added, we did | ||
// not have gossip-based discovery which would (I think) have retried this joining process a short time later. It's therefore possible | ||
// that this is no longer required, so it's omitted here until we can be sure if it's necessary or not. | ||
|
||
/** | ||
* @return nodes in the current cluster state which have failed their follower checks. | ||
*/ | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -21,7 +21,6 @@ | |
import org.elasticsearch.cluster.ClusterState; | ||
|
||
public class InMemoryPersistedState implements CoordinationState.PersistedState { | ||
// TODO add support and tests for behaviour with persistence-layer failures | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done, see |
||
|
||
private long currentTerm; | ||
private ClusterState acceptedState; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -62,7 +62,6 @@ public class PreVoteCollector { | |
this.updateMaxTermSeen = updateMaxTermSeen; | ||
this.electionStrategy = electionStrategy; | ||
|
||
// TODO does this need to be on the generic threadpool or can it use SAME? | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, |
||
transportService.registerRequestHandler(REQUEST_PRE_VOTE_ACTION_NAME, Names.GENERIC, false, false, | ||
PreVoteRequest::new, | ||
(request, channel, task) -> channel.sendResponse(handlePreVoteRequest(request))); | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -244,7 +244,6 @@ void sendPublishRequest() { | |
assert state == PublicationTargetState.NOT_STARTED : state + " -> " + PublicationTargetState.SENT_PUBLISH_REQUEST; | ||
state = PublicationTargetState.SENT_PUBLISH_REQUEST; | ||
Publication.this.sendPublishRequest(discoveryNode, publishRequest, new PublishResponseHandler()); | ||
// TODO Can this ^ fail with an exception? Target should be failed if so. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Don't think so, it notifies the listener on a failure. |
||
assert publicationCompletedIffAllTargetsInactiveOrCancelled(); | ||
} | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -244,7 +244,6 @@ class Cluster implements Releasable { | |
|
||
final List<ClusterNode> clusterNodes; | ||
final DeterministicTaskQueue deterministicTaskQueue = new DeterministicTaskQueue( | ||
// TODO does ThreadPool need a node name any more? | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not really relevant here. |
||
Settings.builder().put(NODE_NAME_SETTING.getKey(), "deterministic-task-queue").build(), random()); | ||
private boolean disruptStorage; | ||
|
||
|
@@ -289,8 +288,13 @@ class Cluster implements Releasable { | |
initialNodeCount, masterEligibleNodeIds, initialConfiguration); | ||
} | ||
|
||
List<ClusterNode> addNodesAndStabilise(int newNodesCount) { | ||
final List<ClusterNode> addedNodes = addNodes(newNodesCount); | ||
void addNodesAndStabilise(int newNodesCount) { | ||
|
||
// The stabilisation time bound is O(#new nodes) which isn't ideal; it's possible that the real bound is O(1) since node-join | ||
// events are batched together, but in practice we have not seen problems in this area so have not invested the time needed to | ||
// investigate this more closely. | ||
|
||
addNodes(newNodesCount); | ||
stabilise( | ||
// The first pinging discovers the master | ||
defaultMillis(DISCOVERY_FIND_PEERS_INTERVAL_SETTING) | ||
|
@@ -299,8 +303,6 @@ List<ClusterNode> addNodesAndStabilise(int newNodesCount) { | |
// Commit a new cluster state with the new node(s). Might be split into multiple commits, and each might need a | ||
// followup reconfiguration | ||
+ newNodesCount * 2 * DEFAULT_CLUSTER_STATE_UPDATE_DELAY); | ||
// TODO Investigate whether 4 publications is sufficient due to batching? A bound linear in the number of nodes isn't great. | ||
return addedNodes; | ||
} | ||
|
||
List<ClusterNode> addNodes(int newNodesCount) { | ||
|
@@ -331,7 +333,6 @@ void runRandomly() { | |
*/ | ||
void runRandomly(boolean allowReboots, boolean coolDown, long delayVariability) { | ||
|
||
// TODO supporting (preserving?) existing disruptions needs implementing if needed, for now we just forbid it | ||
assertThat("may reconnect disconnected nodes, probably unexpected", disconnectedNodes, empty()); | ||
assertThat("may reconnect blackholed nodes, probably unexpected", blackholedNodes, empty()); | ||
|
||
|
@@ -449,11 +450,6 @@ public String toString() { | |
deterministicTaskQueue.runRandomTask(); | ||
} | ||
} | ||
|
||
// TODO other random steps: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done, or at least covered elsewhere. |
||
// - reboot a node | ||
// - abdicate leadership | ||
|
||
} catch (CoordinationStateRejectedException | UncheckedIOException ignored) { | ||
// This is ok: it just means a message couldn't currently be handled. | ||
} | ||
|
@@ -1254,7 +1250,6 @@ static class AckCollector implements ClusterStatePublisher.AckListener { | |
|
||
@Override | ||
public void onCommit(TimeValue commitTime) { | ||
// TODO we only currently care about per-node acks | ||
} | ||
|
||
@Override | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, see call to
ClusterBootstrapService::isBootstrapPlaceholder
indescribeQuorum
.