diff options
author | Matthew Sackman <matthew@rabbitmq.com> | 2011-01-11 11:59:46 +0000 |
---|---|---|
committer | Matthew Sackman <matthew@rabbitmq.com> | 2011-01-11 11:59:46 +0000 |
commit | f18a1d89c71a11cac0a2fc0a2dede9ae03c379f5 (patch) | |
tree | 775f4570cc13e8c23191713831af9d66b80f6eca | |
parent | 3ea9c75c5cc824089df4d56cafd557f599442c88 (diff) | |
download | rabbitmq-server-f18a1d89c71a11cac0a2fc0a2dede9ae03c379f5.tar.gz |
Typosbug23329
-rw-r--r-- | src/rabbit_msg_store.erl | 24 |
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 |