<div dir="ltr">Hi,<div><br></div><div>Global can indeed end up in inconsistent states if some nodes get disconnected from each other (so you're no longer running on a fully connected mesh). Since when registering a global name on node X the change is only propagated to nodes that X are directly connected to, you can end up in a situation that X and Y are connected together, so they will both know about the name, and Y and Z are connected together but X and Z are not, so Z never gets the update.</div><div><br></div><div>When two nodes (re)connect, they only compare the names they locally know about. So it is a bit tricky, but you can actually end up in a situation when all nodes are connected, yet the global name databases are inconsistent. You will need at least 4 nodes for this scenario to happen (e.g. A, B, C & D):</div><div><ol><li>All nodes are connected initially.</li><li>A gets disconnected from C.</li><li>A registers process X under some name: this gets propagated to B & D, but not C.</li><li>B gets disconnected from D.</li><li>B re-registers process Y under some name: this gets propagated to A & C, but not D, so on D the name still belongs to X.</li><li>A reconnects to C, since they both know the name belongs to Y they will inform their half of the network about the new node, but won't issue any global name updates.</li><li>You have all 4 nodes connected again, but A, B & C believe the name belongs to Y, while D believes it belongs to X.</li></ol><div>So this can happen, if you know how global works you can understand how it can happen, but I don't think it would be expected by many people to actually happen. :)</div></div><div><br></div><div>global:sync() is not really meant to resolve this error. The only solution I know about is to manually compare global name registrations shortly after you see a new node connecting.</div><div><br></div><div>Cheers,</div><div>Daniel</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 12 Oct 2020 at 09:23, saket chaudhary <<a href="mailto:saketcmf@gmail.com">saketcmf@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">We hit upon an issue in production where two erlang nodes in the same cluster agreed on the set of neighbour nodes (nodes() call) but diverged on the globally registered names (global:registered_name()). We're running OTP 23.0.2, but have hit these issues infrequently in the past with OTP17 as well. <div><br></div><div>Calling global:sync() or even net_adm:ping/1 for the remote node that had the globally registered process didn't help. We verified global registration of new names was being propagated across all the nodes. However, it didn't help fix the old names that had diverged. Ultimately, we had to manually re-register the name using a remote shell.<div><br></div><div>Does anyone know if this is expected? I thought the erlang nodes would gossip their way through to resolve any inconsistencies.</div></div></div>
</blockquote></div>