diff options
author | Jean-Sébastien Pédron <[email protected]> | 2014-12-11 18:24:38 +0100 |
---|---|---|
committer | Dan Gudmundsson <[email protected]> | 2015-02-10 14:42:24 +0100 |
commit | 70c4db1d0b57363e33a04c935b653092f68cb91a (patch) | |
tree | 36b9ca11521f1bf02e40284b7e6c9728becb6e49 /erts/test | |
parent | ee17dd99f2a56499b13dc4c84578105ea1f14ff6 (diff) | |
download | otp-70c4db1d0b57363e33a04c935b653092f68cb91a.tar.gz otp-70c4db1d0b57363e33a04c935b653092f68cb91a.tar.bz2 otp-70c4db1d0b57363e33a04c935b653092f68cb91a.zip |
mnesia: Check nodes after protocol negotiation
During Mnesia startup, after protocol negotiation, the list of connected
nodes is written to "recover_nodes". This list is later used to merge
the schema.
If Mnesia was stopped on a remote node between the protocol negotiation
and the moment the list is stored in "recover_nodes", the remote node
is still considered running: the value of "recover_nodes" stored during
mnesia_down/1 is overwritten. Therefore, this node may be used to
acquire a write lock on the schema in order to perform the merge. In
this case, the remote node never answers to the lock request and Mnesia
hang forever (application:start(mnesia) never returns).
To fix the problem, we check the list one last time and remove from it
all nodes where Mnesia is stopped. And because there is still a chance
for missing mnesia_down event, handle_cast({mnesia_down, ...}, ...)
writes to recover_nodes again, in addition to mnesia_down/1.
Diffstat (limited to 'erts/test')
0 files changed, 0 insertions, 0 deletions