Mixing
Will network interruption trigger monitor_node or link broken in Erlang/Elixir?
In distribution situation, for example 3 nodes running on different machines, they are connected default as clique in Erlang/Elixir. We call them A, B and C (they are connected explicitly by calling network:connect). Suppose network interruption between A and B happens.
1) Will the interruption between A and B trigger the linkage broken (spawn_link) between processes on A and B since we still have C as intermediate connected node. What about monitor_node (will that be triggered on A or B)?
2) Could we still send message from process of A to process of B since C works as intermediate connected node?
3) How does the membership components of Erlang/Elixir solve this situation? Will the connection be recovered and nothing bad really happens after all (no linkage broken, no monitor_node message returned just like everything are recovered immediately)?
Thank you for any consideration on this question!
erlang elixir otp
asked Nov 18 '18 at 22:32
chenyuandongchenyuandong
1667
add a comment |
In distribution situation, for example 3 nodes running on different machines, they are connected default as clique in Erlang/Elixir. We call them A, B and C (they are connected explicitly by calling network:connect). Suppose network interruption between A and B happens.
1) Will the interruption between A and B trigger the linkage broken (spawn_link) between processes on A and B since we still have C as intermediate connected node. What about monitor_node (will that be triggered on A or B)?
2) Could we still send message from process of A to process of B since C works as intermediate connected node?
3) How does the membership components of Erlang/Elixir solve this situation? Will the connection be recovered and nothing bad really happens after all (no linkage broken, no monitor_node message returned just like everything are recovered immediately)?
Thank you for any consideration on this question!
erlang elixir otp
asked Nov 18 '18 at 22:32
chenyuandongchenyuandong
1667
add a comment |
In distribution situation, for example 3 nodes running on different machines, they are connected default as clique in Erlang/Elixir. We call them A, B and C (they are connected explicitly by calling network:connect). Suppose network interruption between A and B happens.
1) Will the interruption between A and B trigger the linkage broken (spawn_link) between processes on A and B since we still have C as intermediate connected node. What about monitor_node (will that be triggered on A or B)?
2) Could we still send message from process of A to process of B since C works as intermediate connected node?
3) How does the membership components of Erlang/Elixir solve this situation? Will the connection be recovered and nothing bad really happens after all (no linkage broken, no monitor_node message returned just like everything are recovered immediately)?
Thank you for any consideration on this question!
erlang elixir otp
asked Nov 18 '18 at 22:32
chenyuandongchenyuandong
1667
In distribution situation, for example 3 nodes running on different machines, they are connected default as clique in Erlang/Elixir. We call them A, B and C (they are connected explicitly by calling network:connect). Suppose network interruption between A and B happens.
1) Will the interruption between A and B trigger the linkage broken (spawn_link) between processes on A and B since we still have C as intermediate connected node. What about monitor_node (will that be triggered on A or B)?
2) Could we still send message from process of A to process of B since C works as intermediate connected node?
3) How does the membership components of Erlang/Elixir solve this situation? Will the connection be recovered and nothing bad really happens after all (no linkage broken, no monitor_node message returned just like everything are recovered immediately)?
Thank you for any consideration on this question!
erlang elixir otp
erlang elixir otp
asked Nov 18 '18 at 22:32
chenyuandongchenyuandong
1667
asked Nov 18 '18 at 22:32
chenyuandongchenyuandong
1667
edited Nov 18 '18 at 23:50
chenyuandong
asked Nov 18 '18 at 22:32
chenyuandongchenyuandong
1667
asked Nov 18 '18 at 22:32
chenyuandongchenyuandong
1667
asked Nov 18 '18 at 22:32
chenyuandongchenyuandong
1667
1667
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
1) Will the interruption between A and B trigger the linkage broken (spawn_link) between processes on A and B since we still have C as intermediate connected node. What about monitor_node (will that be triggered on A or B)?
The default behaviour of Erlang nodes is to connect transitively, meaning that when functions like connect or ping are called from node A to B, if the connection is established A will also try to connect to all nodes known by B i.e. the list obtained when calling nodes() at node B.
2) Could we still send message from process of A to process of B since
C works as intermediate connected node?
It depends, if A is able to connect directly to B with the transitive behaviour that I have mentioned above, then it doesn't make any difference. See below :
A ----- C ----- B
This is how you would imagine the links between your nodes if you connect A to C and C to B. But actually it will look like this :
A ----- C
/
/
B
So even when node C is running, A won't go through it to reach B. But if going through C is the only physical way for A to reach B, then A and B won't be able to communicate anymore.
3) How does the membership components of Erlang/Elixir solve this
situation? Will the connection be recovered and nothing bad really
happens after all (no linkage broken, no monitor_node message returned
just like everything are recovered immediately)?
If a monitored node goes down, there will be a message of the form {nodedown, Node} sent to the monitoring process so that it can handle the failure. The connection will not be recovered unless the node itself recovers. If the failing node does not hold a critical role in the network for example, and other nodes can still communicate with each other, then you could say that nothing bad really happens.
But that would be in my opinion a pretty reckless way to see node failures, and even if Erlang is said to be fault tolerant, it should not be considered fault acceping i.e. one should always handle errors.
Hope this helps :)
answered Nov 20 '18 at 19:50
LaymerLaymer
665
So do node in Erlang only have topology knowledge of its directed connected neighbors? Since it is default clique topology, do any node just presume the neighbor is down (no matter if it connected indirectly) if network disruption happens?
– chenyuandong
Nov 20 '18 at 21:37
I think that there is no notion of direction in the topology. Every connection is bidirectional by default. Thenodes()function will return the list of nodes that the current node is connected to. If a node becomes unreachable because no more path to it exists, it will no longer appear in thenodes()list.
– Laymer
Nov 20 '18 at 22:37
add a comment |
1） Will the interruption between A and B trigger the linkage broken
(spawn_link) between processes on A and B since we still have C as
intermediate connected node. What about monitor_node (will that be triggered on A or B)?
2) Could we still send message from process of A to process of B
since C works as intermediate connected node?
Erlang had a service named epmd(Erlang Port Mapper Daemon) which will broadcast the nodes' info(ip, name) to other node, and these nodes will save them.
That means, each node has a info map about other nodes.
So if the network interruption can recover and the node are not dead(restart)，nodes can communicate as the same.
Above's situation can. Now talk about the can not communicate situation, which is epmd(Erlang Port Mapper Daemon) down. At this time, old nodes keep each others information so they can call each other. After restarting epmd, the new nodes created now can not call the old ones because old ones do not broad their info.
3) How does the membership components of Erlang/Elixir solve this
situation? Will the connection be recovered and nothing bad really
happens after all (no linkage broken, no monitor_node message returned
just like everything are recovered immediately)?
monitor_node will receive a message {nodedown, Node} if the connection to it is lost.
spawn_link just link two process and can only receive process down msg.
answered Nov 19 '18 at 9:56
YongHao HuYongHao Hu
1,512815
What do you mean by "old nodes" vs "new nodes"?
– chenyuandong
Nov 19 '18 at 18:29
So, even B is still alive, if A monitor_node B, it will receive {nodedown, B} after connection is lost? (note: we have C still connect to both A and B)
– chenyuandong
Nov 19 '18 at 18:41
@chenyuandong 1. A， B create 2.epmddown and restart 3. C， D created : A and B are old nodes, C and D are new nodes.
– YongHao Hu
Nov 20 '18 at 2:21
@chenyuandong Yes. A will receive{nodedown, B}. > monitor_node will receive a message {nodedown, Node} if the connection to it is lost. < is from doc.
– YongHao Hu
Nov 20 '18 at 2:23
Thank you very much!
– chenyuandong
Nov 20 '18 at 21:30
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53366096%2fwill-network-interruption-trigger-monitor-node-or-link-broken-in-erlang-elixir%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
1) Will the interruption between A and B trigger the linkage broken (spawn_link) between processes on A and B since we still have C as intermediate connected node. What about monitor_node (will that be triggered on A or B)?
The default behaviour of Erlang nodes is to connect transitively, meaning that when functions like connect or ping are called from node A to B, if the connection is established A will also try to connect to all nodes known by B i.e. the list obtained when calling nodes() at node B.
2) Could we still send message from process of A to process of B since
C works as intermediate connected node?
It depends, if A is able to connect directly to B with the transitive behaviour that I have mentioned above, then it doesn't make any difference. See below :
A ----- C ----- B
This is how you would imagine the links between your nodes if you connect A to C and C to B. But actually it will look like this :
A ----- C
/
/
B
So even when node C is running, A won't go through it to reach B. But if going through C is the only physical way for A to reach B, then A and B won't be able to communicate anymore.
3) How does the membership components of Erlang/Elixir solve this
situation? Will the connection be recovered and nothing bad really
happens after all (no linkage broken, no monitor_node message returned
just like everything are recovered immediately)?
If a monitored node goes down, there will be a message of the form {nodedown, Node} sent to the monitoring process so that it can handle the failure. The connection will not be recovered unless the node itself recovers. If the failing node does not hold a critical role in the network for example, and other nodes can still communicate with each other, then you could say that nothing bad really happens.
But that would be in my opinion a pretty reckless way to see node failures, and even if Erlang is said to be fault tolerant, it should not be considered fault acceping i.e. one should always handle errors.
Hope this helps :)
answered Nov 20 '18 at 19:50
LaymerLaymer
665
So do node in Erlang only have topology knowledge of its directed connected neighbors? Since it is default clique topology, do any node just presume the neighbor is down (no matter if it connected indirectly) if network disruption happens?
– chenyuandong
Nov 20 '18 at 21:37
I think that there is no notion of direction in the topology. Every connection is bidirectional by default. Thenodes()function will return the list of nodes that the current node is connected to. If a node becomes unreachable because no more path to it exists, it will no longer appear in thenodes()list.
– Laymer
Nov 20 '18 at 22:37
add a comment |
1) Will the interruption between A and B trigger the linkage broken (spawn_link) between processes on A and B since we still have C as intermediate connected node. What about monitor_node (will that be triggered on A or B)?
The default behaviour of Erlang nodes is to connect transitively, meaning that when functions like connect or ping are called from node A to B, if the connection is established A will also try to connect to all nodes known by B i.e. the list obtained when calling nodes() at node B.
2) Could we still send message from process of A to process of B since
C works as intermediate connected node?
It depends, if A is able to connect directly to B with the transitive behaviour that I have mentioned above, then it doesn't make any difference. See below :
A ----- C ----- B
This is how you would imagine the links between your nodes if you connect A to C and C to B. But actually it will look like this :
A ----- C
/
/
B
So even when node C is running, A won't go through it to reach B. But if going through C is the only physical way for A to reach B, then A and B won't be able to communicate anymore.
3) How does the membership components of Erlang/Elixir solve this
situation? Will the connection be recovered and nothing bad really
happens after all (no linkage broken, no monitor_node message returned
just like everything are recovered immediately)?
If a monitored node goes down, there will be a message of the form {nodedown, Node} sent to the monitoring process so that it can handle the failure. The connection will not be recovered unless the node itself recovers. If the failing node does not hold a critical role in the network for example, and other nodes can still communicate with each other, then you could say that nothing bad really happens.
But that would be in my opinion a pretty reckless way to see node failures, and even if Erlang is said to be fault tolerant, it should not be considered fault acceping i.e. one should always handle errors.
Hope this helps :)
answered Nov 20 '18 at 19:50
LaymerLaymer
665
So do node in Erlang only have topology knowledge of its directed connected neighbors? Since it is default clique topology, do any node just presume the neighbor is down (no matter if it connected indirectly) if network disruption happens?
– chenyuandong
Nov 20 '18 at 21:37
I think that there is no notion of direction in the topology. Every connection is bidirectional by default. Thenodes()function will return the list of nodes that the current node is connected to. If a node becomes unreachable because no more path to it exists, it will no longer appear in thenodes()list.
– Laymer
Nov 20 '18 at 22:37
add a comment |
1) Will the interruption between A and B trigger the linkage broken (spawn_link) between processes on A and B since we still have C as intermediate connected node. What about monitor_node (will that be triggered on A or B)?
The default behaviour of Erlang nodes is to connect transitively, meaning that when functions like connect or ping are called from node A to B, if the connection is established A will also try to connect to all nodes known by B i.e. the list obtained when calling nodes() at node B.
2) Could we still send message from process of A to process of B since
C works as intermediate connected node?
It depends, if A is able to connect directly to B with the transitive behaviour that I have mentioned above, then it doesn't make any difference. See below :
A ----- C ----- B
This is how you would imagine the links between your nodes if you connect A to C and C to B. But actually it will look like this :
A ----- C
/
/
B
So even when node C is running, A won't go through it to reach B. But if going through C is the only physical way for A to reach B, then A and B won't be able to communicate anymore.
3) How does the membership components of Erlang/Elixir solve this
situation? Will the connection be recovered and nothing bad really
happens after all (no linkage broken, no monitor_node message returned
just like everything are recovered immediately)?
If a monitored node goes down, there will be a message of the form {nodedown, Node} sent to the monitoring process so that it can handle the failure. The connection will not be recovered unless the node itself recovers. If the failing node does not hold a critical role in the network for example, and other nodes can still communicate with each other, then you could say that nothing bad really happens.
But that would be in my opinion a pretty reckless way to see node failures, and even if Erlang is said to be fault tolerant, it should not be considered fault acceping i.e. one should always handle errors.
Hope this helps :)
answered Nov 20 '18 at 19:50
LaymerLaymer
665
1) Will the interruption between A and B trigger the linkage broken (spawn_link) between processes on A and B since we still have C as intermediate connected node. What about monitor_node (will that be triggered on A or B)?
The default behaviour of Erlang nodes is to connect transitively, meaning that when functions like connect or ping are called from node A to B, if the connection is established A will also try to connect to all nodes known by B i.e. the list obtained when calling nodes() at node B.
2) Could we still send message from process of A to process of B since
C works as intermediate connected node?
It depends, if A is able to connect directly to B with the transitive behaviour that I have mentioned above, then it doesn't make any difference. See below :
A ----- C ----- B
This is how you would imagine the links between your nodes if you connect A to C and C to B. But actually it will look like this :
A ----- C
/
/
B
So even when node C is running, A won't go through it to reach B. But if going through C is the only physical way for A to reach B, then A and B won't be able to communicate anymore.
3) How does the membership components of Erlang/Elixir solve this
situation? Will the connection be recovered and nothing bad really
happens after all (no linkage broken, no monitor_node message returned
just like everything are recovered immediately)?
If a monitored node goes down, there will be a message of the form {nodedown, Node} sent to the monitoring process so that it can handle the failure. The connection will not be recovered unless the node itself recovers. If the failing node does not hold a critical role in the network for example, and other nodes can still communicate with each other, then you could say that nothing bad really happens.
But that would be in my opinion a pretty reckless way to see node failures, and even if Erlang is said to be fault tolerant, it should not be considered fault acceping i.e. one should always handle errors.
Hope this helps :)
answered Nov 20 '18 at 19:50
LaymerLaymer
665
answered Nov 20 '18 at 19:50
LaymerLaymer
665
answered Nov 20 '18 at 19:50
LaymerLaymer
665
answered Nov 20 '18 at 19:50
LaymerLaymer
665
665
So do node in Erlang only have topology knowledge of its directed connected neighbors? Since it is default clique topology, do any node just presume the neighbor is down (no matter if it connected indirectly) if network disruption happens?
– chenyuandong
Nov 20 '18 at 21:37
I think that there is no notion of direction in the topology. Every connection is bidirectional by default. Thenodes()function will return the list of nodes that the current node is connected to. If a node becomes unreachable because no more path to it exists, it will no longer appear in thenodes()list.
– Laymer
Nov 20 '18 at 22:37
add a comment |
So do node in Erlang only have topology knowledge of its directed connected neighbors? Since it is default clique topology, do any node just presume the neighbor is down (no matter if it connected indirectly) if network disruption happens?
– chenyuandong
Nov 20 '18 at 21:37
I think that there is no notion of direction in the topology. Every connection is bidirectional by default. Thenodes()function will return the list of nodes that the current node is connected to. If a node becomes unreachable because no more path to it exists, it will no longer appear in thenodes()list.
– Laymer
Nov 20 '18 at 22:37
So do node in Erlang only have topology knowledge of its directed connected neighbors? Since it is default clique topology, do any node just presume the neighbor is down (no matter if it connected indirectly) if network disruption happens?
– chenyuandong
Nov 20 '18 at 21:37
So do node in Erlang only have topology knowledge of its directed connected neighbors? Since it is default clique topology, do any node just presume the neighbor is down (no matter if it connected indirectly) if network disruption happens?
– chenyuandong
Nov 20 '18 at 21:37
I think that there is no notion of direction in the topology. Every connection is bidirectional by default. The
nodes() function will return the list of nodes that the current node is connected to. If a node becomes unreachable because no more path to it exists, it will no longer appear in the nodes() list.– Laymer
Nov 20 '18 at 22:37
I think that there is no notion of direction in the topology. Every connection is bidirectional by default. The
nodes() function will return the list of nodes that the current node is connected to. If a node becomes unreachable because no more path to it exists, it will no longer appear in the nodes() list.– Laymer
Nov 20 '18 at 22:37
add a comment |
1） Will the interruption between A and B trigger the linkage broken
(spawn_link) between processes on A and B since we still have C as
intermediate connected node. What about monitor_node (will that be triggered on A or B)?
2) Could we still send message from process of A to process of B
since C works as intermediate connected node?
Erlang had a service named epmd(Erlang Port Mapper Daemon) which will broadcast the nodes' info(ip, name) to other node, and these nodes will save them.
That means, each node has a info map about other nodes.
So if the network interruption can recover and the node are not dead(restart)，nodes can communicate as the same.
Above's situation can. Now talk about the can not communicate situation, which is epmd(Erlang Port Mapper Daemon) down. At this time, old nodes keep each others information so they can call each other. After restarting epmd, the new nodes created now can not call the old ones because old ones do not broad their info.
3) How does the membership components of Erlang/Elixir solve this
situation? Will the connection be recovered and nothing bad really
happens after all (no linkage broken, no monitor_node message returned
just like everything are recovered immediately)?
monitor_node will receive a message {nodedown, Node} if the connection to it is lost.
spawn_link just link two process and can only receive process down msg.
answered Nov 19 '18 at 9:56
YongHao HuYongHao Hu
1,512815
What do you mean by "old nodes" vs "new nodes"?
– chenyuandong
Nov 19 '18 at 18:29
So, even B is still alive, if A monitor_node B, it will receive {nodedown, B} after connection is lost? (note: we have C still connect to both A and B)
– chenyuandong
Nov 19 '18 at 18:41
@chenyuandong 1. A， B create 2.epmddown and restart 3. C， D created : A and B are old nodes, C and D are new nodes.
– YongHao Hu
Nov 20 '18 at 2:21
@chenyuandong Yes. A will receive{nodedown, B}. > monitor_node will receive a message {nodedown, Node} if the connection to it is lost. < is from doc.
– YongHao Hu
Nov 20 '18 at 2:23
Thank you very much!
– chenyuandong
Nov 20 '18 at 21:30
add a comment |
1） Will the interruption between A and B trigger the linkage broken
(spawn_link) between processes on A and B since we still have C as
intermediate connected node. What about monitor_node (will that be triggered on A or B)?
2) Could we still send message from process of A to process of B
since C works as intermediate connected node?
Erlang had a service named epmd(Erlang Port Mapper Daemon) which will broadcast the nodes' info(ip, name) to other node, and these nodes will save them.
That means, each node has a info map about other nodes.
So if the network interruption can recover and the node are not dead(restart)，nodes can communicate as the same.
Above's situation can. Now talk about the can not communicate situation, which is epmd(Erlang Port Mapper Daemon) down. At this time, old nodes keep each others information so they can call each other. After restarting epmd, the new nodes created now can not call the old ones because old ones do not broad their info.
3) How does the membership components of Erlang/Elixir solve this
situation? Will the connection be recovered and nothing bad really
happens after all (no linkage broken, no monitor_node message returned
just like everything are recovered immediately)?
monitor_node will receive a message {nodedown, Node} if the connection to it is lost.
spawn_link just link two process and can only receive process down msg.
answered Nov 19 '18 at 9:56
YongHao HuYongHao Hu
1,512815
What do you mean by "old nodes" vs "new nodes"?
– chenyuandong
Nov 19 '18 at 18:29
So, even B is still alive, if A monitor_node B, it will receive {nodedown, B} after connection is lost? (note: we have C still connect to both A and B)
– chenyuandong
Nov 19 '18 at 18:41
@chenyuandong 1. A， B create 2.epmddown and restart 3. C， D created : A and B are old nodes, C and D are new nodes.
– YongHao Hu
Nov 20 '18 at 2:21
@chenyuandong Yes. A will receive{nodedown, B}. > monitor_node will receive a message {nodedown, Node} if the connection to it is lost. < is from doc.
– YongHao Hu
Nov 20 '18 at 2:23
Thank you very much!
– chenyuandong
Nov 20 '18 at 21:30
add a comment |
1） Will the interruption between A and B trigger the linkage broken
(spawn_link) between processes on A and B since we still have C as
intermediate connected node. What about monitor_node (will that be triggered on A or B)?
2) Could we still send message from process of A to process of B
since C works as intermediate connected node?
Erlang had a service named epmd(Erlang Port Mapper Daemon) which will broadcast the nodes' info(ip, name) to other node, and these nodes will save them.
That means, each node has a info map about other nodes.
So if the network interruption can recover and the node are not dead(restart)，nodes can communicate as the same.
Above's situation can. Now talk about the can not communicate situation, which is epmd(Erlang Port Mapper Daemon) down. At this time, old nodes keep each others information so they can call each other. After restarting epmd, the new nodes created now can not call the old ones because old ones do not broad their info.
3) How does the membership components of Erlang/Elixir solve this
situation? Will the connection be recovered and nothing bad really
happens after all (no linkage broken, no monitor_node message returned
just like everything are recovered immediately)?
monitor_node will receive a message {nodedown, Node} if the connection to it is lost.
spawn_link just link two process and can only receive process down msg.
answered Nov 19 '18 at 9:56
YongHao HuYongHao Hu
1,512815
1） Will the interruption between A and B trigger the linkage broken
(spawn_link) between processes on A and B since we still have C as
intermediate connected node. What about monitor_node (will that be triggered on A or B)?
2) Could we still send message from process of A to process of B
since C works as intermediate connected node?
Erlang had a service named epmd(Erlang Port Mapper Daemon) which will broadcast the nodes' info(ip, name) to other node, and these nodes will save them.
That means, each node has a info map about other nodes.
So if the network interruption can recover and the node are not dead(restart)，nodes can communicate as the same.
Above's situation can. Now talk about the can not communicate situation, which is epmd(Erlang Port Mapper Daemon) down. At this time, old nodes keep each others information so they can call each other. After restarting epmd, the new nodes created now can not call the old ones because old ones do not broad their info.
3) How does the membership components of Erlang/Elixir solve this
situation? Will the connection be recovered and nothing bad really
happens after all (no linkage broken, no monitor_node message returned
just like everything are recovered immediately)?
monitor_node will receive a message {nodedown, Node} if the connection to it is lost.
spawn_link just link two process and can only receive process down msg.
answered Nov 19 '18 at 9:56
YongHao HuYongHao Hu
1,512815
answered Nov 19 '18 at 9:56
YongHao HuYongHao Hu
1,512815
answered Nov 19 '18 at 9:56
YongHao HuYongHao Hu
1,512815
answered Nov 19 '18 at 9:56
YongHao HuYongHao Hu
1,512815
1,512815
What do you mean by "old nodes" vs "new nodes"?
– chenyuandong
Nov 19 '18 at 18:29
So, even B is still alive, if A monitor_node B, it will receive {nodedown, B} after connection is lost? (note: we have C still connect to both A and B)
– chenyuandong
Nov 19 '18 at 18:41
@chenyuandong 1. A， B create 2.epmddown and restart 3. C， D created : A and B are old nodes, C and D are new nodes.
– YongHao Hu
Nov 20 '18 at 2:21
@chenyuandong Yes. A will receive{nodedown, B}. > monitor_node will receive a message {nodedown, Node} if the connection to it is lost. < is from doc.
– YongHao Hu
Nov 20 '18 at 2:23
Thank you very much!
– chenyuandong
Nov 20 '18 at 21:30
add a comment |
What do you mean by "old nodes" vs "new nodes"?
– chenyuandong
Nov 19 '18 at 18:29
So, even B is still alive, if A monitor_node B, it will receive {nodedown, B} after connection is lost? (note: we have C still connect to both A and B)
– chenyuandong
Nov 19 '18 at 18:41
@chenyuandong 1. A， B create 2.epmddown and restart 3. C， D created : A and B are old nodes, C and D are new nodes.
– YongHao Hu
Nov 20 '18 at 2:21
@chenyuandong Yes. A will receive{nodedown, B}. > monitor_node will receive a message {nodedown, Node} if the connection to it is lost. < is from doc.
– YongHao Hu
Nov 20 '18 at 2:23
Thank you very much!
– chenyuandong
Nov 20 '18 at 21:30
What do you mean by "old nodes" vs "new nodes"?
– chenyuandong
Nov 19 '18 at 18:29
What do you mean by "old nodes" vs "new nodes"?
– chenyuandong
Nov 19 '18 at 18:29
So, even B is still alive, if A monitor_node B, it will receive {nodedown, B} after connection is lost? (note: we have C still connect to both A and B)
– chenyuandong
Nov 19 '18 at 18:41
So, even B is still alive, if A monitor_node B, it will receive {nodedown, B} after connection is lost? (note: we have C still connect to both A and B)
– chenyuandong
Nov 19 '18 at 18:41
@chenyuandong 1. A， B create 2.
epmd down and restart 3. C， D created : A and B are old nodes, C and D are new nodes.– YongHao Hu
Nov 20 '18 at 2:21
@chenyuandong 1. A， B create 2.
epmd down and restart 3. C， D created : A and B are old nodes, C and D are new nodes.– YongHao Hu
Nov 20 '18 at 2:21
@chenyuandong Yes. A will receive
{nodedown, B} . > monitor_node will receive a message {nodedown, Node} if the connection to it is lost. < is from doc.– YongHao Hu
Nov 20 '18 at 2:23
@chenyuandong Yes. A will receive
{nodedown, B} . > monitor_node will receive a message {nodedown, Node} if the connection to it is lost. < is from doc.– YongHao Hu
Nov 20 '18 at 2:23
Thank you very much!
– chenyuandong
Nov 20 '18 at 21:30
Thank you very much!
– chenyuandong
Nov 20 '18 at 21:30
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53366096%2fwill-network-interruption-trigger-monitor-node-or-link-broken-in-erlang-elixir%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
