diff options
| -rw-r--r-- | src/rabbit_amqqueue.erl | 10 | ||||
| -rw-r--r-- | src/rabbit_mirror_queue_coordinator.erl | 68 | ||||
| -rw-r--r-- | src/rabbit_mirror_queue_master.erl | 6 | ||||
| -rw-r--r-- | src/rabbit_mirror_queue_misc.erl | 24 | ||||
| -rw-r--r-- | src/rabbit_mirror_queue_mode.erl | 6 | ||||
| -rw-r--r-- | src/rabbit_mirror_queue_mode_nodes.erl | 2 | ||||
| -rw-r--r-- | src/rabbit_mirror_queue_slave.erl | 8 | ||||
| -rw-r--r-- | src/rabbit_mirror_queue_sync.erl | 12 | ||||
| -rw-r--r-- | src/rabbit_prequeue.erl | 2 | ||||
| -rw-r--r-- | test/dynamic_ha_SUITE.erl | 8 | ||||
| -rw-r--r-- | test/many_node_ha_SUITE.erl | 2 | ||||
| -rw-r--r-- | test/priority_queue_SUITE.erl | 14 | ||||
| -rw-r--r-- | test/simple_ha_SUITE.erl | 8 |
13 files changed, 85 insertions, 85 deletions
diff --git a/src/rabbit_amqqueue.erl b/src/rabbit_amqqueue.erl index 7d1837550a..fbf169363e 100644 --- a/src/rabbit_amqqueue.erl +++ b/src/rabbit_amqqueue.erl @@ -679,7 +679,7 @@ with(#resource{} = Name, F, E, RetriesLeft) -> {ok, Q} when ?amqqueue_state_is(Q, crashed) -> E({absent, Q, crashed}); %% The queue process has been stopped by a supervisor. - %% In that case a synchronised slave can take over + %% In that case a synchronised mirror can take over %% so we should retry. {ok, Q} when ?amqqueue_state_is(Q, stopped) -> %% The queue process was stopped by the supervisor @@ -715,7 +715,7 @@ retry_wait(Q, F, E, RetriesLeft) -> QState = amqqueue:get_state(Q), case {QState, is_replicated(Q)} of %% We don't want to repeat an operation if - %% there are no slaves to migrate to + %% there are no mirrors to migrate to {stopped, false} -> E({absent, Q, stopped}); _ -> @@ -1869,7 +1869,7 @@ forget_node_for_queue(DeadNode, Q) -> forget_node_for_queue(DeadNode, RS, Q). forget_node_for_queue(_DeadNode, [], Q) -> - %% No slaves to recover from, queue is gone. + %% No mirrors to recover from, queue is gone. %% Don't process_deletions since that just calls callbacks and we %% are not really up. Name = amqqueue:get_name(Q), @@ -1986,7 +1986,7 @@ maybe_clear_recoverable_node(Node, Q) -> %% by the incoming slave node and this function, called %% by the master node. If this function is executed after %% record_synchronised/1, the node is erroneously removed - %% from the recoverable slaves list. + %% from the recoverable mirrors list. %% %% We check if the slave node's queue PID is alive. If it is %% the case, then this function is executed after. In this @@ -2134,7 +2134,7 @@ deliver(Qs, Delivery = #delivery{flow = Flow, noflow -> ok end, - %% We let slaves know that they were being addressed as slaves at + %% We let mirrors know that they were being addressed as mirrors at %% the time - if they receive such a message from the channel %% after they have become master they should mark the message as %% 'delivered' since they do not know what the master may have diff --git a/src/rabbit_mirror_queue_coordinator.erl b/src/rabbit_mirror_queue_coordinator.erl index 9c185b0f24..2437f77b09 100644 --- a/src/rabbit_mirror_queue_coordinator.erl +++ b/src/rabbit_mirror_queue_coordinator.erl @@ -48,7 +48,7 @@ %% +----------+ +-------+--------------+-----------...etc... %% | | | %% V V V -%% amqqueue_process---+ slave-----+ slave-----+ ...etc... +%% amqqueue_process---+ mirror-----+ mirror-----+ ...etc... %% | BQ = master----+ | | BQ = vq | | BQ = vq | %% | | BQ = vq | | +-+-------+ +-+-------+ %% | +-+-------+ | | | @@ -63,50 +63,50 @@ %% consumers %% %% The master is merely an implementation of bq, and thus is invoked -%% through the normal bq interface by the amqqueue_process. The slaves +%% through the normal bq interface by the amqqueue_process. The mirrors %% meanwhile are processes in their own right (as is the -%% coordinator). The coordinator and all slaves belong to the same gm +%% coordinator). The coordinator and all mirrors belong to the same gm %% group. Every member of a gm group receives messages sent to the gm %% group. Because the master is the bq of amqqueue_process, it doesn't %% have sole control over its mailbox, and as a result, the master %% itself cannot be passed messages directly (well, it could by via %% the amqqueue:run_backing_queue callback but that would induce %% additional unnecessary loading on the master queue process), yet it -%% needs to react to gm events, such as the death of slaves. Thus the +%% needs to react to gm events, such as the death of mirrors. Thus the %% master creates the coordinator, and it is the coordinator that is %% the gm callback module and event handler for the master. %% %% Consumers are only attached to the master. Thus the master is -%% responsible for informing all slaves when messages are fetched from +%% responsible for informing all mirrors when messages are fetched from %% the bq, when they're acked, and when they're requeued. %% -%% The basic goal is to ensure that all slaves performs actions on +%% The basic goal is to ensure that all mirrors performs actions on %% their bqs in the same order as the master. Thus the master %% intercepts all events going to its bq, and suitably broadcasts -%% these events on the gm. The slaves thus receive two streams of +%% these events on the gm. The mirrors thus receive two streams of %% events: one stream is via the gm, and one stream is from channels %% directly. Whilst the stream via gm is guaranteed to be consistently -%% seen by all slaves, the same is not true of the stream via +%% seen by all mirrors , the same is not true of the stream via %% channels. For example, in the event of an unexpected death of a %% channel during a publish, only some of the mirrors may receive that %% publish. As a result of this problem, the messages broadcast over -%% the gm contain published content, and thus slaves can operate +%% the gm contain published content, and thus mirrors can operate %% successfully on messages that they only receive via the gm. %% %% The key purpose of also sending messages directly from the channels -%% to the slaves is that without this, in the event of the death of +%% to the mirrors is that without this, in the event of the death of %% the master, messages could be lost until a suitable slave is %% promoted. However, that is not the only reason. A slave cannot send %% confirms for a message until it has seen it from the %% channel. Otherwise, it might send a confirm to a channel for a %% message that it might *never* receive from that channel. This can -%% happen because new slaves join the gm ring (and thus receive +%% happen because new mirrors join the gm ring (and thus receive %% messages from the master) before inserting themselves in the %% queue's mnesia record (which is what channels look at for routing). %% As it turns out, channels will simply ignore such bogus confirms, %% but relying on that would introduce a dangerously tight coupling. %% -%% Hence the slaves have to wait until they've seen both the publish +%% Hence the mirrors have to wait until they've seen both the publish %% via gm, and the publish via the channel before they issue the %% confirm. Either form of publish can arrive first, and a slave can %% be upgraded to the master at any point during this @@ -116,7 +116,7 @@ %% amqqueue API. However, it does not need to implement all parts: for %% example, no ack or consumer-related message can arrive directly at %% a slave from a channel: it is only publishes that pass both -%% directly to the slaves and go via gm. +%% directly to the mirrors and go via gm. %% %% Slaves can be added dynamically. When this occurs, there is no %% attempt made to sync the current contents of the master with the @@ -144,18 +144,18 @@ %% the master queue but can't go back in the slave, since we don't %% want "holes" in the slave queue. Note that the depth, and the %% length likewise, must always be shorter on the slave - we assert -%% that in various places. In case slaves are joined to an empty queue +%% that in various places. In case mirrors are joined to an empty queue %% which only goes on to receive publishes, they start by asking the -%% master to broadcast its depth. This is enough for slaves to always +%% master to broadcast its depth. This is enough for mirrors to always %% be able to work out when their head does not differ from the master %% (and is much simpler and cheaper than getting the master to hang on %% to the guid of the msg at the head of its queue). When a slave is %% promoted to a master, it unilaterally broadcasts its depth, in -%% order to solve the problem of depth requests from new slaves being +%% order to solve the problem of depth requests from new mirrors being %% unanswered by a dead master. %% %% Obviously, due to the async nature of communication across gm, the -%% slaves can fall behind. This does not matter from a sync pov: if +%% mirrors can fall behind. This does not matter from a sync pov: if %% they fall behind and the master dies then a) no publishes are lost %% because all publishes go to all mirrors anyway; b) the worst that %% happens is that acks get lost and so messages come back to @@ -164,12 +164,12 @@ %% but close enough for jazz). %% %% Because acktags are issued by the bq independently, and because -%% there is no requirement for the master and all slaves to use the +%% there is no requirement for the master and all mirrors to use the %% same bq, all references to msgs going over gm is by msg_id. Thus %% upon acking, the master must convert the acktags back to msg_ids %% (which happens to be what bq:ack returns), then sends the msg_ids -%% over gm, the slaves must convert the msg_ids to acktags (a mapping -%% the slaves themselves must maintain). +%% over gm, the mirrors must convert the msg_ids to acktags (a mapping +%% the mirrors themselves must maintain). %% %% When the master dies, a slave gets promoted. This will be the %% eldest slave, and thus the hope is that that slave is most likely @@ -196,9 +196,9 @@ %% mirrors to be able to detect this and tidy up as necessary to avoid %% leaks. If we just had the master monitoring all senders then we %% would have the possibility that a sender appears and only sends the -%% message to a few of the slaves before dying. Those slaves would +%% message to a few of the mirrors before dying. Those mirrors would %% then hold on to the message, assuming they'll receive some -%% instruction eventually from the master. Thus we have both slaves +%% instruction eventually from the master. Thus we have both mirrors %% and the master monitor all senders they become aware of. But there %% is a race: if the slave receives a DOWN of a sender, how does it %% know whether or not the master is going to send it instructions @@ -209,8 +209,8 @@ %% coordinator receives a DOWN message from a sender, it informs the %% master via a callback. This allows the master to do any tidying %% necessary, but more importantly allows the master to broadcast a -%% sender_death message to all the slaves, saying the sender has -%% died. Once the slaves receive the sender_death message, they know +%% sender_death message to all the mirrors , saying the sender has +%% died. Once the mirrors receive the sender_death message, they know %% that they're not going to receive any more instructions from the gm %% regarding that sender. However, it is possible that the coordinator %% receives the DOWN and communicates that to the master before the @@ -230,11 +230,11 @@ %% received the sender_death message from the master via gm already, %% then it will wait 20 seconds before broadcasting a request for %% confirmation from the master that the sender really has died. -%% Should a sender have only sent a publish to slaves, this allows -%% slaves to inform the master of the previous existence of the +%% Should a sender have only sent a publish to mirrors , this allows +%% mirrors to inform the master of the previous existence of the %% sender. The master will thus monitor the sender, receive the DOWN, %% and subsequently broadcast the sender_death message, allowing the -%% slaves to tidy up. This process can repeat for the same sender: +%% mirrors to tidy up. This process can repeat for the same sender: %% consider one slave receives the publication, then the DOWN, then %% asks for confirmation of death, then the master broadcasts the %% sender_death message. Only then does another slave receive the @@ -248,7 +248,7 @@ %% When the 20 second timer expires, the slave first checks to see %% whether it still needs confirmation of the death before requesting %% it. This prevents unnecessary traffic on gm as it allows one -%% broadcast of the sender_death message to satisfy many slaves. +%% broadcast of the sender_death message to satisfy many mirrors. %% %% If we consider the promotion of a slave at this point, we have two %% possibilities: that of the slave that has received the DOWN and is @@ -257,14 +257,14 @@ %% DOWN. In the first case, in the act of promotion to master, the new %% master will monitor again the dead sender, and after it has %% finished promoting itself, it should find another DOWN waiting, -%% which it will then broadcast. This will allow slaves to tidy up as +%% which it will then broadcast. This will allow mirrors to tidy up as %% normal. In the second case, we have the possibility that %% confirmation-of-sender-death request has been broadcast, but that %% it was broadcast before the master failed, and that the slave being %% promoted does not know anything about that sender, and so will not %% monitor it on promotion. Thus a slave that broadcasts such a %% request, at the point of broadcasting it, recurses, setting another -%% 20 second timer. As before, on expiry of the timer, the slaves +%% 20 second timer. As before, on expiry of the timer, the mirrors %% checks to see whether it still has not received a sender_death %% message for the dead sender, and if not, broadcasts a death %% confirmation request. Thus this ensures that even when a master @@ -273,12 +273,12 @@ %% dead sender, receive the DOWN and broadcast the sender_death %% message. %% -%% The preceding commentary deals with the possibility of slaves +%% The preceding commentary deals with the possibility of mirrors %% receiving publications from senders which the master does not, and %% the need to prevent memory leaks in such scenarios. The inverse is %% also possible: a partial publication may cause only the master to %% receive a publication. It will then publish the message via gm. The -%% slaves will receive it via gm, will publish it to their BQ and will +%% mirrors will receive it via gm, will publish it to their BQ and will %% set up monitoring on the sender. They will then receive the DOWN %% message and the master will eventually publish the corresponding %% sender_death message. The slave will then be able to tidy up its @@ -419,7 +419,7 @@ handle_pre_hibernate(State = #state { gm = GM }) -> %% timely notification of slave death if policy changes when %% everything is idle. So cause some activity just before we %% sleep. This won't cause us to go into perpetual motion as the - %% heartbeat does not wake up coordinator or slaves. + %% heartbeat does not wake up coordinator or mirrors. gm:broadcast(GM, hibernate_heartbeat), {hibernate, State}. @@ -446,7 +446,7 @@ handle_msg([_CPid], _From, {delete_and_terminate, _Reason}) -> %% actually delivered. Then it calls handle_terminate/2 below so the %% coordinator is stopped. %% - %% If we stop the coordinator right now, remote slaves could see the + %% If we stop the coordinator right now, remote mirrors could see the %% coordinator DOWN before delete_and_terminate was delivered to all %% GMs. One of those GM would be promoted as the master, and this GM %% would hang forever, waiting for other GMs to stop. diff --git a/src/rabbit_mirror_queue_master.erl b/src/rabbit_mirror_queue_master.erl index cf0c196a73..96c96bd689 100644 --- a/src/rabbit_mirror_queue_master.erl +++ b/src/rabbit_mirror_queue_master.erl @@ -118,9 +118,9 @@ init_with_existing_bq(Q0, BQ, BQS) when ?is_amqqueue(Q0) -> {_MNode, SNodes} = rabbit_mirror_queue_misc:suggested_queue_nodes(Q0), %% We need synchronous add here (i.e. do not return until the %% slave is running) so that when queue declaration is finished - %% all slaves are up; we don't want to end up with unsynced slaves + %% all mirrors are up; we don't want to end up with unsynced mirrors %% just by declaring a new queue. But add can't be synchronous all - %% the time as it can be called by slaves and that's + %% the time as it can be called by mirrors and that's %% deadlock-prone. rabbit_mirror_queue_misc:add_mirrors(QName, SNodes, sync), #state{name = QName, @@ -207,7 +207,7 @@ terminate(Reason, true -> %% Remove the whole queue to avoid data loss rabbit_mirror_queue_misc:log_warning( QName, "Stopping all nodes on master shutdown since no " - "synchronised slave is available~n", []), + "synchronised mirror (replica) is available~n", []), stop_all_slaves(Reason, State); false -> %% Just let some other slave take over. ok diff --git a/src/rabbit_mirror_queue_misc.erl b/src/rabbit_mirror_queue_misc.erl index d92e74ea7e..df878986bf 100644 --- a/src/rabbit_mirror_queue_misc.erl +++ b/src/rabbit_mirror_queue_misc.erl @@ -317,11 +317,11 @@ store_updated_slaves(Q0) when ?is_amqqueue(Q0) -> %% Recoverable nodes are those which we could promote if the whole %% cluster were to suddenly stop and we then lose the master; i.e. all -%% nodes with running slaves, and all stopped nodes which had running -%% slaves when they were up. +%% nodes with running mirrors , and all stopped nodes which had running +%% mirrors when they were up. %% -%% Therefore we aim here to add new nodes with slaves, and remove -%% running nodes without slaves, We also try to keep the order +%% Therefore we aim here to add new nodes with mirrors , and remove +%% running nodes without mirrors , We also try to keep the order %% constant, and similar to the live SPids field (i.e. oldest %% first). That's not necessarily optimal if nodes spend a long time %% down, but we don't have a good way to predict what the optimal is @@ -337,10 +337,10 @@ update_recoverable(SPids, RS) -> stop_all_slaves(Reason, SPids, QName, GM, WaitTimeout) -> PidsMRefs = [{Pid, erlang:monitor(process, Pid)} || Pid <- [GM | SPids]], ok = gm:broadcast(GM, {delete_and_terminate, Reason}), - %% It's possible that we could be partitioned from some slaves + %% It's possible that we could be partitioned from some mirrors %% between the lookup and the broadcast, in which case we could %% monitor them but they would not have received the GM - %% message. So only wait for slaves which are still + %% message. So only wait for mirrors which are still %% not-partitioned. PendingSlavePids = lists:foldl(fun({Pid, MRef}, Acc) -> case rabbit_mnesia:on_running_node(Pid) of @@ -365,7 +365,7 @@ stop_all_slaves(Reason, SPids, QName, GM, WaitTimeout) -> [Q0] = mnesia:read({rabbit_queue, QName}), Q1 = amqqueue:set_gm_pids(Q0, []), Q2 = amqqueue:set_slave_pids(Q1, []), - %% Restarted slaves on running nodes can + %% Restarted mirrors on running nodes can %% ensure old incarnations are stopped using %% the pending slave pids. Q3 = amqqueue:set_slave_pids_pending_shutdown(Q2, PendingSlavePids), @@ -534,10 +534,10 @@ update_mirrors(Q) when ?is_amqqueue(Q) -> OldNodes = [OldMNode | OldSNodes], NewNodes = [NewMNode | NewSNodes], %% When a mirror dies, remove_from_queue/2 might have to add new - %% slaves (in "exactly" mode). It will check mnesia to see which - %% slaves there currently are. If drop_mirror/2 is invoked first + %% mirrors (in "exactly" mode). It will check mnesia to see which + %% mirrors there currently are. If drop_mirror/2 is invoked first %% then when we end up in remove_from_queue/2 it will not see the - %% slaves that add_mirror/2 will add, and also want to add them + %% mirrors that add_mirror/2 will add, and also want to add them %% (even though we are not responding to the death of a %% mirror). Breakage ensues. add_mirrors (QName, NewNodes -- OldNodes, async), @@ -589,7 +589,7 @@ wait_for_new_master(QName, Destination, N) -> %% The arrival of a newly synced slave may cause the master to die if %% the policy does not want the master but it has been kept alive -%% because there were no synced slaves. +%% because there were no synced mirrors. %% %% We don't just call update_mirrors/2 here since that could decide to %% start a slave for some other reason, and since we are the slave ATM @@ -608,7 +608,7 @@ maybe_drop_master_after_sync(Q) when ?is_amqqueue(Q) -> end, ok. %% [0] ASSERTION - if the policy wants the master to change, it has -%% not just shuffled it into the slaves. All our modes ensure this +%% not just shuffled it into the mirrors. All our modes ensure this %% does not happen, but we should guard against a misbehaving plugin. %%---------------------------------------------------------------------------- diff --git a/src/rabbit_mirror_queue_mode.erl b/src/rabbit_mirror_queue_mode.erl index 377c98f726..8c335668f6 100644 --- a/src/rabbit_mirror_queue_mode.erl +++ b/src/rabbit_mirror_queue_mode.erl @@ -33,11 +33,11 @@ %% %% Takes: parameters set in the policy, %% current master, -%% current slaves, -%% current synchronised slaves, +%% current mirrors, +%% current synchronised mirrors, %% all nodes to consider %% -%% Returns: tuple of new master, new slaves +%% Returns: tuple of new master, new mirrors %% -callback suggested_queue_nodes( params(), master(), [slave()], [slave()], [node()]) -> diff --git a/src/rabbit_mirror_queue_mode_nodes.erl b/src/rabbit_mirror_queue_mode_nodes.erl index af6ddaef49..df9fe6fafe 100644 --- a/src/rabbit_mirror_queue_mode_nodes.erl +++ b/src/rabbit_mirror_queue_mode_nodes.erl @@ -35,7 +35,7 @@ description() -> suggested_queue_nodes(PolicyNodes0, CurrentMaster, _SNodes, SSNodes, NodesRunningRabbitMQ) -> PolicyNodes1 = [list_to_atom(binary_to_list(Node)) || Node <- PolicyNodes0], %% If the current master is not in the nodes specified, then what we want - %% to do depends on whether there are any synchronised slaves. If there + %% to do depends on whether there are any synchronised mirrors. If there %% are then we can just kill the current master - the admin has asked for %% a migration and we should give it to them. If there are not however %% then we must keep the master around so as not to lose messages. diff --git a/src/rabbit_mirror_queue_slave.erl b/src/rabbit_mirror_queue_slave.erl index 0c880e9a5d..f9651a035f 100644 --- a/src/rabbit_mirror_queue_slave.erl +++ b/src/rabbit_mirror_queue_slave.erl @@ -193,8 +193,8 @@ init_it(Self, GM, Node, QName) -> master_in_recovery end. -%% Pending slaves have been asked to stop by the master, but despite the node -%% being up these did not answer on the expected timeout. Stop local slaves now. +%% Pending mirrors have been asked to stop by the master, but despite the node +%% being up these did not answer on the expected timeout. Stop local mirrors now. stop_pending_slaves(QName, Pids) -> [begin rabbit_mirror_queue_misc:log_warning( @@ -276,7 +276,7 @@ handle_call({gm_deaths, DeadGMPids}, From, end, %% Since GM is by nature lazy we need to make sure %% there is some traffic when a master dies, to - %% make sure all slaves get informed of the + %% make sure all mirrors get informed of the %% death. That is all process_death does, create %% some traffic. ok = gm:broadcast(GM, process_death), @@ -323,7 +323,7 @@ handle_cast({deliver, Delivery = #delivery{sender = Sender, flow = Flow}, true}, %% the message delivery. See %% rabbit_amqqueue_process:handle_ch_down for more info. %% If message is rejected by the master, the publish will be nacked - %% even if slaves confirm it. No need to check for length here. + %% even if mirrors confirm it. No need to check for length here. maybe_flow_ack(Sender, Flow), noreply(maybe_enqueue_message(Delivery, State)); diff --git a/src/rabbit_mirror_queue_sync.erl b/src/rabbit_mirror_queue_sync.erl index c516470bf9..76774e4f2b 100644 --- a/src/rabbit_mirror_queue_sync.erl +++ b/src/rabbit_mirror_queue_sync.erl @@ -194,11 +194,11 @@ handle_set_maximum_since_use() -> syncer(Ref, Log, MPid, SPids) -> [erlang:monitor(process, SPid) || SPid <- SPids], - %% We wait for a reply from the slaves so that we know they are in + %% We wait for a reply from the mirrors so that we know they are in %% a receive block and will thus receive messages we send to them %% *without* those messages ending up in their gen_server2 pqueue. case await_slaves(Ref, SPids) of - [] -> Log("all slaves already synced", []); + [] -> Log("all mirrors already synced", []); SPids1 -> MPid ! {ready, self()}, Log("mirrors ~p to sync", [[node(SPid) || SPid <- SPids1]]), syncer_check_resources(Ref, MPid, SPids1) @@ -214,7 +214,7 @@ await_slaves(Ref, SPids) -> end]. %% [0] This check is in case there's been a partition which has then %% healed in between the master retrieving the slave pids from Mnesia -%% and sending 'sync_start' over GM. If so there might be slaves on the +%% and sending 'sync_start' over GM. If so there might be mirrors on the %% other side of the partition which we can monitor (since they have %% rejoined the distributed system with us) but which did not get the %% 'sync_start' and so will not reply. We need to act as though they are @@ -257,7 +257,7 @@ syncer_loop(Ref, MPid, SPids) -> SPids1 = wait_for_credit(SPids), case SPids1 of [] -> - % Die silently because there are no slaves left. + % Die silently because there are no mirrors left. ok; _ -> broadcast(SPids1, {sync_msgs, Ref, Msgs}), @@ -265,7 +265,7 @@ syncer_loop(Ref, MPid, SPids) -> syncer_loop(Ref, MPid, SPids1) end; {cancel, Ref} -> - %% We don't tell the slaves we will die - so when we do + %% We don't tell the mirrors we will die - so when we do %% they interpret that as a failure, which is what we %% want. ok; @@ -304,7 +304,7 @@ wait_for_resources(Ref, SPids) -> %% Ignore other alerts. wait_for_resources(Ref, SPids); {cancel, Ref} -> - %% We don't tell the slaves we will die - so when we do + %% We don't tell the mirrors we will die - so when we do %% they interpret that as a failure, which is what we %% want. cancel; diff --git a/src/rabbit_prequeue.erl b/src/rabbit_prequeue.erl index 51164af53f..994e66a96d 100644 --- a/src/rabbit_prequeue.erl +++ b/src/rabbit_prequeue.erl @@ -81,7 +81,7 @@ init(Q0, restart) when ?is_amqqueue(Q0) -> %% %% [2] Nothing is alive. We are the last best hope. Try to restart as a master. %% -%% [3] The current master is dead but either there are alive slaves to +%% [3] The current master is dead but either there are alive mirrors to %% take over or it's all happening on a different node anyway. This is %% not a stable situation. Sleep and wait for somebody else to make a %% move. diff --git a/test/dynamic_ha_SUITE.erl b/test/dynamic_ha_SUITE.erl index d5e9700b66..15770ca41f 100644 --- a/test/dynamic_ha_SUITE.erl +++ b/test/dynamic_ha_SUITE.erl @@ -444,7 +444,7 @@ nodes_policy_should_pick_master_from_its_params(Config) -> LastSlave = node(lists:last(SSPids)), ?assertEqual(true, apply_policy_to_declared_queue(Config, Ch, [A], [{nodes, [LastSlave]}])), - %% --> Master: B or C (depends on the order of current slaves) + %% --> Master: B or C (depends on the order of current mirrors ) %% Slaves: [] %% Now choose a new master that isn't synchronised. The previous @@ -452,8 +452,8 @@ nodes_policy_should_pick_master_from_its_params(Config) -> %% from the initial synchronised list). Thus, by taking the first %% node from this list, we know it is not synchronised. %% - %% Because the policy doesn't cover any synchronised slave, RabbitMQ - %% should instead use an existing synchronised slave as the new master, + %% Because the policy doesn't cover any synchronised mirror, RabbitMQ + %% should instead use an existing synchronised mirror as the new master, %% even though that isn't in the policy. ?assertEqual(true, apply_policy_to_declared_queue(Config, Ch, [A], [{nodes, [LastSlave, A]}])), @@ -559,7 +559,7 @@ failing_random_policies(Config) -> undefined, {exactly, 3}, all])). promote_slave_after_standalone_restart(Config) -> - %% Tests that slaves can be brought up standalone after forgetting the rest + %% Tests that mirrors can be brought up standalone after forgetting the rest %% of the cluster. Slave ordering should be irrelevant. %% https://github.com/rabbitmq/rabbitmq-server/issues/1213 [A, B, C] = rabbit_ct_broker_helpers:get_node_configs(Config, nodename), diff --git a/test/many_node_ha_SUITE.erl b/test/many_node_ha_SUITE.erl index 6f3bc49de7..d71b6214d5 100644 --- a/test/many_node_ha_SUITE.erl +++ b/test/many_node_ha_SUITE.erl @@ -103,7 +103,7 @@ kill_intermediate(Config) -> ProducerPid = rabbit_ha_test_producer:create(ProducerChannel, Queue, self(), false, Msgs), - %% create a killer for the master and the first 3 slaves + %% create a killer for the master and the first 3 mirrors [rabbit_ct_broker_helpers:kill_node_after(Config, Node, Time) || {Node, Time} <- [{A, 50}, {B, 50}, diff --git a/test/priority_queue_SUITE.erl b/test/priority_queue_SUITE.erl index 541a52ff24..8a2e53a06d 100644 --- a/test/priority_queue_SUITE.erl +++ b/test/priority_queue_SUITE.erl @@ -459,7 +459,7 @@ mirror_queue_sync(Config) -> mirror_queue_sync_priority_above_max(Config) -> A = rabbit_ct_broker_helpers:get_node_config(Config, 0, nodename), - %% Tests synchronisation of slaves when priority is higher than max priority. + %% Tests synchronisation of mirrors when priority is higher than max priority. %% This causes an infinity loop (and test timeout) before rabbitmq-server-795 {Conn, Ch} = rabbit_ct_client_helpers:open_connection_and_channel(Config, A), Q = <<"mirror_queue_sync_priority_above_max-queue">>, @@ -476,7 +476,7 @@ mirror_queue_sync_priority_above_max(Config) -> mirror_queue_sync_priority_above_max_pending_ack(Config) -> [A, B] = rabbit_ct_broker_helpers:get_node_configs(Config, nodename), - %% Tests synchronisation of slaves when priority is higher than max priority + %% Tests synchronisation of mirrors when priority is higher than max priority %% and there are pending acks. %% This causes an infinity loop (and test timeout) before rabbitmq-server-795 {Conn, Ch} = rabbit_ct_client_helpers:open_connection_and_channel(Config, A), @@ -499,9 +499,9 @@ mirror_queue_sync_priority_above_max_pending_ack(Config) -> mirror_queue_auto_ack(Config) -> A = rabbit_ct_broker_helpers:get_node_config(Config, 0, nodename), - %% Check correct use of AckRequired in the notifications to the slaves. - %% If slaves are notified with AckRequired == true when it is false, - %% the slaves will crash with the depth notification as they will not + %% Check correct use of AckRequired in the notifications to the mirrors. + %% If mirrors are notified with AckRequired == true when it is false, + %% the mirrors will crash with the depth notification as they will not %% match the master delta. %% Bug rabbitmq-server 687 {Conn, Ch} = rabbit_ct_client_helpers:open_connection_and_channel(Config, A), @@ -512,11 +512,11 @@ mirror_queue_auto_ack(Config) -> <<".*">>, <<"all">>), get_partial(Ch, Q, no_ack, [3, 2, 1]), - %% Retrieve slaves + %% Retrieve mirrors SPids = slave_pids(Config, A, rabbit_misc:r(<<"/">>, queue, Q)), [{SNode1, _SPid1}, {SNode2, SPid2}] = nodes_and_pids(SPids), - %% Restart one of the slaves so `request_depth` is triggered + %% Restart one of the mirrors so `request_depth` is triggered rabbit_ct_broker_helpers:restart_node(Config, SNode1), %% The alive slave must have the same pid after its neighbour is restarted diff --git a/test/simple_ha_SUITE.erl b/test/simple_ha_SUITE.erl index 10d8eda9ee..528c5f1cf9 100644 --- a/test/simple_ha_SUITE.erl +++ b/test/simple_ha_SUITE.erl @@ -121,7 +121,7 @@ rapid_redeclare(Config) -> end || _I <- lists:seq(1, 20)], ok. -%% Check that by the time we get a declare-ok back, the slaves are up +%% Check that by the time we get a declare-ok back, the mirrors are up %% and in Mnesia. declare_synchrony(Config) -> [Rabbit, Hare] = rabbit_ct_broker_helpers:get_node_configs(Config, @@ -222,7 +222,7 @@ consume_survives(Config, Channel2 = rabbit_ct_client_helpers:open_channel(Config, B), Channel3 = rabbit_ct_client_helpers:open_channel(Config, C), - %% declare the queue on the master, mirrored to the two slaves + %% declare the queue on the master, mirrored to the two mirrors Queue = <<"test">>, amqp_channel:call(Channel1, #'queue.declare'{queue = Queue, auto_delete = false}), @@ -253,7 +253,7 @@ confirms_survive(Config, DeathFun) -> Node1Channel = rabbit_ct_client_helpers:open_channel(Config, A), Node2Channel = rabbit_ct_client_helpers:open_channel(Config, B), - %% declare the queue on the master, mirrored to the two slaves + %% declare the queue on the master, mirrored to the two mirrors Queue = <<"test">>, amqp_channel:call(Node1Channel,#'queue.declare'{queue = Queue, auto_delete = false, @@ -288,7 +288,7 @@ rejects_survive(Config, DeathFun) -> Node1Channel = rabbit_ct_client_helpers:open_channel(Config, A), Node2Channel = rabbit_ct_client_helpers:open_channel(Config, B), - %% declare the queue on the master, mirrored to the two slaves + %% declare the queue on the master, mirrored to the two mirrors XOverflow = ?config(overflow, Config), Queue = <<"test_rejects", "_", XOverflow/binary>>, amqp_channel:call(Node1Channel,#'queue.declare'{queue = Queue, |