aboutsummaryrefslogtreecommitdiffstats
path: root/lib/kernel
diff options
context:
space:
mode:
authorBjörn Gustavsson <[email protected]>2014-03-04 12:20:57 +0100
committerBjörn Gustavsson <[email protected]>2014-03-06 12:06:23 +0100
commit651d8b9ab88b4bad73d37f3696b8d3cf0970a80d (patch)
tree7f99a5d2637809c773b413f7a29bc98f5ebb3af5 /lib/kernel
parent22494c65f5da5b06816c637141c40b14e829cb11 (diff)
downloadotp-651d8b9ab88b4bad73d37f3696b8d3cf0970a80d.tar.gz
otp-651d8b9ab88b4bad73d37f3696b8d3cf0970a80d.tar.bz2
otp-651d8b9ab88b4bad73d37f3696b8d3cf0970a80d.zip
cover_SUITE:reconnect/1: Let the other side initiate the disconnect
The reconnect/1 test starts another node and takes down the connection to it for a while. However, it has been in observed in our daily builds that sometimes a "spontaneous" re-connection occurs. I think that it because of the call to rpc:cast/3 which internally will set the group leader for the remote process to a process on the test_server node. It seems that sometimes the group_leader/2 call will re-establish the connection. Unfortunately, I have not been able to force this to happen by inserting delays in the rpc module, so it it still just an hypothesis. However, letting the other node do the disconnection does seem to fix the problem and intuitively that should be safer way to do it because the group_leader/2 call and the disconnection will be executed sequentially on the same node instead of concurrently from two different nodes.
Diffstat (limited to 'lib/kernel')
0 files changed, 0 insertions, 0 deletions