Some gproc_dists_tests are very unstable (namely, t_sync_cand_dies, t_fail_node, t_master_dies) about gproc HOT 6 CLOSED

Yes, the gproc_dist test in particular is a bit timing sensitive.

I believe I have an explanation for that, and have been working on a redesign of some parts. As usual, I've been distracted by other things, but will try to finish it asap.

from gproc.

Ok, got that. Meanwhile I'll just disable these three until they will be rewritten.

from gproc.

Actually, the case_clause error on gproc_dist_tests:562 has a very simple explanation: it assumes that the leader is one of two nodes, but there are in fact three nodes started in the test run. They are always in the same order in the Nodes list, and we can tell from the error that it was in fact the third node that was leader in this case. Duh.

**error:{case_clause,'dist_test_n3@buildvm-ppc64le-10'}

The way the test case works, we simply need to pick a node that isn't the leader, so that's an easy fix.

The other error, timeout in t_leader_dies() is likely more complex. Presumably, it's the rpc:call() to gproc_dist:sync() that takes too long, which might imply that the remaining nodes are stuck in their safe loops, and leader election, for some reason, has become protracted. This would be a gen_leader issue, presumably.

I have been meaning to switch to locks_leader, but the reason why I've delayed that is that while gen_leader has some obvious problems, it's by no means certain that switching to a component with no obvious problems will improve things. After all, gen_leader has seen much more use than locks_leader.

from gproc.

Ok, cool! I'm going to try it out.

from gproc.

Looks like it's much more stable now so I'm going to close this one issue.

I'll open a new one If any timing issues pop up again.

from gproc.

Yes, much more stable, but I'm still not really happy (but go ahead and close this issue). The next steps might be to move over to locks_leader, and also get up and running with QuickCheck-based testing.

from gproc.