aboutsummaryrefslogtreecommitdiffstats
path: root/lib/tools/emacs
diff options
context:
space:
mode:
authorJean-Sébastien Pédron <[email protected]>2014-12-11 18:24:38 +0100
committerDan Gudmundsson <[email protected]>2015-02-10 14:42:24 +0100
commit70c4db1d0b57363e33a04c935b653092f68cb91a (patch)
tree36b9ca11521f1bf02e40284b7e6c9728becb6e49 /lib/tools/emacs
parentee17dd99f2a56499b13dc4c84578105ea1f14ff6 (diff)
downloadotp-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 'lib/tools/emacs')
0 files changed, 0 insertions, 0 deletions