summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* internal_error -> precondition_failedbug26120Alvaro Videla2014-04-291-5/+5
|
* updates intercept callback signatureAlvaro Videla2014-04-291-15/+10
|
* updates intercept callback typeAlvaro Videla2014-04-212-2/+2
|
* internal_error -> precondition_failedAlvaro Videla2014-04-211-6/+6
|
* stable to defaultSimon MacMullen2014-04-171-0/+3
|\
| * stable to defaultSimon MacMullen2014-04-173-88/+72
| |\
| * \ stable to defaultSimon MacMullen2014-04-171-0/+3
| |\ \
| | * \ stable to defaultSimon MacMullen2014-04-163-6/+9
| | |\ \
| | * \ \ merge stable into defaultMatthias Radestock2014-04-151-0/+3
| | |\ \ \
| | | * \ \ stable to defaultSimon MacMullen2014-04-151-0/+3
| | | |\ \ \
| | | | * \ \ stable to defaultSimon MacMullen2014-04-151-0/+3
| | | | |\ \ \
| | | | | * \ \ stable to defaultSimon MacMullen2014-04-141-0/+3
| | | | | |\ \ \
| | | | | | * \ \ merge stable into defaultMatthias Radestock2014-04-101-1/+1
| | | | | | |\ \ \
| | | | | | * \ \ \ stable to defaultSimon MacMullen2014-04-091-0/+3
| | | | | | |\ \ \ \
| | | | | | | * | | | ExplainSimon MacMullen2014-04-091-0/+3
| | | | | | | | | | |
| | | | | | | * | | | stable to defaultSimon MacMullen2014-04-090-0/+0
| | | | | | | |\ \ \ \
| | | | | | | | * \ \ \ stable to defaultSimon MacMullen2014-04-090-0/+0
| | | | | | | | |\ \ \ \
| | | | | | | | | * \ \ \ stable to defaultSimon MacMullen2014-04-091-1/+1
| | | | | | | | | |\ \ \ \
| | | | | | | | | * \ \ \ \ stable to defaultSimon MacMullen2014-04-081-4/+8
| | | | | | | | | |\ \ \ \ \
| | | | | | | | | * \ \ \ \ \ stable to defaultSimon MacMullen2014-04-040-0/+0
| | | | | | | | | |\ \ \ \ \ \
* | | | | | | | | | \ \ \ \ \ \ Merge bug26117Simon MacMullen2014-04-178-61/+73
|\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ | |_|_|_|_|_|_|_|_|_|_|_|_|_|_|/ |/| | | | | | | | | | | | | | |
| * | | | | | | | | | | | | | | explainbug26117Matthias Radestock2014-04-171-12/+17
| | | | | | | | | | | | | | | |
| * | | | | | | | | | | | | | | go back to from members_changed/4 to /3Matthias Radestock2014-04-177-21/+18
| | | | | | | | | | | | | | | |
| * | | | | | | | | | | | | | | always return DeadPids, so that all deaths are loggedMatthias Radestock2014-04-161-6/+5
| | | | | | | | | | | | | | | |
| * | | | | | | | | | | | | | | gm_pids is the source of truthMatthias Radestock2014-04-161-20/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | | | | | | | | | | | drive remove_from_queue with DeadGMPidsMatthias Radestock2014-04-163-28/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...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.
* | | | | | | | | | | | | | | | Merge bug 26123Simon MacMullen2014-04-173-88/+72
|\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ | |_|/ / / / / / / / / / / / / / |/| | | | | | | | | | | | | | |
| * | | | | | | | | | | | | | | monitor workersbug26123Matthias Radestock2014-04-162-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | | | | | | | | | | | track workers by Pid instead of nameMatthias Radestock2014-04-163-59/+37
| | | | | | | | | | | | | | | |
| * | | | | | | | | | | | | | | record workers in a setMatthias Radestock2014-04-161-35/+29
| | |_|_|_|_|_|_|_|_|_|_|_|_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...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.
* | | | | | | | | | | | | | | Merge bug26127Simon MacMullen2014-04-170-0/+0
|\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ | |/ / / / / / / / / / / / / /
* | | | | | | | | | | | | | | Remove rabbit_amqqueue:force_event_refresh/1 synchronybug26127Simon MacMullen2014-04-172-40/+22
|/ / / / / / / / / / / / / /
* | | | | | | | | | | | | | Merge bug26118Simon MacMullen2014-04-163-6/+11
|\ \ \ \ \ \ \ \ \ \ \ \ \ \ | |/ / / / / / / / / / / / /
| * | | | | | | | | | | | | cosmetic-ish: add a missing ?TABLE abstractionMatthias Radestock2014-04-161-4/+4
| | | | | | | | | | | | | |
| * | | | | | | | | | | | | cosmetic: prevent trailing whitespace in log messageMatthias Radestock2014-04-151-2/+2
| |/ / / / / / / / / / / /
| * | | | | | | | | | | | helper for starting a background rabbitMatthias Radestock2014-04-151-0/+5
| |/ / / / / / / / / / /
* | | | | | | | | | | | Handle hibernation in our pre-go state.bug26118Simon MacMullen2014-04-151-0/+3
|/ / / / / / / / / / /
* | | | | | | | | | | Merge bug26115Simon MacMullen2014-04-151-4/+4
|\ \ \ \ \ \ \ \ \ \ \ | |/ / / / / / / / / / |/| | | | | | | | | |
| * | | | | | | | | | eliminate accidental, crash-inducing assertionbug26115Matthias Radestock2014-04-141-4/+4
| |/ / / / / / / / /
* | | | | | | | | | Merge bug26113Simon MacMullen2014-04-151-1/+2
|\ \ \ \ \ \ \ \ \ \ | |/ / / / / / / / / |/| | | | | | | | |
| * | | | | | | | | Add a capability for it.bug26113Simon MacMullen2014-04-151-1/+2
|/ / / / / / / / /
* | | | | | | | | Merge bug26084Simon MacMullen2014-04-142-41/+26
|\ \ \ \ \ \ \ \ \
| * | | | | | | | | eliminate comment duplicationMatthias Radestock2014-04-141-4/+1
| | | | | | | | | |
| * | | | | | | | | ensure propagation of master deathMatthias Radestock2014-04-131-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | | | | | less lazy death notificationsMatthias Radestock2014-04-131-21/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
| * | | | | | | | | ensure callback_view_changed is called whenever the view may have changedMatthias Radestock2014-04-131-8/+8
| | |_|_|_|_|_|_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We had missed a case here. Ditto for check_neighbours.
* | | | | | | | | Merge bug26102Simon MacMullen2014-04-110-0/+0
|\ \ \ \ \ \ \ \ \ | |/ / / / / / / /
* | | | | | | | | Actually let's move the unlink/1 back, not convinced it is any clearer.bug26102Simon MacMullen2014-04-111-5/+4
| | | | | | | | |
* | | | | | | | | Monitor and wait for 'DOWN' from our own GM as well as the slaves, to make ↵Simon MacMullen2014-04-101-5/+6
|/ / / / / / / / | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | | | | | update copyright notice yearMatthias Radestock2014-04-101-1/+1
|/ / / / / / /
View Lorry Controller Status