[PUBDEV-3173] Client does not need to provide full flatfile anymore to connect to the flatfile-based cluster. #113
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Test in progress. |
| // Note: this could cause a temporary flood of messages since the other | ||
| // nodes will later inform about the connected client as well. It would be helpful | ||
| // to have a control over flatfile-based multicast to inject a small wait. | ||
| if (h2o._heartbeat._client) { |
There was a problem hiding this comment.
Unnecessary check here ?
|
For me looks good. Already tested together with new sparkling water solution and works as expected. |
|
Thanks @madman0708 - MichalK had also a few comments which i need to integrate. But will merge soon. |
…o connect to the flatfile-based cluster.
Before this fix, the client was required to provide a flatfile with a list
of all nodes it would like to speak with (in fact all nodes in the cluster).
This fix changes the behaviour in the following way:
- an H2O client needs only a subset of all nodes to list in the flatfile, but at least a single node
- a regular H2O node which receives a heartbeat from a client node, adds it into a list of multicasted nodes and also
sends a message to all visible nodes with information about client connection (which contains address of client).
- when a regular node receives this event about client connection, it appends the received client information into
the list of nodes for multicast. Hence, the node is going send hearbeats to the client as well (not only the first node which was
contacted by the client initially).
- on the client side, when the client receives a message from a node outside its flatfile, it just appends the node into the list
of nodes for multicast
The fix also hides the field `H2O.STATIC_NODES` but provides API to access it.
Missing parts:
- the fix intentionally does not work in mixed environments (for example, backend based on multicast, client outside of multicast zone connecting via flatfile)
- explicit client disconnect event implementation (different jira)
mmalohlava
force-pushed
the
MM_PUBDEV-3173_client_mode_change
branch
from
1f5866a to
2ee836a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Before this fix, the client was required to provide a flatfile with a list
of all nodes it would like to speak with (in fact all nodes in the cluster).
This fix changes the behaviour in the following way:
sends a message to all visible nodes with information about client connection (which contains address of client).
the list of nodes for multicast. Hence, the node is going send hearbeats to the client as well (not only the first node which was
contacted by the client initially).
of nodes for multicast
Missing parts:
This change is