| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| |/
|
|
|
| |
since that can result in completely forgetting about a member when
there are still acks making their way around the right.
|
| |
|
|
| |
in yet another place
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
...by using mnesia:write/3 instead of /1
and generally abstract mnesia reading/writing and make it dirty reads
obvious.
|
| |\ |
|
| | |
| |
| |
| | |
since the latter operates on the former
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| | |
eliminate branching
|
| |\ \ |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
We base promotion decisions on the sub-set of [QPid | SPids] that is
referenced in gm_pids. In particular, QPid may be missing from that,
if another slave previously noticed its death.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
...instead of LiveGMPids
The latter may be out of date s.t. it contains fewer pids than are
actually alive, due to new GMs having sprung into live recently. We'd
then, incorrectly, remove the corresponding entries from the queue's
mnesia record, causing havoc.
DeadGMPids can be out of date too; it may contain fewer pids than have
actually died, due to GMs having died more recently. That is harmless
though since it never leads us to remove an entry that we shouldn't,
and we will learn about any new deaths eventually.
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In a way this is a damage limitation exercise...
When a worker dies while working it is not in the pool anyway, so
noticing its death is a no-op.
When a worker dies while idle, it will not return to the pool when we
next submit work to it. But obviously the submitted work won't be
carried out, and the submitter will get an error (unless they
submitted the work asynchronously).
All the monitoring does is reduce the likelihood of the latter
happening. It cannot eliminate it though since the worker may die just
as work was being submitted to it.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
...instead of a queue.
That way when an idle worker is restarted (and sends an 'idle' message
to the pool), it won't end up in the pool twice.
Note that we always hand out work to the first worker in the
ordset. That is actually more efficient than the round-robin strategy
we had with the queue since it keeps a smaller number of workers busy
while others can hibernate.
|
| |\ \ \ \
| |/ / / |
|
| |/ / / |
|
| |\ \ \
| |/ / |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
| |\ \ |
|
| | | | |
|
| |\ \ \
| |/ /
|/| | |
|
| |/ / |
|
| |\ \
| |/ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously slaves were monitoring the master and sending a
process_death message through gm in an attempt to get the updated gm
state propagated (and thus members_changed callbacks getting invoked
on slaves, which in turn trigger promotion).
However, the DOWN notification for the master may well arrive and be
processed, and the process_death message sent around the ring, before
GM has noticed the master death, thus rendering the process_death
broadcast ineffectual for its intended purpose.
With the recent GM changes we can guarantee that at least one slave
will be notified of the master death via GM. So we emit the
process_death message then, and not on master DOWN (and ditch the
master monitoring as a result). Since the new emission is triggered by
a gm notification we know GM is aware of the master death, thus
avoiding the aforementioned problem.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When we receive a DOWN, it's possible that there are no messages from
the dead member floating around anyway. So rather than waiting for
some other activity to occur first, it is perfectly safe enough to
always call maybe_erase_aliases. That way we get slightly less lazy
death notification in this case (i.e. we can then be certain that
either the dead member is fully removed immediately or there must
still be messages from the dead member floating around. No other
possibility exists).
|
| | |
| |
| |
| |
| |
| | |
We had missed a case here.
Ditto for check_neighbours.
|
| |\ \
| |/ |
|
| | | |
|
| |/
|
|
| |
sure our GM does not try to update group info after we have called forget_group/1. Also ensure we unlink from the coordinator when shutting down as well as when stopping mirroring, not strictly necessary but clearer.
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| |/ |
|
| | |\ |
|
| | | |\ |
|
