diff options
| -rw-r--r-- | src/rabbit_channel.erl | 17 |
1 files changed, 8 insertions, 9 deletions
diff --git a/src/rabbit_channel.erl b/src/rabbit_channel.erl index eb03bf54e8..0510afa9a4 100644 --- a/src/rabbit_channel.erl +++ b/src/rabbit_channel.erl @@ -590,15 +590,14 @@ handle_method(_Method, _, State = #ch{state = closing}) -> handle_method(#'channel.close'{}, _, State = #ch{reader_pid = ReaderPid}) -> {ok, State1} = notify_queues(State), %% We issue the channel.close_ok response after a handshake with - %% the reader, the other half of which is the - %% ready_for_close. That way the reader forgets about the channel - %% before we send the response (and this channel process - %% terminates). If we didn't do that, a channel.open for the same - %% channel number, which a client is entitled to send as soon as - %% it has received the close_ok, might be received by the reader - %% before it has seen the termination and hence be sent to the - %% old, now dead/dying channel process, instead of a new process, - %% and thus lost. + %% the reader, the other half of which is ready_for_close. That + %% way the reader forgets about the channel before we send the + %% response (and this channel process terminates). If we didn't do + %% that, a channel.open for the same channel number, which a + %% client is entitled to send as soon as it has received the + %% close_ok, might be received by the reader before it has seen + %% the termination and hence be sent to the old, now dead/dying + %% channel process, instead of a new process, and thus lost. ReaderPid ! {channel_closing, self()}, {noreply, State1}; |