Prevent node monitor crashing from doing multiple node disconnects in unstable networks #9663
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proposed Changes
When nodes are already disconnected on erlang dist layer, we want to avoid repeated explicit disconnects
by
rabbit_node_monitor
when detecting a partial partition. Doing so once until node reconnects is enough.Repeated disconnections (e.g.
up
|down
messages queued in node monitor's mailbox in unstable networks)has been seen to cause application controller timeouts and node monitor terminations, which in most cases
fails to recover indefinitely. See crash below. Partial partition disconnect from
rabbit@host-309
followed by{partial_partition_disconnect, 'rabbit@host-309'}
request.This PR also adds announcement of partition handling strategy on the node monitor start-up log (no need to
check environment for this).
Types of Changes
What types of changes does your code introduce to this project?
Put an
x
in the boxes that applyChecklist
Put an
x
in the boxes that apply.You can also fill these out after creating the PR.
If you're unsure about any of them, don't hesitate to ask on the mailing list.
We're here to help!
This is simply a reminder of what we are going to look for before merging your code.
CONTRIBUTING.md
documentFurther Comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc.