Typosbug23329

1 files changed, 12 insertions, 12 deletions

diff --git a/src/rabbit_msg_store.erl b/src/rabbit_msg_store.erl
index 189953cf..1fe06a1f 100644
--- a/src/rabbit_msg_store.erl
+++ b/src/rabbit_msg_store.erl
@@ -347,12 +347,12 @@
 %% actions you've issued to the msg_store have been processed. (b) Not
 %% only is client_delete_and_terminate/1 asynchronous, but it also
 %% permits writes and subsequent removes from the current
-%% (terminating) client which are still in flight can be safely
+%% (terminating) client which are still in flight to be safely
 %% ignored. Thus from the point of view of the msg_store itself, and
 %% all from the same client:
 %%
-%% (T) = termination; (WN) = write of msg N; (RN) = read of msg N
-%% -->  W1, W2, W1, R1, T, W3, R2, W2, R1, R2, R3, W4 -->
+%% (T) = termination; (WN) = write of msg N; (RN) = remove of msg N
+%% --> W1, W2, W1, R1, T, W3, R2, W2, R1, R2, R3, W4 -->
 %%
 %% The client obviously sent T after all the other messages (up to
 %% W4), but because the msg_store prioritises messages, the T can be
@@ -368,15 +368,15 @@
 %% would then mean that the subsequent W2 and R2 are then ignored.
 %%
 %% The use case then for client_delete_and_terminate/1 is if the
-%% client wishes to remove everything it's sent to the msg_store: it
-%% issues removes for all messages it's written, and then calls
-%% client_delete_and_terminate/1. At that point, any in-flight writes
-%% (and subsequent removes) can be ignored, but removes and writes for
-%% messages the msg_store already knows about will continue to be
-%% processed normally (which will normally just involve modifying the
-%% reference count, which is fast). Thus we save disk bandwidth for
-%% writes which are going to be immediately removed again by the the
-%% terminating client.
+%% client wishes to remove everything it's written to the msg_store:
+%% it issues removes for all messages it's written and not removed,
+%% and then calls client_delete_and_terminate/1. At that point, any
+%% in-flight writes (and subsequent removes) can be ignored, but
+%% removes and writes for messages the msg_store already knows about
+%% will continue to be processed normally (which will normally just
+%% involve modifying the reference count, which is fast). Thus we save
+%% disk bandwidth for writes which are going to be immediately removed
+%% again by the the terminating client.
 %%
 %% We use a separate set to keep track of the dying clients in order
 %% to keep that set, which is inspected on every write and remove, as