diff options
author | Björn Gustavsson <[email protected]> | 2014-03-04 12:20:57 +0100 |
---|---|---|
committer | Björn Gustavsson <[email protected]> | 2014-03-06 12:06:23 +0100 |
commit | 651d8b9ab88b4bad73d37f3696b8d3cf0970a80d (patch) | |
tree | 7f99a5d2637809c773b413f7a29bc98f5ebb3af5 /lib/kernel | |
parent | 22494c65f5da5b06816c637141c40b14e829cb11 (diff) | |
download | otp-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